小团队的可观测性：不买 APM 也能把问题定位到行

很多团队一上来就讨论上不上 APM，其实在日均请求量不大的阶段，把三件事做对，就能解决 80% 的定位问题：结构化日志、请求串联、关键指标。

一、日志要能被机器读

`print("user login failed")` 这种日志，人看得懂，机器看不懂。改成一行 JSON，字段固定：时间、级别、trace_id、用户标识、动作、结果、耗时、错误码。这样 `jq` 就能直接筛：

```bash

jq -c 'select(.level=="error")' app.log | jq -r '.trace_id' | sort | uniq -c | sort -rn | head

```

一眼看出哪次请求错得最多。字段固定还有个隐性好处：新人不用学"我们日志长什么样"。

二、请求要能串起来

一个请求进网关、过鉴权、调服务、查库，日志散在四个地方。给每个入口生成 trace_id 放进上下文，所有下游日志都带上它，出问题时 `grep <trace_id>` 一条线拉完。实现成本很低：HTTP 入口取 `X-Request-Id`，没有就生成 UUID，塞进 logger 的默认字段；出站调用把同样的 header 透传下去。

三、指标只留四个黄金指标

延迟、流量、错误率、饱和度。不要一开始就铺几百个指标，没人看。延迟要分位数而不是平均值（P50/P95/P99），平均值会把长尾抹平。错误率按状态码和业务错误码分开看。饱和度对小团队最实用的是：连接池占用、队列长度、磁盘使用率。

四、告警要少而准

告警疲劳比没有告警更糟。原则是：只对"需要人立刻做动作"的事情告警。错误率持续 5 分钟超过阈值、可用性探测连续失败、磁盘 85%、证书 30 天内到期——这些值得叫人。单次 500、偶发超时不需要，进日志里躺着就行。

五、把"查询"做成固定动作

出事故时最浪费时间的不是修，是"到底该看哪里"。提前写好三份查询：某个 trace 的完整链路、某个错误码最近一小时的时间分布、某个接口的 P99 变化。贴在值班手册里，事故时照着敲，比现场想快十倍。

这套东西的投入大概是两三天：日志格式改造半天、trace 透传一天、指标和看板一天。相比动辄几万的 APM 年费，小团队先把这套吃透更划算；等真的需要调用链拓扑、跨服务火焰图了，再上 APM 也不迟——因为那时你已经知道要看什么了。