监控体系设计原则：黄金指标与分层架构
监控体系设计，说白了就是回答三个问题：系统跑得稳不稳？哪里出了问题？影响有多大？ 我做了这么多年量化系统，见过太多团队一上来就堆监控指标，结果告警比业务消息还多，最后大家干脆把告警群屏蔽了——这完全背离了监控的初衷。
今天我们就聊聊监控体系设计的两大核心：黄金指标和监控分层。这两块搞明白了，你的监控系统才算真正有了骨架。
一、黄金指标：四个维度看透系统健康
Google 的 SRE 团队总结过四个黄金指标，我个人觉得非常实用。你想想看，一个系统无论多复杂，最终关心的无非就是：快不快、多不多、对不对、够不够。
| 黄金指标 | 核心关注点 | 典型度量 | 我踩过的坑 |
|---|---|---|---|
| 延迟（Latency） | 请求处理速度 | P50/P95/P99 耗时 | 只看平均值，忽略了长尾 |
| 吞吐量（Throughput） | 系统处理能力 | QPS、TPS、消息数/秒 | 高峰期吞吐骤降，才发现连接池满了 |
| 错误率（Error Rate） | 请求失败比例 | HTTP 5xx、超时、业务异常 | 业务错误码没纳入监控，漏了关键告警 |
| 资源利用率（Saturation） | 资源是否够用 | CPU、内存、磁盘、网络 | 磁盘空间报警时，日志已经写不进去了 |
1. 延迟：别被平均值骗了
延迟监控，我建议重点关注 P99 和 P95。为什么？因为平均值会掩盖真相。举个例子，100 个请求里 99 个 1ms，1 个 10s，平均值才 100ms 左右，看起来还行对吧？但那个 10s 的请求可能已经让用户崩溃了。
实战经验：我在做因子计算引擎时，发现 P50 延迟只有 200ms，但 P99 高达 8s。一查才发现，有个因子依赖的外部数据源偶尔会超时重试。后来加了超时熔断，P99 直接降到 500ms 以内。
2. 吞吐量：关注峰值和趋势
吞吐量监控，不能只看当前值。我习惯同时看 5 分钟均值 和 1 分钟峰值。为什么？因为均值平滑了毛刺，但峰值才能暴露瓶颈。
举个例子，你的系统平时 1000 QPS 跑得好好的，突然某分钟飙到 5000 QPS，虽然均值还是 1200，但那一分钟可能已经触发了限流。如果不看峰值，你根本不知道系统在「擦边球」运行。
3. 错误率：区分「真错误」和「假报警」
错误率监控，最怕的就是「狼来了」。我见过一个团队，把 HTTP 404 也当成错误告警，结果每天几百条告警，真正的 500 错误反而被淹没了。
我的建议：错误率一定要分层。基础设施错误（如连接超时）和应用层错误（如业务校验失败）分开告警。业务错误码也要纳入监控，我曾经因为漏了「数据不存在」这个业务错误码，导致一个数据源挂了 2 小时才发现。
4. 资源利用率：提前预警，别等爆了再处理
资源利用率监控，核心是 设置水位线。比如磁盘使用率，我一般设三个阈值：
- 警告线（70%）：通知运维关注，准备清理
- 严重线（85%）：触发自动清理脚本
- 紧急线（95%）：直接告警到值班手机
避坑指南：我曾经把磁盘告警阈值设在 90%，结果某次日志暴增，等告警发出时磁盘已经满了，系统直接 OOM。后来我改成 70% 预警，留足缓冲时间。
二、监控分层：从底层到业务，层层递进
监控不能只盯着一个层面。我习惯把监控分成三层：基础设施层、应用层、业务层。每一层关注的点不同，告警的优先级也不同。
核心思路：下层告警可能影响上层，但上层告警不一定能定位到下层。所以排查问题时，从下往上查；设计告警时，从上往下定级。
1. 基础设施层：地基稳不稳？
这一层关注的是硬件和系统资源。说白了，就是服务器、网络、存储这些「硬家伙」有没有出问题。
- CPU：使用率、负载、上下文切换
- 内存：使用率、Swap、OOM 事件
- 磁盘：使用率、IOPS、读写延迟
- 网络：带宽、丢包率、连接数
基础设施层的告警，我建议直接接入 PagerDuty 或类似工具，7x24 小时值班。因为底层出问题，往往影响面最大。
2. 应用层：代码跑得对不对？
这一层关注的是应用本身的运行状态。包括：
- 服务状态：进程是否存活、端口是否监听
- 接口性能：每个 API 的延迟、吞吐量、错误率
- 依赖健康：数据库、缓存、消息队列的连接状态
- JVM 指标：GC 次数、堆内存、线程数（Java 应用）
个人经验：应用层监控，我强烈建议加上「依赖健康检查」。有一次数据库主从切换，应用层所有接口都超时了，但进程还在、端口也通，基础设施层完全没告警。要不是依赖健康检查发现了数据库连接异常，排查起来得花半天。
3. 业务层：用户感受到什么？
这一层是最容易被忽略的，但也是最重要的。因为基础设施和应用层都正常，不代表业务没问题。
业务层监控关注的是：
- 核心业务流程：比如因子计算是否按时完成、交易信号是否正常发出
- 业务指标：比如今日新增因子数、策略运行数量、数据源更新延迟
- 用户体验：比如页面加载时间、操作成功率
避坑指南：我曾经遇到过一个案例：所有服务器指标都正常，应用日志也没有错误，但用户反馈说「数据一直不更新」。后来一查，是上游数据源改了接口格式，我们的解析器没适配，导致数据写入失败。但因为错误被静默处理了，业务层没有任何告警。从那以后，我坚持每个核心业务都要有独立的健康检查。
三、知识体系结构图
下面这张图，是我对监控体系设计原则的总结。你可以把它当作一个检查清单，设计监控系统时逐项对照。
四、总结：监控设计的三个原则
最后，我总结三条设计原则，你可以贴在工位上：
- 指标可量化：每个指标都要有明确的度量方式和阈值。不要说「系统有点慢」，要说「P99 延迟超过 2s」。
- 告警可行动：收到告警后，必须知道下一步做什么。如果告警信息只是「CPU 高」，那和没告警一样。要带上「建议操作：检查是否有异常进程」。
- 分层不重叠：每层关注点清晰，避免重复告警。比如基础设施层告警了磁盘满，应用层就别再告警「日志写入失败」了，否则就是噪音。
最后说一句：监控系统不是建完就完事了。我每季度都会做一次「告警复盘」，把那些从来没触发过的告警删掉，把那些误报率高的规则调优。监控系统也需要持续迭代，就像你的代码一样。
公众号：蓝海数据掘金营，微信 deep3321