在分布式系统架构下，请求往往要经过网关、认证、订单、库存、支付等多个服务节点，任何一个环节出现异常都可能造成业务失败。传统的监控手段多关注单台机器或单个服务的 CPU、内存与错误率，一旦问题跨服务传播，孤立的指标和日志就会形成观测空白，导致故障难以快速定位。
为什么监控会出现盲区
监控盲区通常指那些系统已经发生故障或性能退化，但既有监控工具无法揭示原因与影响范围的区域。造成这类盲区的原因首先是服务拆分过细，一次用户操作背后是几十次内部远程调用，如果没有统一标识，各服务的日志就是互不关联的碎片。其次，很多团队只采集了基础设施指标，忽略了业务维度埋点，当订单量下跌时，指标曲线只会显示总体失败数上升，却说不清是优惠券服务超时还是库存扣减死锁。
另一个常见因素是异步与消息队列的广泛使用。请求进入 MQ 后由消费者异步处理，同步链路监控到此中断，若消费者报错仅记录在自身日志中，排查者很难把这条报错和十分钟前用户点击联系起来。再加上容器化后实例随时重建，本地日志未集中收集也会直接丢失，进一步扩大了看不见的角落。
全链路追踪如何串联请求
全链路追踪的核心思路是为每一个进入系统的请求分配全局唯一的 traceId，并在跨服务调用时通过协议头传递该标识，同时为每个内部步骤生成 spanId 记录开始时间、耗时与状态。这样无论请求经过多少应用，都能在追踪后台还原出一张调用拓扑图与耗时瀑布流。例如用户提交订单变慢，追踪系统可直观显示瓶颈在第三方支付接口，而不是自身数据库。
在实际落地中，OpenTelemetry 等标准框架已经帮我们完成了大部分埋点工作，只需在网关统一注入 traceId，下游服务使用 SDK 自动继续传播。需要注意的是，追踪数据量极大，通常要采用头采样或尾部采样控制成本，并保证出错与超长链路一定被保留，否则追踪本身也会变成有选择性的盲采。
日志在盲区排查中的价值
日志是粒度最细的观测数据，它能记录代码层面的变量值、分支判断与异常堆栈，这是追踪指标无法替代的。当全链路追踪把故障定位到某个 span 后，下一步就必须依靠该服务在此期间的详细日志来确认根因。比如追踪显示库存服务返回了 500，日志里才能看到具体是 Redis 连接池耗尽还是 SQL 死锁。
为了让日志真正补齐盲区，必须建立规范：每条日志都要打印 traceId 与 spanId，集中采集到 Elasticsearch 等平台，并支持按标识快速检索。许多团队吃过亏，线上出问题后登录容器去 tail 日志，不仅慢而且实例可能已经销毁。统一的日志管道配合追踪标识，才能实现从宏观路径到微观现场的平滑下钻。
两者协同的最佳实践
将全链路追踪与日志打通，关键动作是在应用日志模板中强制注入追踪字段，并在追踪系统的详情页直接提供跳转查询日志的入口。下表列出了协同方案中各环节的要点：
| 环节 | 追踪侧动作 | 日志侧动作 |
|---|---|---|
| 入口 | 网关生成 traceId 并传头 | 记录接入请求与 traceId |
| 服务内 | SDK 自动建 span | 业务日志打印 spanId |
| 存储 | 追踪库采样存异常链路 | 日志平台按 traceId 建索引 |
| 排查 | 拓扑图点开慢 span | 一键查该 trace 全部日志 |
此外，建议对核心链路设置告警联动：当追踪发现错误率突增，自动提取相关 traceId 并拉出对应日志样本推送给值班人。这种机制能把平均修复时间从小时级压到分钟级，也让原本隐藏在多线程与消息流中的盲区彻底暴露。
落地时的常见误区
有些团队认为上了追踪系统就不需要仔细写日志，结果 span 只记录了接口名，出了错仍然要靠猜。追踪解决的是路径与耗时，日志解决的是内容与状态，二者缺一则盲区仍在。还有团队把所有日志都设为 debug 级别却不采集，真到故障时不降级别就看不到现场，这也是一种自欺欺人的覆盖。
另一个误区是盲目全量采样追踪，导致存储费用爆炸且查询卡顿。正确做法是业务正常时低比例采样，异常与慢请求全留，并以日志补齐细节。只有把成本与覆盖率平衡好，全链路追踪与日志的协同才能长期运转，持续消灭监控盲区。