指标、监控与告警：SRE 基础指南

系统的稳定性不是靠运气维持的。一套靠谱的监控体系能让你在问题影响用户之前发现它、在复盘时有据可查、在扩容决策时有数可依。这篇指南把监控体系拆成三个核心组件——指标、监控、告警——讲清楚各自的角色、该采哪些数据、以及怎么把它们组装成一套能真正保障可靠性的系统。

什么是指标（Metrics）？

指标是某个时间点上一个代表系统状态的数字——它把复杂的底层活动压缩成一个可解释的值，用来监控、诊断和决策。

几个关键认知：

• 指标是时序数据。单个数字意义有限，连续采集形成的时间序列才能揭示规律、暴露异常、呈现趋势。CPU 此刻 80% 说明不了什么，但"过去一周每天 14 点都冲到 95%"就是个明确的信号。
• 指标需要上下文。同样 80% 的 CPU，在批处理机器上是正常水位，在延迟敏感的 API 网关上可能就是事故前兆。指标只有和历史基线、预期负载、业务目标对照着看才有意义。
• 指标要可行动。好的指标能直接驱动决策：触发告警、触发自动扩容、或者告诉你该优化哪段代码。

应该采集哪些指标？

把系统想象成一栋楼：地基、主体结构、各楼层、屋顶，每层都有各自的健康视角。监控策略也应该按层次规划：

1. 主机层指标

单台机器的健康：CPU 使用率、内存、磁盘空间与 IO、进程状态、网络吞吐与错误率。这是最基础的一层，采集工具如 Node Exporter、Telegraf，或者观测云的 DataKit——装上就自动上报主机指标，无需额外配置。

2. 应用层指标

应用自己的业务行为：请求速率与错误率、响应时间与延迟分布、队列长度与处理时长、依赖调用耗时。这层需要埋点——用 Prometheus 客户端库或 OpenTelemetry SDK 在代码里暴露指标，接入 APM 探针则能获得免埋点的请求级追踪。

3. 基础设施层指标

支撑应用的中间层：容器与 K8s 集群状态、数据库（连接数、慢查询、复制延迟）、缓存命中率、负载均衡器、消息队列积压。这一层通常是集成采集——每个组件有现成的 exporter 或采集插件。

4. 外部依赖指标

你的系统依赖的第三方：支付网关、短信通道、云服务的 API。关注它们的可用性、错误率、调用延迟、配额消耗。第三方挂了不是你的故障，但你的用户照样受影响——监控它们是为了快速定界"是我挂了还是他挂了"。

什么是监控（Monitoring）？

监控是把指标持续采集、存储、可视化、分析起来，让你理解系统行为的完整过程。一套监控系统的标准链路：

1. 采集（Collection）：从各层级拉取或接收数据——主机、应用、中间件、外部依赖。
2. 存储（Storage）：时序数据库，要扛得住高基数写入和长时间范围查询。
3. 可视化（Visualization）：仪表盘把数据变成人能快速扫读的趋势图。好的仪表盘按"概览 → 下钻"组织，而不是把所有图堆在一屏。
4. 分析（Analysis）：对比基线、识别异常模式、定位关联性——这一步越来越依赖机器辅助，纯靠人盯图的时代过去了。

什么是告警（Alerting）？

监控让人看懂系统，告警让系统在需要人介入时主动叫人。告警是监控体系里最容易做砸的部分——配少了漏报，配多了狼来了。

设告警的几条原则：

• 告警要对应"需要人立即行动"的事。能自愈的、纯信息性的，进仪表盘不进告警。
• 基于症状而非原因。告"用户请求错误率超过 2%"，而不是"某台机器 CPU 高"——CPU 高但用户无感时，不该半夜叫醒人。
• 每条告警都该有处理手册（runbook）。收到告警的人下一步做什么，应该不需要思考。
• 分级。P1 打电话、P2 发 IM、P3 进工单，不是所有异常都值得打断睡眠。

告警疲劳是真实存在的组织病——天天被无效告警轰炸的团队，最终会开始忽略告警，然后漏掉真正重要的那条。治理方法见本系列《防止告警疲劳》一篇。

现代系统里监控的边界

微服务、容器、Serverless 让系统从"几台可知的服务器"变成"几百个短暂存在的实例"，传统监控的思路遇到了真实的边界：

• 实例是短暂的：容器可能只活几分钟，基于"机器"的监控视角失效。
• 基数爆炸：标签组合（pod × 接口 × 状态码）轻易突破百万级时间序列。
• 分布式因果：一次用户请求穿过十几个服务，单点指标无法回答"为什么慢了"。

这就是为什么现代可观测性在指标之外还要结合日志和链路追踪（Tracing）——指标告诉你"出事了"，日志告诉你"发生了什么"，追踪告诉你"慢在哪一段"。三者关联，才是完整答案。

用观测云落地这套体系

观测云把上述三个支柱做成了开箱即用的闭环：

• 采集：DataKit 一个采集器覆盖主机、容器、数据库、中间件等数百种集成，应用侧用 APM 探针或 OpenTelemetry 直传。
• 存储与可视化：指标、日志、Trace 统一存储，拖拽式仪表盘与模板市场。
• 告警：监控器支持阈值、突变、区间、无数据（心跳）等多种检测，告警走钉钉/企微/飞书/Webhook 分级通知。
• 关联分析：指标异常一键跳到相关日志和 Trace，三层数据不再割裂。

最后

指标、监控、告警不是三个工具，而是一套思维方式的三个环节：量化系统状态、持续观察趋势、在需要人时叫人。先想清楚"这个系统坏掉时用户会怎样"，再倒推该看什么指标、设什么告警——从症状出发，而不是从数据出发。

常见问题（FAQ）

Q：指标、日志、链路追踪应该先建哪个？
A：指标成本最低、见效最快，先建；日志通常已有积累，第二步统一采集；链路追踪投入最大，在微服务规模上来后再补。观测云三者统一存储，可以按这个节奏逐步接入。

Q：告警阈值设多少合适？
A：别拍脑袋。先让监控跑一两周拿到基线，阈值设在"明显偏离正常波动"的位置；然后持续根据误报/漏报情况回调。固定阈值搞不定的场景用动态阈值或突变检测。

Q：监控数据要存多久？
A：分用途：排障需要近 7-14 天的高精度数据；容量规划要 3-12 个月的聚合数据；合规另算。观测云支持按数据类型配置存储策略，高精度短存 + 降采样长存是经济型标配。