可观测性不是装监控：给分布式服务设计追踪、指标与告警的完整方法

凌晨三点，告警群里同时弹出十几条消息，接口成功率在下降，错误日志在暴涨，客服工单也在增加。值班工程师打开监控面板，曲线都在波动，却没有一条信息能直接回答最关键的问题：到底是哪个服务、哪一次调用、哪一个下游依赖出了问题。团队花了四十多分钟才定位到一次数据库慢查询引发的连锁超时，而这段时间里，真正能帮助定位的不是监控的数量，而是监控之间的关联。这就是很多团队的真实状态：仪表盘很多，告警很多，日志很多，可观测性却很弱。本文要讲的，就是如何把可观测性从工具堆砌变成一套可落地的工程方法。

一、从故障复盘开始：先问三个问题

在动手接入任何工具之前，先回答三个问题。第一，用户受影响的表现是什么，是页面打不开、接口变慢，还是订单偶发失败。不同的表现对应不同的黄金信号，不能用同一套阈值去覆盖。第二，故障的传播路径是什么，请求经过网关、业务服务、缓存、数据库和第三方接口，哪一环最先恶化，哪一环放大了影响。第三，事后需要复现什么，是一次请求的完整链路、某个时间段的指标变化，还是特定用户的操作序列。这三个问题的答案，决定了追踪要采哪些跨度，指标要按哪些维度聚合，日志要保留哪些字段。没有这一步，后续所有工作都容易变成为了采集而采集。复盘时还有一个常见误区，就是把根因写成某一个组件故障。分布式系统里的故障很少是单点问题，更多是超时、重试、队列积压和资源竞争叠加的结果。可观测性的价值，恰恰在于把这种叠加过程还原出来，让团队看到时间线上的因果关系，而不是只看到最终崩溃的那一个点。

二、追踪：让一次请求说出完整故事

分布式追踪的核心不是记录所有调用，而是让一次请求能够被完整还原。入口服务生成全局唯一的追踪标识，后续每一次内部调用、数据库访问、消息发送都携带这个标识，各个服务把自己的跨度上报到同一个追踪系统。这样，值班人员输入一个追踪标识，就能看到请求在每个环节花了多长时间，哪个环节返回了错误，哪个环节被重试。没有这个标识，日志只能按时间拼凑，跨服务的因果关系基本靠猜。

在实现上，有几个细节决定成败。首先是上下文传递，异步任务、消息队列和线程池切换时最容易丢标识，必须在框架层面统一处理，不能依赖每个业务开发手动传递。其次是采样策略，全量采集在高流量下成本极高，也会拖慢系统，常见做法是按比例采样，同时对错误请求和慢请求全量保留，这样既控制了成本，又不丢失关键样本。再次是跨度命名，跨度名称要稳定、可聚合，例如用服务名加操作名，而不是把用户标识或订单号写进名称，否则聚合结果会被碎片化。最后是敏感信息，追踪里不要记录密码、令牌和完整的用户隐私字段，记录必要的业务标识就足够了。

追踪落地的检验标准很简单：随机挑一个线上错误，能否在五分钟内找到完整链路，能否说清耗时分布和错误首次出现的位置。如果做不到，说明追踪覆盖还不完整，或者采样把关键请求丢掉了。

三、指标：先定服务等级目标，再选黄金信号

指标最容易走偏的方向，是先把所有能采集的数字都采集回来，再去想怎么用。正确顺序正好相反，先定义服务等级目标，再围绕目标选择指标。常见的黄金信号包括延迟、流量、错误和饱和度。延迟要看分位数而不是平均值，因为平均值会掩盖长尾问题，百分之九十五和百分之九十九分位数的恶化，往往比平均值更早反映用户体验下降。流量要区分请求量和并发量，错误要区分业务错误和系统错误，饱和度则要关注队列长度、连接池使用率和CPU与内存的余量。

指标的维度同样重要。按服务、接口、版本和机房聚合，才能在出问题时快速缩小范围。维度太少，定位只能停留在服务级别；维度太多，基数爆炸会让存储和查询成本失控。一个实用的原则是，核心维度控制在五个以内，业务维度只在确实需要下钻时再加。另外，指标命名要统一规范，单位要明确，计数器和计量器不要混用，否则后续做告警和看板时，每个人对同一个数字的理解都会不一样。

服务等级目标的另一个作用，是给告警提供判断依据。没有目标的告警只能凭感觉设阈值，阈值一松就漏报，一紧就误报。有了目标，就可以按错误预算来管理：预算充足时优先做功能迭代，预算快耗尽时优先做稳定性工作。这样，可观测性就从技术工具变成了团队共同的决策语言。

四、日志：结构化、关联化、可检索

日志的常见问题不是太少，而是太杂。同一类事件在不同服务里字段名称不同、时间格式不同、级别定义不同，出了问题只能靠关键词搜索碰运气。结构化日志的第一步，是统一字段，例如时间、服务名、追踪标识、用户标识、操作、结果和耗时，用统一的格式输出。这样，日志系统才能按字段过滤和聚合，而不是把日志当成纯文本去翻。

日志与追踪的关联同样关键。日志里带上追踪标识后，从指标异常可以跳到追踪链路，再从链路跳到对应服务的详细日志，排查路径就变成了一条线。反过来，日志里如果没有追踪标识，即使日志量再大，也很难还原一次请求的完整过程。另外，日志级别要分清，调试信息只在开发和灰度环境开启，生产环境默认只保留信息、警告和错误级别，避免调试日志淹没真正重要的信号。

日志保留策略也要提前设计。不同级别的日志保留时间可以不同，错误日志保留更久，普通访问日志可以按采样保留，合规要求的数据还要考虑脱敏和访问权限。保留不是越久越好，成本和查询性能同样是工程约束。

五、告警与值班：把信息变成行动

告警的目标不是让人知道系统出了问题，而是让人知道该做什么。好的告警至少包含四个要素：影响范围、当前指标、已经确认的链路或日志链接、以及第一步处理建议。只写服务名和阈值的告警，值班人员每次都要重新排查，响应时间自然很长。告警还要分级，致命级别需要立即电话或短信通知，警告级别可以在工作群里提醒，信息级别只记录不打扰。分级不清的结果，就是所有告警都被当成噪音。

告警的另一个关键是抑制和收敛。同一个根因引发的多个告警应该合并成一条，正在处理中的告警不要反复重复通知，依赖服务的告警要按依赖关系排序。否则，值班人员在故障高峰期会被告警淹没，反而错过真正重要的那一条。定期复盘告警同样重要，每周统计误报率和平均响应时间，删除长期无人处理的告警，调整长期误报的阈值。

值班流程的最后一环，是把每一次故障变成可观测性的改进项。复盘时不要只写修复了哪个缺陷，还要写清楚当时缺了哪一条追踪、哪一个指标、哪一个告警，下一次如何提前发现。长期坚持下来，团队的可观测性会越来越贴近真实故障，而不是停留在仪表盘的数量上。

结论：可观测性不是一次性项目，而是一套持续演进的工程习惯。从故障复盘出发，用追踪还原请求，用指标衡量目标，用日志补充细节，用告警驱动行动，四个环节形成闭环，系统才会越跑越稳，值班才会越来越从容。