本文目录导读：
告警规则配置是监控系统中的核心环节,它决定了何时以及如何向运维人员发送通知，不同的监控系统（如 Prometheus、Zabbix、阿里云云监控、Grafana 等）配置方式略有不同，但核心逻辑是一致的。
以下我将从核心概念、通用配置步骤、常见规则类型以及最佳实践四个方面进行详细说明。
核心概念（理解这些是基础）
无论使用哪种系统,告警规则通常包含以下五个要素：
- 指标（Metric）：你要监控什么？如
cpu_usage、memory_available、http_request_duration_seconds。 - 条件（Condition）：什么情况下触发？如
> 90%、< 10GB、!= 200。 - 持续时间（Duration / For）：条件满足多久后才算真正告警？这是为了防止因瞬时抖动（毛刺）产生大量误报，CPU 超过 90% 持续 5 分钟 才告警。
- 严重级别（Severity）：问题有多严重？常见级别：
- Critical（严重）：影响核心业务，需立即处理（如服务宕机）。
- Warning（警告）：潜在风险，需关注（如磁盘使用率 85%）。
- Info（信息）：通知类消息。
- 通知方式（Channel）：告警发给谁？通过什么方式？如邮件、短信、钉钉/企业微信/飞书机器人、电话、PagerDuty 等。
通用配置步骤（以 Prometheus + Alertmanager 为例）
这是目前云原生领域最主流的监控告警方案,其逻辑适用于大多数系统。
步骤 1：定义告警规则文件（Prometheus 端）
在 Prometheus 的配置目录中创建 .rules 文件，并加载到 prometheus.yml 中。
示例 alert.rules 文件：
groups:
- name: example-alerts
rules:
- alert: InstanceDown # 告警名称
expr: up == 0 # PromQL表达式，当实例状态为0时触发
for: 1m # 持续1分钟才告警
labels:
severity: critical # 告警级别
annotations:
summary: "Instance {{ $labels.instance }} down" # 告警摘要
description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 1 minute." # 详细描述
- alert: HighCpuUsage
expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
for: 5m
labels:
severity: warning
annotations:
summary: "High CPU usage on {{ $labels.instance }}"
description: "Instance {{ $labels.instance }} CPU usage is above 90% (currently: {{ $value }}%)"
关键字段解释：
expr：核心查询逻辑。for：持续时间，防抖的关键。labels：可以添加自定义标签，severity最常用。annotations：告警消息的具体内容，可以使用模板变量$labels（来自时间序列标签）和$value（当前的指标值）。
步骤 2：配置 Alertmanager（通知分发）
Alertmanager 负责接收 Prometheus 发来的告警，然后进行分组、抑制、静默，并发送通知。
示例 alertmanager.yml 核心配置：
route:
group_by: ['alertname', 'cluster'] # 按告警名和集群分组
group_wait: 30s # 组内等待时间，收集更多告警
group_interval: 5m # 相同组告警的发送间隔
repeat_interval: 4h # 已解决告警重复通知的间隔
receiver: 'default-receiver'
routes:
- match:
severity: critical
receiver: 'pager-duty' # 严重告警走电话/钉钉
receivers:
- name: 'default-receiver'
webhook_configs:
- url: 'http://your-webhook-url/alert' # 通用webhook，可连钉钉/企微
- name: 'pager-duty'
webhook_configs:
- url: 'http://pagerduty-url/critical-alerts'
关键概念：
- 分组（Grouping）：将相似的告警合并，避免“告警风暴”。
- 抑制（Inhibition）：当高等级告警（如服务宕机）触发时，抑制衍生告警（如该服务的端口检查失败），避免信息冗余。
- 静默（Silencing）：根据时间或标签，在特定时间段内屏蔽特定告警（如维护窗口期间）。
- 接收器（Receiver）：定义告警的最终去向（邮件、钉钉、Webhook 等）。
常见告警规则类型（模板）
基础设施监控
- 节点存活：
up == 0 - CPU 使用率：
(100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)) > 80 - 内存使用率：
(node_memory_MemTotal_bytes - node_memory_Available_bytes) / node_memory_MemTotal_bytes * 100 > 90 - 磁盘使用率：
(node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 < 10 - 磁盘 IO 繁忙：
rate(node_disk_io_time_seconds_total[1m]) > 0.9
应用与中间件监控
- HTTP 错误率：
sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.05(5% 5xx 错误) - P99 延迟过高：
histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) > 1(P99 延迟 > 1秒) - Java JVM 堆内存满：
jvm_memory_used_bytes{area="heap"} / jvm_memory_max_bytes{area="heap"} > 0.9
业务与流量监控
- 流量突增/突降：
rate(http_requests_total[5m]) / rate(http_requests_total[10m]) > 2(5分钟内流量是10分钟的2倍) - 队列积压：
kafka_consumer_lag > 1000
最佳实践（避免踩坑）
- 避免“抖动”：一定使用
for子句，如果没有，CPU 一秒飙到 99% 又会降下来，你会收到无数个告警和恢复通知。 - 定义清晰的“恢复”规则：告警系统会自动发送恢复通知，确保你的恢复阈值合理（低于 80% 才算恢复，而不是低于 90%）。
- 带上上下文（Annotations）：告警消息应该包含：谁（实例名）、发生了什么（问题描述）、影响如何（严重级别）、值是多少（当前值），不要只发一个“CPU 高了”。
- 分层告警：
- P0/Critical：直接电话或钉钉加急，必须在 5 分钟内响应（如整个服务 500 错误）。
- P1/Warning：非工作时间发邮件，工作时间发 IM 群消息（如磁盘 85%）。
- P2/Info：记录到日志，汇总日报（如响应时间波动）。
- 使用标签进行分类：通过
severity、env（环境）、team等标签，合理配置 Alertmanager 的routes，让告警分流到正确的团队和渠道。 - 定期清理和优化：每季度审查一次告警规则，删除那些你看了 3 次但从未处理的“噪声”告警。警惕“告警疲劳”。
- 配置告警静默：对“计划中的操作”（如版本发布、机房维护）提前创建静默规则，避免误报。
告警规则配置的核心不是“配置”，而是 “业务影响分析”。
- 一个好的告警规则 = 明确的指标 + 合理的阈值 + 有效的持续时间 + 清晰的通知内容 + 正确的分级路由。
- 最成功的监控是“机器忙得像狗，运维人员却在喝茶”。
对于不同的具体平台（如阿里云 ARMS、腾讯云、Zabbix、Nightingale），界面操作会简化这些过程，但背后的逻辑（指标、条件、持续、级别、渠道）是完全相通的。
