08 · 服务端可观测性:日志 / 指标 / 链路追踪
服务上线后是黑的。可观测性 = 把"黑盒"变成"能查日志、能看指标、能追链路"的白盒。
速览卡
| 项 | 内容 |
|---|---|
| 一句话定位 | 后端三大观测手段:日志讲"发生了什么",指标讲"有多快多慢",链路讲"跨服务怎么走" |
| 核心内容 | 三大支柱、结构化日志、指标与告警、链路追踪、错误率/延迟/流量黄金三指标 |
| 读完能回答 | 线上出问题先看什么?日志怎么搜?链路追踪解决什么? |
| 相关板块 | C12 · 错误处理日志配置 | C05 · 服务架构 | C07 · 性能与容量 |
一、三大支柱
| 支柱 | 回答 | 工具(可选) |
|---|---|---|
| 日志(Logs) | 发生了什么 | ELK / Loki |
| 指标(Metrics) | 有多快、多健康 | Prometheus + Grafana |
| 链路(Traces) | 一个请求跨了哪些服务 | Jaeger / Tempo |
排查顺序:先看告警/指标确认范围 → 看链路定位到服务 → 看该服务日志找根因。
二、黄金三指标
| 指标 | 含义 | 异常信号 |
|---|---|---|
| 错误率 | 5xx 占比 | 突然升高 = 出事了 |
| 延迟 | RT 的 P50/P95/P99 | P99 飙升 = 尾巴变长 |
| 流量 | QPS/RPS | 突增 = 被刷/热点 |
监控的第一要务:把这三个指标的可视化 + 告警搭起来,比任何花哨指标都重要。
三、日志:结构化 + 可检索
延续 C12:JSON 结构化日志 + 统一字段。
json
{"ts":"...","level":"ERROR","logger":"orders","msg":"payment failed","order_id":"42","service":"orders"}约定:日志里带
request_id/trace_id,一个请求的所有日志能串起来搜。这是"链路"的最小形态。
四、指标与告警
4.1 用 Prometheus 思路暴露指标
python
from prometheus_client import Counter, Histogram, start_http_server
REQUESTS = Counter("http_requests_total", "Total requests", ["method", "path", "status"])
LATENCY = Histogram("http_request_duration_seconds", "Latency", ["method", "path"])4.2 告警原则
| 原则 | 说明 |
|---|---|
| 告警要可行动 | 每条告警对应一个处置动作 |
| 别告警轰炸 | 只告警"用户可感知的坏",别刷屏 |
| 分级 | P1 严重(服务挂)/ P2 一般(延迟高) |
类比前端:指标 ≈ 前端监控的性能面板,告警 ≈ 崩溃上报提醒。
五、链路追踪:跨服务的"一次请求全程"
text
网关 ──trace_id=a1──▶ 订单服务 ──▶ 支付服务
└──────▶ 消息队列| 概念 | 说明 |
|---|---|
trace_id | 一次完整请求的全局 ID |
span_id | 每个服务/操作的一段 |
parent_id | 表示父子关系 |
怎么落地:HTTP 请求带
trace_id头,跨服务传递;日志里带上它,链路工具按它拼装。最小可用就是"日志里带 trace_id"。
六、最小可观测落地(个人项目够用)
| 层级 | 做法 |
|---|---|
| 1 | 结构化日志 + 每个请求打 request_id |
| 2 | 暴露 /metrics,接 Grafana 看黄金三指标 |
| 3 | 关键错误告警到 IM/邮件 |
| 4 | 需要跨服务排查时再上链路追踪 |
别一开始就搭全家桶。先让"日志可搜 + 指标可看 + 错误可告警",链路等真拆服务再加。
自检清单
- [ ] 能说清日志/指标/链路各回答什么问题
- [ ] 会给服务打结构化日志并带
request_id/trace_id - [ ] 知道黄金三指标(错误率/延迟/流量)和 P99
- [ ] 会暴露
/metrics并看懂基本指标 - [ ] 能设计"日志可搜 + 指标可看 + 错误可告警"的最小落地
常见误区
- 误区:日志越多越好。 没结构的日志只是噪音,关键是可检索、带上下文。
- 误区:只看平均延迟。 看 P95/P99,尾巴才是体验。
- 误区:监控 = 一堆面板没人看。 面板没有告警 = 出事时才发现。
- 误区:链路追踪和日志二选一。 配合用:链路定位到服务,日志找根因。
动手练习
练习 A:给服务加 request_id
写一个中间件给每个请求生成 request_id 并打进所有日志,验证一次请求的日志能串起来搜。
练习 B:暴露指标
给服务暴露 /metrics(请求数/延迟),本地用 Prometheus + Grafana 看一张面板。
练习 C:告警
给"错误率 > 5%"配一条告警,故意制造错误确认触发。
相关文档
本区
- 12 · 错误处理日志配置 —— 日志怎么打
- 05 · 服务架构 —— 跨服务时为什么要链路
- 07 · 性能与容量 —— 延迟指标怎么用
其他域
- 12 · 前端可观测性与线上排障 —— 前端监控对照