代码上线了，你长舒一口气。但半小时后，用户群里有人喊”网站好卡”。你慌了：卡在哪？是数据库慢了？还是某个接口炸了？还是服务器内存爆了？你盯着屏幕，却什么也看不见——因为服务对你来说是个黑盒。

这就是”监控”要解决的问题。更现代的说法叫 可观测性（Observability）：通过系统对外暴露的数据，推断它内部到底发生了什么。可观测性有公认的三根支柱，记住它们，你就有了排查问题的”三把钥匙”。

第一支柱：指标（Metrics）——“系统整体健不健康”

指标是随时间变化的数值，用来回答”系统现在整体状态如何”。比如：CPU 使用率 75%、每秒请求数 1200、接口平均响应 200ms、错误率 0.5%。

指标的特点是聚合、低成本、适合看趋势。它不记录”某一次具体请求”的细节，而是成千上万次请求的统计结果。你靠它快速判断：“现在是不是出问题了”。

常见指标分四类，业界叫 RED/USE 模型：

• RED（对请求类服务）：Rate（请求速率）、Errors（错误率）、Duration（响应耗时）。
• USE（对资源类，如 CPU/内存）：Utilization（利用率）、Saturation（饱和度，队列积压）、Errors（错误数）。

指标最适合做仪表盘和告警：比如”错误率超过 1% 就报警”。但它回答不了”为什么”，只能告诉你”出问题了”。

第二支柱：日志（Logging）——“具体发生了什么”

日志是程序运行时打印的一条条文字记录，比如 "用户123登录失败，原因：密码错误"、"订单456创建耗时2.3s"。它回答”某次具体事件到底发生了什么”。

日志的特点是详细、原始、量大。它是最传统的排查手段——服务挂了，第一反应就是翻日志。但日志也有坑：如果没规范，满屏 console.log 反而找不到重点；量太大存不下、查得慢。

好的日志实践：

• 结构化：用 JSON 格式而不是纯文本，方便机器检索。例如 {"level":"error","user":123,"msg":"登录失败"}。
• 带上下文：每条日志带上 request_id、用户 ID、时间，方便串联。
• 分级：debug/info/warn/error 分级，生产环境一般只看 warn 以上。

第三支柱：链路追踪（Tracing）——“一次请求穿越了哪些服务”

现代系统往往是微服务：一个”下单”请求，可能先后经过网关、用户服务、订单服务、库存服务、支付服务。哪个环节慢了？光看指标和日志很难定位，因为问题分散在多个服务里。

链路追踪就是给一次请求发一个 Trace ID，它穿过所有服务，把每个服务的处理片段（叫 Span）串成一条完整的时间线。你一眼就能看出：“下单慢，是因为库存服务那一段花了 3 秒”。

打个比方：指标像”体温计”（知道发烧了），日志像”病历本”（知道某次具体症状），链路追踪像”全身 CT 扫描”（知道病根在哪个器官）。三者互补，缺一个都不完整。

三者怎么配合：一个真实排查流程

假设告警说”下单接口错误率飙升”。典型排查路径：

1. 看指标（Metrics）：确认错误率确实涨了，且集中在 POST /orders 接口，响应时间也变长。→ 知道”出问题了，在哪”。
2. 看链路（Tracing）：点开一条慢请求，发现 80% 时间花在”库存服务”调用上。→ 锁定”病根在哪个服务”。
3. 看日志（Logging）：去库存服务的日志里搜对应 request_id，发现报错 connection pool exhausted（连接池耗尽）。→ 找到”具体原因”。

你看，指标定位范围 → 链路锁定服务 → 日志查明原因，三支柱接力，问题无所遁形。

常见认知误区

• “有日志就够了，不用指标”：日志量大、查得慢，半夜告警你不可能去翻几 GB 日志。指标能秒级告诉你”出问题了”，是告警的基础。
• “监控就是装个监控软件”：监控是”指标+日志+链路+告警+ dashboard”一整套体系，不是装一个工具就完事。
• “链路追踪只有微服务才需要”：单体应用也能用，尤其当你想看”一个请求里各函数耗时”时，追踪一样有用。
• “采集越细越好”：过细的采集会拖垮性能、撑爆存储。按”关键路径 + 合理采样率”来，别全量无脑采集。

主流工具地图（先混个脸熟）

• 指标：Prometheus（采集）+ Grafana（展示），下一篇细讲。
• 日志：ELK（Elasticsearch+Logstash+Kibana）或轻量的 Loki。
• 链路：Jaeger、Zipkin，或云厂商的 APM。

不用现在全学，记住”三支柱分别解决什么问题”这个框架，以后遇到哪个工具都知道它归在哪一类。

小测验：看看你掌握了没

• 问题一：指标、日志、链路分别回答什么问题？答案：指标回答”整体健不健康”，日志回答”具体发生了什么”，链路回答”一次请求穿越了哪些服务、哪段慢”。
• 问题二：RED 模型指哪三个？答案：Rate（请求速率）、Errors（错误率）、Duration（响应耗时）。
• 问题三：一个错误率告警该怎么用三支柱接力排查？答案：指标定位接口 → 链路锁定慢服务 → 日志查明具体报错。

这一篇你该记住的

• 可观测性三支柱：Metrics（整体健康）、Logging（具体事件）、Tracing（请求链路）。
• 指标聚合低成本、看趋势做告警；日志详细原始、查具体原因；链路串联多服务、定位慢环节。
• 排查接力：指标定位范围 → 链路锁定服务 → 日志查明原因。
• 日志要结构化、带上下文、分级；采集讲究关键路径与采样，非越细越好。
• 工具只是载体，先建立”三支柱”框架，再认工具不迟。

下一篇我们落地第一支柱：用 Prometheus 采集指标 + Grafana 画仪表盘，亲手看到服务的实时曲线。