实用的异常检测
2015年6月18日作者 Brian Brazil
在他的致监控/指标/警报公司的公开信中,John Allspaw 断言,试图“在正确的时间完美地检测异常是不可能的”。
我曾见过一些才华横溢的工程师试图构建系统,以根据时间序列数据自动检测和诊断问题。虽然演示确实可以成功,但数据总是噪声过大,使得这种方法除了最简单的实际系统之外,无法应用于其他任何情况。
然而,希望并未完全破灭。有许多常见的异常可以通过定制规则来检测和处理。Prometheus 查询语言为您提供了发现这些异常的工具,同时避免了误报。
构建查询
服务中常见的问题是,少数服务器的性能不如其他服务器,例如响应延迟增加。
假设我们有一个指标 instance:latency_seconds:mean5m
,表示服务每个实例的平均查询延迟,它是通过记录规则从 Summary 指标计算得出的。
一个简单的开始方法是寻找延迟超过平均值两个标准差的实例
instance:latency_seconds:mean5m
> on (job) group_left()
(
avg by (job)(instance:latency_seconds:mean5m)
+ on (job)
2 * stddev by (job)(instance:latency_seconds:mean5m)
)
您尝试后发现,当延迟非常集中时,会出现误报。因此,您添加了一个要求,即实例延迟也必须高于平均值20%。
(
instance:latency_seconds:mean5m
> on (job) group_left()
(
avg by (job)(instance:latency_seconds:mean5m)
+ on (job)
2 * stddev by (job)(instance:latency_seconds:mean5m)
)
)
> on (job) group_left()
1.2 * avg by (job)(instance:latency_seconds:mean5m)
最后,您发现误报往往发生在流量较低时。您添加了一个要求,即每个实例必须有足够的流量,达到每秒1次查询。您为此创建了一个警报定义
groups:
- name: Practical Anomaly Detection
rules:
- alert: InstanceLatencyOutlier
expr: >
(
(
instance:latency_seconds:mean5m
> on (job) group_left()
(
avg by (job)(instance:latency_seconds:mean5m)
+ on (job)
2 * stddev by (job)(instance:latency_seconds:mean5m)
)
)
> on (job) group_left()
1.2 * avg by (job)(instance:latency_seconds:mean5m)
and on (job)
avg by (job)(instance:latency_seconds_count:rate5m)
>
1
)
for: 30m
自动操作
上述警报可以输入到 Alertmanager,然后从那里发送到您的聊天、工单或寻呼系统。过了一段时间,您可能会发现警报的常见原因是无法通过适当修复解决的问题,但存在诸如重启、重引导或机器替换等自动化操作可以解决该问题。
与其让人类处理这项重复性任务,一个选择是让 Alertmanager 将警报发送到一个 Web 服务,该服务将执行此操作,并具有适当的节流和安全功能。
通用 webhook 将警报通知发送到您选择的 HTTP 端点。一个使用它的简单 Alertmanager 配置可能如下所示
# A simple notification configuration which only sends alert notifications to
# an external webhook.
receivers:
- name: restart_webhook
webhook_configs:
url: "http://example.org/my/hook"
route:
receiver: restart_webhook
总结
Prometheus 查询语言允许对您的监控数据进行丰富的处理。这使您能够创建具有良好信噪比的警报,并且 Alertmanager 的通用 webhook 支持可以触发自动修复。所有这些结合起来,使值班工程师能够专注于他们能产生最大影响的问题。
在为您的服务定义警报时,另请参阅我们的警报最佳实践。