对 DevOps 团队来说,检测大量服务器的性能异常并尽快响应一直是个挑战。他们设置了各种指标来监控服务器性能,但诊断性能问题复杂且耗时,因为诊断数据的量可能非常大。越来越多的人认为这个过程应该自动化。但怎么做呢?
流式系统在这种情况下可能很有帮助。它在接收到性能事件后实时监控指标,并基于 SQL 查询中定义的模式立即检测异常。一旦检测到性能问题,下游微服务可以触发一个动作来处理该问题。
本文将分享如何使用流式数据库 RisingWave 自动化地从系统性能指标流中检测异常。我们为本教程设置了一个演示集群,因此大家可以轻松尝试。
1. 开始之前
- 确保您的环境中安装了 Docker 和 Docker Compose。请注意,Docker Compose 包含在 Windows 和 macOS 的 Docker Desktop 中。如果您使用 Docker Desktop,请确保在启动演示集群之前已经运行。
- 确保您的环境中安装了 PostgreSQL 交互式终端
psql
。详细说明请参阅下载 PostgreSQL。
2. 启动演示集群
在演示集群中,我们打包了 RisingWave 和一个工作负载生成器。一旦集群启动,工作负载生成器将开始生成随机流量并将其输入到 Kafka。
首先,将 risingwave 仓库克隆到环境中。
git clone https://github.com/risingwavelabs/risingwave.git
导航到 integration_tests/cdn-metrics
目录,并从 docker compose 文件启动演示集群。
cd risingwave/integration_tests/cdn-metrics
docker compose up -d
命令未找到?
(1)Compose V2 中的默认命令行句法以
docker compose
开头,详见 Docker 文档。
(2)如果您使用的是 Compose V1,请改用docker-compose
。
将启动必要的 RisingWave 组件,包括 Frontend 节点、Compute 节点、Meta 节点和 MinIO。工作负载生成器将开始生成随机数据并将其输入到 Kafka topic。在这个演示集群中,物化视图的数据将存储在 MinIO 实例中。
3. 将 RisingWave 连接到数据流
让我们连接到 RisingWave,以便我们可以管理数据流并进行数据分析。
psql -h localhost -p 4566 -d dev -U root
创建两个独立的数据源。第一个是跟踪网络接口卡(NICs)的指标,第二个是跟踪传输控制协议(TCP)性能的指标流。
CREATE SOURCE nics_metrics (
device_id VARCHAR,
metric_name VARCHAR,
aggregation VARCHAR,
nic_name VARCHAR,
report_time TIMESTAMP WITH TIME ZONE,
bandwidth DOUBLE PRECISION,
metric_value DOUBLE PRECISION
) WITH (
connector = 'kafka',
topic = 'nics_metrics',
properties.bootstrap.server = 'message_queue:29092',
scan.startup.mode = 'earliest'
) FORMAT PLAIN ENCODE JSON;
CREATE SOURCE tcp_metrics (
device_id VARCHAR,
metric_name VARCHAR,
report_time TIMESTAMP WITH TIME ZONE,
metric_value DOUBLE PRECISION
) WITH (
connector = 'kafka',
topic = 'tcp_metrics',
properties.bootstrap.server = 'message_queue:29092',
scan.startup.mode = 'earliest'
) FORMAT PLAIN ENCODE JSON;
4. 定义物化视图并查询结果
在本教程中,我们将创建几个不同的物化视图。第一个视图 high_util_tcp_metrics
,将包括每个设备每三分钟所有指标的平均值。其他三个视图将派生自第一个视图,每个视图包含一个触发时间和不同的指标值。
4.1 为高利用率 TCP 指标设置物化视图
首先,我们将创建包含所有相关 TCP 值的物化视图。我们使用 tumble 函数将所有事件映射到1分钟的窗口,并计算每个设备在每个时间窗口内的平均指标值。接下来,分别计算平均 TCP 和 NIC 指标,然后在设备名称和时间窗口上进行连接。我们将保留测量接口传输的字节量的记录,其中平均利用率大于或等于 50。
请参考这个指南了解 tumble 函数和聚合的解释。
CREATE MATERIALIZED VIEW high_util_tcp_metrics AS
SELECT
tcp.device_id AS device_id,
tcp.window_end AS window_end,
tcp.metric_name AS metric_name,
tcp.metric_value AS metric_value,
nic.avg_util AS tcp_avg_bandwidth_util
FROM
(
SELECT
device_id,
window_end,
metric_name,
AVG(metric_value) AS metric_value
FROM
TUMBLE(
tcp_metrics,
report_time,
INTERVAL '1' MINUTE
)
GROUP BY
device_id,
window_end,
metric_name
) AS tcp
JOIN (
SELECT
device_id,
window_end,
AVG((metric_value) / bandwidth) * 100 AS avg_util
FROM
TUMBLE(
nics_metrics,
report_time,
INTERVAL '1' MINUTE
)
WHERE
metric_name = 'tx_bytes'
AND aggregation = 'avg'
GROUP BY
device_id,
window_end
) AS nic ON tcp.device_id = nic.device_id
AND tcp.window_end = nic.window_end
WHERE
avg_util >= 50;
我们可以通过查询我们刚刚创建的视图来看到一个结果示例:
SELECT * FROM high_util_tcp_metrics;
这是一个示例结果。
device_id | window_end | metric_name | metrics_value | tcp_avg_bandwidth_util
----------------------------------+---------------------------+----------------+---------------+-----------------------
eccbc87e4b5ce2fe28308fd9f2a7baf3 | 2022-08-17 18:02:00+00:00 | download_speed | 1126.3827 | 45.26712
eccbc87e4b5ce2fe28308fd9f2a7baf3 | 2022-08-17 18:02:00+00:00 | retrans_rate | 0.19406 | 45.26712
eccbc87e4b5ce2fe28308fd9f2a7baf3 | 2022-08-17 18:02:00+00:00 | srtt | 649.25184 | 45.26712
4.2 从物化视图中设置物化视图
RisingWave 支持基于物化视图创建物化视图。作为源使用的物化视图是上游物化视图,而基于其他物化视图创建的物化视图是下游物化视图。随着上游物化视图的值发生变化,下游物化视图将自动变化。
![MV on MV 示例]](https://i-blog.csdnimg.cn/direct/3ba437bc734f4929859e75baec52b9e3.png#pic_center)
以下三个物化视图使用 high_util_tcp_metrics
作为它们的源。生成的物化视图包括检测到的不同事件的异常。当某个事件的相应指标值高于或低于特定阈值时,就会检测到异常。
第一个物化视图查询重传超时。
CREATE MATERIALIZED VIEW retrans_incidents AS
SELECT
device_id,
window_end AS trigger_time,
metric_value AS trigger_value
FROM
high_util_tcp_metrics
WHERE
metric_name = 'retrans_rate'
AND metric_value > 0.15;CREATEMATERIALIZEDVIEW download_incidents AS
SELECT
device_id,
window_end AS trigger_time,
metric_value AS trigger_value
FROM
high_util_tcp_metrics
WHERE
metric_name = 'download_speed'
AND metric_value < 200.0;
第二个物化视图查询慢速往返时间。
CREATE MATERIALIZED VIEW srtt_incidents AS
SELECT
device_id,
window_end AS trigger_time,
metric_value AS trigger_value
FROM
high_util_tcp_metrics
WHERE
metric_name = 'srtt'
AND metric_value > 500.0;
最后一个物化视图查询下载事件。
CREATE MATERIALIZED VIEW download_incidents AS
SELECT
device_id,
window_end AS trigger_time,
metric_value AS trigger_value
FROM
high_util_tcp_metrics
WHERE
metric_name = 'download_speed'
AND metric_value < 200.0;
现在我们可以显示检测到的异常。我们将以 srtt_incidents
为例进行展示,但您可以查询其他两个物化视图。请注意,您的结果会有所不同,因为工作负载生成器在流中随机生成数据。
SELECT * FROM srtt_incidents;
device_id | trigger_time | trigger_value
---------------------------------+---------------------------+---------------
cfcd208495d565ef66e7dff9f98764da | 2022-08-18 18:02:00+00:00 | 698.14387
e4da3b7fbbce2345d7772b0674a318d5 | 2022-08-18 18:09:00+00:00 | 973.03618
您可以几分钟后重新运行查询,看看结果是否有更新。
当您完成时,运行以下命令以断开 RisingWave 的连接。
\q
可选:要移除容器和生成的数据,请使用以下命令。
docker compose down -v
5. 总结
在本教程中,我们学到了:
- 如何使用 RisingWave 设置用于异常检测的流式处理管道。
- 如何基于现有物化视图创建物化视图。
本 Demo 只是抛砖引玉,欢迎大家充分利用 RisingWave 的强大功能挖掘其在各个领域的更多应用。
6. 关于 RisingWave
RisingWave 是一款开源的分布式流处理数据库,旨在帮助用户降低实时应用的开发成本。RisingWave 采用存算分离架构,提供 Postgres-style 使用体验,具备比 Flink 高出 10 倍的性能以及更低的成本。
👨🔬加入 RW 社区,欢迎关注公众号:RisingWave 中文开源社区
🧑💻想要了解和探索 RisingWave,欢迎浏览我们的官网:risingwave.com/
🔧快速上手 RisingWave,欢迎体验入门教程:github.com/risingwave
💻深入理解使用 RisingWave,欢迎阅读用户文档:zh-cn.risingwave.com/docs