第2章告警源头分析

2、告警源头分析：三大监控体系的触发机制

告警处理的第一步，不是看告警内容，而是搞清楚——这个告警从哪来的。

我见过太多运维新手，一看到告警就慌了，直接开始查日志、重启服务。其实你想想看，不同监控系统的触发逻辑完全不同，排查方向也天差地别。今天我就把三大主流告警源头的触发机制掰开揉碎了讲清楚。

核心观点：告警源头决定排查路径。Prometheus 看指标趋势，Zabbix 看阈值边界，ELK 看日志模式，业务指标看数据波动。搞错方向，白忙一场。

2.1 Prometheus 告警触发机制

Prometheus 的告警，说白了就是基于时间序列数据的条件判断。它不关心你的业务逻辑，只关心指标数值是否满足预设规则。

我个人习惯把 Prometheus 告警分为两类：

阈值类告警：CPU > 90%，内存 > 85%
趋势类告警：5分钟内错误率上升超过 50%

这里有个关键点——Prometheus 的告警规则是在 prometheus.yml 或独立的规则文件中定义的。举个例子：

groups:
- name: example
  rules:
  - alert: HighCpuUsage
    expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Instance {{ $labels.instance }} CPU usage over 90%"

注意那个 for: 5m，这是 Prometheus 特有的持续时间条件。我曾经踩过一个坑：某次业务高峰期，CPU 瞬间冲到 95%，但只持续了 30 秒就回落了。如果没有 for 条件，Prometheus 会立刻触发告警，结果就是告警风暴。

我的建议：对于瞬时波动敏感的业务（如电商秒杀），可以把 for 设短一些（1-2分钟）；对于基础设施指标（如磁盘使用率），建议设到 5-10 分钟，避免误报。

2.2 Zabbix 告警触发机制

Zabbix 和 Prometheus 最大的区别在于——Zabbix 是主动采集 + 被动接收混合模式。它的告警触发逻辑更复杂，但也更灵活。

Zabbix 的告警触发主要依赖三个要素：

要素	说明	我的经验
触发器（Trigger）	定义告警条件，如 {host:system.cpu.load.avg(5m)}>5	注意函数参数，avg(5m) 和 avg(10m) 结果差异很大
事件（Event）	触发器条件满足时生成的事件	同一个触发器可能生成多个事件，注意去重
动作（Action）	事件触发后的处理流程	我习惯把动作和升级机制绑定，避免告警无人处理

Zabbix 有个很实用的功能——依赖关系。比如，如果网络交换机宕机了，下面所有服务器的告警其实都是冗余的。我曾经在管理 2000+ 台服务器时，通过配置依赖关系，把告警量从每天 5000+ 降到了 300+。

避坑指南：Zabbix 的触发器表达式里，时间函数（如 avg、last、min）的参数单位是秒，不是分钟。我见过有人写 avg(5m) 结果语法报错，正确写法是 avg(300)。嗯，这个坑我踩过两次。

2.3 ELK 日志告警触发机制

ELK 的告警和前面两个完全不同。它不监控指标，而是监控日志内容。说白了，就是「当某类日志出现时，触发告警」。

ELK 告警的典型场景：

错误日志出现频率超过阈值（如 5 分钟内出现 100 次 ERROR）
特定关键词出现（如 "OutOfMemoryError"、"Connection refused"）
日志模式异常（如某接口突然没有日志输出了）

在 Elasticsearch 中，我们通常用 Watcher 或 ElastAlert 来实现告警。以 ElastAlert 为例：

name: Error Rate Alert
type: frequency
index: logstash-*
num_events: 50
timeframe:
  minutes: 5
filter:
- query:
    query_string:
      query: "level: ERROR AND service: payment"
alert:
- "slack"
- "email"

这个配置的意思是：在 5 分钟内，如果 payment 服务的 ERROR 日志超过 50 条，就发 Slack 和邮件告警。

我个人觉得，ELK 告警最大的价值在于发现指标监控发现不了的问题。比如，某个接口响应时间正常，但返回的数据全是空值——这种问题指标监控看不出来，但日志里会有明显的 WARN 记录。

一个小技巧：ELK 告警一定要设置「静默期」。否则，如果某个服务持续打印错误日志，你的手机可能会被告警消息刷爆。我一般设 30 分钟的静默期，同一个规则 30 分钟内只发一次告警。

2.4 业务指标告警触发机制

业务指标告警，这是最贴近用户的一层。它监控的不是 CPU、内存，而是订单量、支付成功率、用户登录数这些业务数据。

业务指标告警的触发机制通常有两种：

固定阈值：比如支付成功率低于 99% 就告警
动态基线：基于历史数据自动计算正常范围，超出范围就告警

我强烈推荐使用动态基线。为什么？因为业务指标有周期性。比如，电商平台的工作日订单量和周末完全不同，如果用固定阈值，要么工作日误报，要么周末漏报。

动态基线的实现思路：

# 伪代码示例
def detect_anomaly(current_value, historical_data):
    # 取过去7天同一时段的数据
    baseline = historical_data[-7*24*60:]  # 每分钟一个点
    mean = np.mean(baseline)
    std = np.std(baseline)
    # 如果当前值偏离均值超过3个标准差，触发告警
    if abs(current_value - mean) > 3 * std:
        return True
    return False

嗯，这里要注意——动态基线不是万能的。如果业务本身在快速增长（比如双十一期间），历史数据就失去了参考意义。我遇到过这种情况：某次大促，订单量比平时涨了 10 倍，动态基线疯狂告警，最后只能临时把告警关了。

我的经验：业务指标告警一定要有「人工确认」环节。因为业务数据变化的原因太多了——可能是活动推广、可能是竞品下线、也可能是系统故障。不要一告警就重启服务，先看看业务数据是不是真的异常。

2.5 三大告警源头的对比总结

说了这么多，我画了一张图帮你理清思路：

这张图把三大监控体系的核心特点都列出来了。你想想看，实际工作中，我们往往需要组合使用：Prometheus 看基础设施，Zabbix 看传统设备，ELK 看应用日志，业务指标看用户数据。四者互补，才能覆盖全栈。

最后说一句——告警源头分析不是一次性的工作。随着业务变化，告警规则也要持续调整。我每季度都会 review 一次告警规则，把那些「从来没触发过」或者「天天在触发」的规则都过一遍。前者可能是配置错了，后者可能是阈值设得太低了。

记住：告警不是越多越好。一个健康的监控系统，告警量应该稳定在每天 10-20 条以内。如果超过这个数，说明你的告警规则需要优化了。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

2、告警源头分析：三大监控体系的触发机制

2.1 Prometheus 告警触发机制

2.2 Zabbix 告警触发机制

2.3 ELK 日志告警触发机制

2.4 业务指标告警触发机制

2.5 三大告警源头的对比总结