监控系统基础：核心指标、分类与数据模型
各位同学，今天我们来聊聊监控系统最基础的东西。说实话，很多人在搭建监控系统时，一上来就堆工具、配告警，结果发现要么告警轰炸，要么关键故障没发现。我当年也踩过这个坑。
监控系统要解决的核心问题其实很简单：系统到底跑得怎么样？出问题了能不能快速定位？ 围绕这两个问题，业界总结出了一套方法论。今天我就把这块掰开揉碎了讲清楚。
一、四大黄金信号：监控的“体检指标”
Google 的 SRE 团队总结过四个核心指标，圈内叫“四大黄金信号”。说白了，你只要把这四个维度盯住了，系统健康度就能掌握个八九不离十。
| 黄金信号 | 核心含义 | 我常用的指标 |
|---|---|---|
| 延迟（Latency） | 请求处理耗时 | P99、P95、平均延迟 |
| 流量（Traffic） | 系统承载的请求量 | QPS、RPS、带宽使用率 |
| 错误（Errors） | 请求失败率 | HTTP 5xx、4xx、业务错误码 |
| 饱和度（Saturation） | 资源使用程度 | CPU、内存、磁盘、连接数 |
重点提醒： 延迟和错误是最容易出问题的两个信号。我见过太多团队只盯着 CPU 和内存，结果用户反馈页面打不开，一看延迟已经飙到 10 秒了，CPU 才 30%。
延迟，我习惯分两层看：客户端感知的延迟和服务端处理延迟。有时候服务端处理很快，但网络抖动导致客户端觉得慢。嗯，这个坑我踩过——有一次排查了半天，最后发现是 CDN 回源超时。
流量，不只是看总量。我建议按接口、按来源、按用户维度拆开看。为什么？因为某个爬虫突然刷量，总量可能只涨了 20%，但那个接口的延迟可能已经翻倍了。
错误，这里有个细节：HTTP 500 是错误，但业务返回码为 200 但内容为空，算不算错误？我个人觉得算。我在项目中遇到过，支付回调返回 200，但 body 里写着“余额不足”，这种业务错误比 500 更隐蔽。
饱和度，说白了就是资源还有多少余量。我习惯看“接近极限”的指标，比如内存使用率超过 80% 就要关注了，超过 90% 就得准备扩容。你想想看，等到 100% 再处理，系统已经挂了。
二、监控的分类：白盒 vs 黑盒
监控系统按数据来源，可以分为两大类：白盒监控和黑盒监控。这两个概念，我刚开始也搞混过，后来在实战中才真正理解它们的区别。
黑盒监控：从外部看系统
黑盒监控，就是站在用户的角度，从外部探测系统是否可用。你不需要知道系统内部怎么实现的，只需要知道“这个接口能不能访问”、“这个页面能不能打开”。
常用的手段：
- HTTP 健康检查（比如 curl 某个 URL）
- TCP 端口探测
- 模拟用户操作（比如登录、下单流程）
- Ping、Traceroute 等网络探测
我的经验： 黑盒监控适合做“第一道防线”。我曾经用黑盒监控发现某个微服务的健康检查接口返回 200，但实际业务接口已经 502 了。为什么？因为健康检查接口写死了返回“ok”，根本没检查依赖的数据库是否正常。所以，黑盒监控的探测点一定要覆盖真实业务路径。
白盒监控：从内部看系统
白盒监控，就是深入到系统内部，采集各种内部指标。比如 JVM 的 GC 次数、数据库的连接池状态、Redis 的命中率等等。这些数据只有系统内部才知道。
常用的手段：
- 应用埋点（比如 Prometheus 的 client 库）
- 日志采集（比如 ELK 或 Loki）
- 系统指标采集（比如 node_exporter）
- APM 工具（比如 SkyWalking、Jaeger）
注意： 白盒监控的数据量通常很大，采集频率要合理。我见过有人把 JVM 的 GC 详情每秒采集一次，结果监控系统自己先扛不住了。建议：核心指标 10-15 秒采集一次，非核心指标 1-5 分钟采集一次。
黑盒和白盒怎么配合？我举个例子：黑盒发现某个接口超时了，白盒告诉你这个接口的数据库连接池满了。你看，一个告诉你“出事了”，一个告诉你“为什么出事”。两者缺一不可。
三、监控数据模型：怎么存、怎么查
聊完了指标和分类，我们得说说数据模型。监控数据本质上是一堆带时间戳的数值，但怎么组织这些数据，决定了你的监控系统好不好用。
目前主流的监控数据模型有三种：
| 模型 | 代表系统 | 特点 |
|---|---|---|
| 指标（Metrics） | Prometheus、Graphite | 数值型、可聚合、适合趋势分析 |
| 日志（Logs） | ELK、Loki | 文本型、包含上下文、适合排查问题 |
| 链路（Traces） | Jaeger、Zipkin | 请求级、展示调用链、适合性能分析 |
指标模型，说白了就是“时间序列数据”。每条数据包含：指标名、标签（key-value）、时间戳、数值。比如：
http_requests_total{method="GET", endpoint="/api/user", status="200"} 1024 1690000000这个模型的好处是查询效率高，适合做聚合和告警。我习惯用 Prometheus 的 PromQL 来做各种计算，比如“过去 5 分钟的错误率”这种。
日志模型，就是记录系统运行过程中发生的事件。每条日志包含时间戳、级别、来源、消息内容。日志的优点是信息丰富，缺点是不好做数值聚合。你想想看，要从几万条日志里统计出错误率，那得多慢。
链路模型，是分布式系统的“X 光片”。它记录一个请求从入口到各个微服务的完整路径，包括每个环节的耗时。我在排查慢请求时，链路追踪是神器——一眼就能看出哪个环节最慢。
我的建议： 不要试图用一个工具解决所有问题。Prometheus 管指标，ELK 管日志，Jaeger 管链路，三者配合才是最佳实践。我曾经见过有人把日志塞进 Prometheus，结果存储爆炸了——因为 Prometheus 根本不适合存文本数据。
最后说一句，数据模型的选择会影响你的存储成本和查询性能。我个人习惯：指标数据保留 30 天，日志数据保留 7-15 天，链路数据保留 3-7 天。超过这个时间，要么归档，要么直接丢弃。毕竟，监控的目的是发现问题，不是当数据仓库。
好了，这一章的内容就到这里。下一章我们会聊聊具体的监控工具选型，以及怎么搭建一套生产级的监控体系。到时候我会分享一些我在实际项目中踩过的坑，保证让你少走弯路。