Prometheus告警需配合Alertmanager实现去重分组路由，Grafana告警为独立体系；PromQL规则应使用rate/irate、加label过滤、设持续时间阈值以减少误报。
想让 Prometheus + Grafana 告警真正管用，光配个阈值远远不够——得知道指标从哪来、规则怎么写、告警怎么收敛、通知怎么不漏不扰。
搞懂告警链路：从采集到通知不是一条直线
Prometheus 不直接发通知，它只负责“发现异常”；Alertmanager 才是告警的调度中心，负责去重、分组、静默、路由和派发；Grafana 的告警是独立体系（v8+ 后逐渐转向内置 Alerting），和 Prometheus 原生告警不互通。混用时务必分清职责：
- Prometheus rules.yml 定义“什么算问题”（如：
100 * (1 - avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m]))) > 90） - Alertmanager 配置
route和receivers，决定“谁在什么时候收到哪类告警” - Grafana 告警需在面板或独立告警规则中配置，数据源必须是其支持的（Prometheus、Mimir、Loki 等），且触发逻辑走 Grafana 后端
写好 PromQL 告警规则：别让误报毁掉可信度
高频误报往往源于 PromQL 表达式没考虑时间窗口、实例差异或瞬时抖动。几个关键点：
- 用
rate()或irate()计算速率，别直接比原始计数器（如node_network_receive_bytes_total） - 聚合前先加 label 过滤，避免跨节点/服务误合并（例如加
{job="node-exporter", instance=~"prod-.*"}） - 给 CPU、内存等基础指标留出缓冲空间，比如 “持续 3 分钟 > 92%” 比 “> 90%” 更稳，用
count_over_time(your_condition[3m]) == 3实现 - 对磁盘使用率这类缓慢增长指标，用
node_filesystem_avail_bytes / node_filesystem_size_bytes 比固定字节数更合理
Alertmanager 分组与静默：让运维不被消息淹没
一个宿主机宕机，可能同时触发 CPU、内存、网络、进程多个告警——全发出来就是噪音。靠 group_by 和 inhibit_rules 控制节奏：
-
group_by: [alertname, job, instance]把同实例的同类告警压成一条 - 设置
group_wait: 30s（首次发前等）、group_interval: 5m（后续同组再发间隔）、repeat_interval: 4h（彻底静默前重复提醒） - 用抑制规则（inhibition）让高优先级告警压制低优先级：比如
instance_down触发后，自动抑制该实例上所有node_disk_io_time_seconds_total告警 - 日常维护前，用 Alertmanager UI 或 API 创建临时静默（silence），按标签匹配，精确到分钟级
对接真实通知渠道：微信、钉钉、飞书不能只靠 webhook
原生 Alertmanager 只支持 email、PagerDuty、Slack 等。国内常用 IM 工具需自建中转：
- 钉钉/飞书：用开源项目 prometheus-webhook-dingtalk，部署后在 Alertmanager
receivers中配置 webhook URL - 微信：通过企业微信应用发送，需获取
agentid、secret和corpid，可用轻量脚本封装 API 调用，或选用 PrometheusAlert - 关键提示：所有 webhook 请求务必开启 HTTPS + TLS 验证；敏感 token 别硬编码进配置，改用
file_sd_configs动态加载或环境变量注入
告警不是设完就完的事——要定期清理失效规则、校准阈值、回溯漏报案例、更新联系人列表。真正的稳定性，藏在每次告警之后的复盘里。
