凌晨一点多收到告警时，我正准备关电脑。监控说错误率升了，日志里也确实有异常，可两边像互不认识：我知道系统病了，却不知道是哪一条请求先咳嗽。
那晚翻了将近一个小时日志，最后靠时间戳和几个参数勉强拼出调用链。问题修好以后，我第一件事不是补觉，而是把请求标识加到了入口。
给请求系一根线
现在请求经过网关时会拿到一个唯一标识，之后每个服务都沿用它。结构化日志、错误响应和调用追踪里也带着同一个值。用户再反馈“刚才点了一下没反应”，只要能给出请求标识，我就能顺着这根线往回找。
日志字段不用很多，但要固定。我常留时间、服务名、路由、耗时、错误码和请求标识。以前喜欢把上下文全塞进一段句子里，写的时候痛快，查的时候像在沙堆里找螺丝。
三种数据各做各的事
指标最适合告诉我“哪里冒烟了”。请求量、错误率和高分位耗时一眼就能看出影响范围。平均耗时反而经常骗人，九十九个快请求足够掩护一个慢得离谱的请求。
追踪负责回答“火从哪一层烧起来”。日志则留下现场细节，解释为什么失败。它们单独看都不完整，串在一起才像一段能读懂的故事。
现在偶尔还是会在深夜收到告警，不过至少不用先猜半小时。线上系统不会因为有了监控就不出问题，但排查时能少一点慌乱，已经很值得了。