监控也会坏
监控系统自身也会失效：采集器停止、规则不再评估、通知渠道静默，这些故障不会产生任何告警。结果是业务实际已经处于无人监控的状态，而所有人都以为一切正常，往往要等真正出故障时才被发现。
把链路每一环都当对象
做法是把监控链路的每个环节都纳入监控：采集端看抓取成功率与耗时，规则端看最近评估时间，通知端看投递结果。任何一环的指标缺失或停滞，本身就是需要处理的信号，而不是可以忽略的噪音。
基本信息
| 采集端 | 抓取状态与抓取耗时 |
|---|---|
| 存储端 | 序列总数与写入情况 |
| 规则端 | 规则组最近一次评估时间 |
| 通知端 | 通知发送失败计数 |
典型使用场景
- 抓取失败告警：目标失联或抓取超时
- 规则停滞告警：评估时间长时间不更新
- 序列数异常：基数膨胀或采集范围被误改
- 通知投递失败：通道不可用导致告警丢失
- 心跳检测：定期生成一条必然触发的测试告警，验证全链路可达
自监控的基础告警
自监控的基础告警
# 目标失联
up == 0
# 规则组超过 5 分钟未评估
time() - prometheus_rule_group_last_evaluation_timestamp_seconds > 300
# 采集耗时逼近超时阈值
scrape_duration_seconds > 0.8 * scrape_timeout_seconds
# 序列总数突增，提示基数异常
prometheus_tsdb_head_series > 3000000自监控对象
| 环节 | 关键指标 | 异常信号 |
|---|---|---|
| 采集端 | 抓取状态与耗时 | 目标失联或抓取超时 |
| 存储端 | 当前序列总数 | 序列数异常增长 |
| 规则端 | 规则组评估时间 | 规则停滞不再评估 |
| 通知端 | 通知投递结果 | 通道静默或投递失败 |
部署与演练
- 监控组件与被监控系统避免强耦合，防止一起失联
- 告警通道保留多条，避免单通道故障导致全部通知失效
- 定期做通道演练，确认消息真的能送到人
- 自监控告警本身也要有兜底：留一条独立的检查路径
自监控的指标要与业务监控同样对待：告警规则、看板与值班归属都要明确，否则它只会成为一块没人看的面板。
监控系统与业务系统部署在同一处，一旦整体不可用会同时失效：至少让告警通道与检查手段保持独立。