监控与可观测性的区别

"系统挂了没、响应快不快"这类已知问题，靠监控就能发现；但可观测性更进一步，回答"为什么出问题"——哪怕你事先不知道会出什么问题，也能从系统吐出来的数据里推理出根因。可观测性靠三大支柱：日志（Logs）、指标（Metrics）、链路追踪（Traces）。

一句话区分：监控告诉你"出事了"，可观测性告诉你"出的是什么事、卡在哪一环"。微服务越多，越需要后者——一次请求穿过十几个服务，没有链路追踪根本说不清慢在哪。

本文核心知识点
  • 日志结构化输出、集中采集，按请求 ID 串联。
  • 指标Prometheus 采集 + Grafana 看板，量化健康度。
  • 链路追踪traceId 贯穿，可视化一次请求的完整耗时分布。
  • 告警基于指标设阈值，异常第一时间通知到人。
可观测性配图：蓝色渐变背景左侧一摞发光日志方块，中间三个仪表盘指针图表，右侧链路追踪泳道节点连成彩色轨迹
日志方块、仪表盘、链路泳道——正是可观测性的三大支柱。

日志：结构化与集中采集

打印"用户下单失败了"这种自由文本日志，事后几乎没法检索。要改成结构化日志：每条日志带时间、级别、服务名、请求 ID、用户 ID 等字段，输出成 JSON。再通过日志采集组件把各台机器的日志汇总到中心化存储（如 Elasticsearch），按请求 ID 一搜，就能把一次请求在所有服务里的日志串起来。

// 结构化日志示例（带 traceId，便于串联）
logger.info({
  traceId: "abc123",
  orderId: "9527",
  costMs: 42
}, "下单接口调用成功");

指标：Prometheus 与 Grafana

指标是可聚合的数值：QPS、响应时间分位、错误率、CPU、内存。Prometheus 定时从各服务拉取指标存起来，Grafana 把它们画成看板。重点看分位数（P95/P99）而不只是平均值——平均值正常不代表长尾不慢。服务自己暴露一个 /metrics 接口，Prometheus 来抓，这是最常见的接入方式。

链路追踪：一次请求的全景

链路追踪给每个请求分配一个 traceId，在调用链路上一路透传，每经过一个服务记一个 span（这段叫什么、耗时多少）。最后画出一张瀑布图：一次请求 500ms，到底是网关慢、某个服务慢、还是数据库慢，一目了然。没有它，微服务的性能问题基本是黑盒。

告警：让指标主动找人

有了指标还要设告警规则：错误率超过阈值、P95 响应时间飙升、服务实例掉线，自动推送到企业微信或短信。好的告警要少而准——全是噪音的告警等于没有告警，真正的问题会被淹没。按"影响面 × 严重程度"分级，P0 才电话叫醒，一般异常发群里即可。

三者如何配合定位问题

实战定位顺序通常是：先看指标看板发现"错误率涨了、响应慢了"；再看链路追踪找到慢在哪个服务的哪一段；最后按 traceId 捞日志看具体报错堆栈。三者靠同一个 traceId 打通，从宏观指标钻到微观日志，根因通常很快就出来。