监控基础：理解监控体系、指标种类与告警生命周期
说实话，很多团队一上来就扎进告警规则配置，结果告警风暴、漏报、误报全来了。我刚开始带项目时也犯过这个错——连监控体系长什么样都没搞清楚，就急着写PromQL。嗯，这节课我们先打好地基，把监控体系、指标分类、告警生命周期这三个核心概念捋清楚。
监控体系：到底要监控什么？
一个完整的监控体系，说白了就是回答三个问题：
- 服务还在跑吗？ —— 可用性监控
- 跑得怎么样？ —— 性能监控
- 资源够不够？ —— 容量监控
我个人习惯把这三大块再拆成更细的维度，比如基础设施层、应用层、业务层。你想想看，如果业务指标（比如下单成功率）下降了，你光看CPU可没用，必须能层层下钻找到根因。
核心原则：监控体系应该是“漏斗式”的——从业务指标一路下钻到基础设施指标，每一层都有对应的监控项。
指标种类：计数器、直方图、Summary……怎么选？
指标类型这玩意儿，早期很多人搞混。我用一个表格帮你梳理清楚：
| 指标类型 | 典型用途 | 数据特点 | 常见示例 |
|---|---|---|---|
| Counter（计数器） | 累计计数 | 只增不减（重启后归零） | 请求总数、错误总数 |
| Gauge（仪表盘） | 瞬态值 | 可增可减 | 内存使用量、在线人数 |
| Histogram（直方图） | 分布统计 | 分桶计数 + 总和 + 计数 | 请求延迟分布 |
| Summary（摘要） | 分位数估算 | 流式计算分位数 + 总和 + 计数 | TP99、TP999 延迟 |
我有一个小建议：如果能用Histogram就别用Summary。为什么？因为Histogram可以在查询端通过histogram_quantile函数灵活算分位数，而Summary的分位数是在客户端预计算的，后期没法改。
避坑：我曾经在项目里用Counter记录并发请求数，结果发现数值一直在涨不会降——后来才反应过来应该用Gauge。指标类型选错，数据全白费。
告警生命周期：从触发到闭环
告警不是发出去就算完事。一个完整的告警生命周期大致是这样的：
- 触发 —— 指标值越过阈值
- 聚合/去重 —— 同一故障的告警合并
- 通知 —— 通过电话、钉钉、邮件送达
- 确认/认领 —— 值班人员响应
- 处理/修复 —— 执行预案或排查
- 恢复/关闭 —— 告警自动恢复或手动关闭
这里面最容易出问题的环节是“聚合”。如果不去重，一个Elasticsearch集群挂掉可能触发几千条告警，全砸到手机上——这就是典型的告警风暴。我个人习惯在告警规则里加上group_by和group_interval，把同类告警揉成一条。
经验：我曾经在压测时没做聚合，结果告警直接打爆了PagerDuty的API限流。从那以后，我每条告警规则都会先问自己：同一时间最多会有多少条类似告警？
一张图搞定监控体系 + 指标 + 告警流程
下面这张图把三个核心概念串了起来，方便你对照理解：
实战视角：一个完整的监控告警配置线索
前面讲了概念，接下来我们用一个小例子感受一下。假设你要监控一个支付服务：
- 可用性：每5秒探测一次HTTP健康检查接口，响应非200即告警
- 性能：记录所有请求延迟的Histogram，阈值设TP99 > 500ms
- 容量：Gauge监控JVM堆内存，超过80%告警
告警规则写成PromQL大概长这样：
# 支付服务延迟 TP99 告警
histogram_quantile(0.99,
sum(rate(http_request_duration_seconds_bucket{service="payment"}[5m])) by (le)
) > 0.5嗯，这里要注意：histogram_quantile必须在聚合函数之前先算百分位，否则结果不准。我见过有人把顺序写反，查了一下午为什么TP99永远等于0。
小技巧：一开始别把所有指标都配上告警。我建议先挑3-5个核心指标（比如错误率、P99延迟、CPU高水位），把报警通路跑通，再逐步添加。贪多嚼不烂。
好了，监控基础这部分就到这里。搞清楚了“监控什么”“用什么指标”“告警怎么流转”，后面配置告警规则、对接通知通道时才会更顺手。