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 支持可以触发自动修复。所有这些结合起来,使值班工程师能够专注于他们能产生最大影响的问题。
在为您的服务定义告警时,另请参阅我们的告警最佳实践。