Shirone

监控回答两个问题#

「系统现在正常吗？」——用于告警，要求快、准、少误报。

「出问题的时候，哪里出了问题？」——用于排障，要求数据足够细、维度足够多。

这两个目标有时矛盾：告警要求聚合后的少量信号，排障要求保留大量原始数据。好的监控体系同时服务两者，而不是用同一套东西勉强应付。

四层监控模型#

从底向上，每一层关注不同的问题：

新手常犯的错误是只监控第一层——CPU 60% 告警响了，但用户一切正常；反过来数据库连接池耗尽导致全站 500，CPU 却风平浪静。越靠近用户的层级，告警价值越高。

三大支柱的分工#

指标（Metrics）：按时间间隔采样的数值，如「过去 1 分钟平均延迟」。特点是聚合后体积小、查询快，适合趋势图和告警条件。局限是维度爆炸——给指标加 user_id 标签，时间序列数量直接失控。

日志（Logs）：离散事件的记录，信息量最大但检索成本高。排障时回答「这个具体请求发生了什么」靠它。

追踪（Traces）：一个请求跨多个服务的完整路径，微服务架构下定位慢调用靠它。

三者的关系：指标告诉你出事了，日志告诉你发生了什么，追踪告诉你卡在哪一环。

告警疲劳：监控系统的头号杀手#

告警太多 = 没有告警。值班的人每天收到 50 条告警，其中 49 条可以安全忽略，那么第 50 条也必然被忽略。设计告警时遵守几条纪律：

1. 只对「需要人立即行动」的情况告警。 CPU 高需要人半夜爬起来吗？通常不需要。磁盘 95% 需要吗？可能只需要工作日处理。用户支付失败率飙升呢？需要，立刻。

2. 告警基于症状，不是原因。 「数据库连接数高」是原因，「接口错误率超过 5%」是症状。原因类信号适合做成巡检报表，症状类信号才配叫醒人。

3. 每条告警都要有处理手册。 收到告警的人（可能是三个月后的你）应该能照着 runbook 一步步排查，而不是对着一个指标名干瞪眼。告警消息里附上相关面板链接和处理文档地址。

4. 设置抑制与静默。 主机宕机时，它上面的 30 个服务告警应该被收敛成一条；计划内维护期间对应告警提前静默，别让噪音训练大家忽略告警。

延迟告警的正确姿势：分位数与窗口#

「平均响应时间」是最具欺骗性的指标——99 个 10ms 的请求和 1 个 10s 的请求，平均下来 109ms，看起来还行，但有一个用户等了 10 秒。

正确做法是监控分位数：p50 看中位体验，p95/p99 看尾部体验。告警条件再加上持续时间窗口，避免毛刺触发：

1
# 伪代码：p99 延迟连续 5 分钟超过 2 秒才告警
2
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 2

同样的思路适用于错误率：「5 分钟内错误率 > 2%」比「单次错误」可靠得多。

从一台机器开始的最小实践#

暂时不上复杂系统，一台 Linux 服务器也能做好基础监控：

1. 指标采集：装 node_exporter，暴露机器指标到 :9100/metrics。
2. 可视化：Grafana 连上 Prometheus，导入官方 Node Exporter 面板。
3. 告警：只配三条——磁盘使用率 > 85%（预警）、内存可用 < 10%（预警）、服务端口不通（严重）。
4. 日志：确认 journalctl -u <你的服务> 能查到应用日志，rsyslog 正常轮转。

这套组合足够支撑个人项目和小团队初期，等它不够用时，痛点会自然告诉你下一步该补什么。

延伸阅读#

• Google SRE Book: Monitoring Distributed Systems
• Prometheus 官方文档：Alerting rules
• The USE Method（Brendan Gregg）