在一个典型的微服务调用链里，一个用户请求可能穿过网关、鉴权、订单、库存、支付、通知等十几个服务。排查线上超时时，如果系统只把各服务的本地日志按时间顺序打印，开发人员往往需要打开多个日志平台，沿着时间线反复比对。由于时钟偏差、异步线程切换、日志格式不统一等原因，很多关键路径会从视野中消失，这就是监控盲区。要解决这个问题，不能只增加日志量，而是要让每次调用带有一个全局唯一的追踪标识，并让日志与追踪数据能够在同一个上下文中被检索。
一、监控盲区到底从哪来
很多人以为日志打得越多，监控数据越全，问题就一定越容易暴露。实际上盲区恰恰出现在系统之间的缝隙里。一个请求进入网关，网关打印一条访问日志，转发到订单服务后，订单服务又打印一条业务日志。这两条日志如果没有统一关联字段，只能靠时间线猜测先后顺序。机器时钟轻微不同步、日志异步写入延迟、负载均衡重试，都会让时间线错位，最终让排查变成拼图游戏。
另一个容易被忽略的是异步执行。业务代码里用线程池处理库存扣减或者发放优惠券，原始请求的上下文不会自动带到新线程。线程池中打印的日志缺少用户标识、订单号甚至缺少追踪 ID，一旦这些异步任务报错，日志平台里就会出现一条来源不明的错误堆栈。消息队列同理，生产者把消息投递出去后，消费者侧完全是新的本地调用，通常与生产者的日志断层。
指标监控也有局限。CPU、内存、JVM GC、接口 QPS 这类指标能说明整体健康度，但无法回答某个具体请求为什么慢。P99 延迟突然上升，可能是某个下游数据库语句变慢，也可能是第 3 次重试触发了雪崩。没有请求维度的追踪数据，指标只能告诉你出事了，不能告诉你根因在哪里。
所以，要补上盲区，需要把日志和全链路追踪结合起来：用追踪数据还原调用拓扑，用日志数据补全每个节点的业务细节。
二、把一次请求串起来：TraceId 与 Span 的关系
全链路追踪的核心概念并不复杂。一次完整的请求生成一个 TraceId，它在整个调用链中保持不变。每经过一个服务或一个独立操作，就会产生一个 Span，Span 用 SpanId 唯一标识，并且通过 ParentSpanId 指向上一层。比如网关作为根 Span，订单服务是它的子 Span，库存服务又是订单服务的子 Span。这样所有 Span 组合起来就是一棵调用树。
落地时，最简单的方式是在网关或统一入口生成 TraceId，并通过请求头向下游传递。Java Web 项目可以用拦截器读取请求头，如果没有 TraceId 就创建一个，然后写入 slf4j 的 MDC。这样当前请求线程里所有日志都会自动带上 traceId。
public class TraceInterceptor implements HandlerInterceptor {
private static final String TRACE_ID_HEADER = "X-Trace-Id";
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
String traceId = request.getHeader(TRACE_ID_HEADER);
if (traceId == null || traceId.isEmpty()) {
traceId = UUID.randomUUID().toString().replace("-", "");
}
MDC.put("traceId", traceId);
return true;
}
@Override
public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
MDC.remove("traceId");
}
}
上面的逻辑看起来简单，但有几个容易踩的坑。首先，请求头名称要统一，最好用 X-Trace-Id 或 OpenTelemetry 标准的 traceparent 头。如果内部系统混用 X-Request-Id、Trace-Id、traceId 等多个名称，链路会在某一个服务处断开。其次，在 afterCompletion 里清理 MDC 很重要，否则线程被复用后会把上一个请求的 traceId 带到下一个请求，产生误导性的关联。
目前更推荐的方式是直接接入 OpenTelemetry 或 Spring Cloud Sleuth，它们会处理 Span 创建、传播、导出和采样。但理解手动实现有助于排查框架没覆盖到的场景，比如老项目改造、非标准协议或者内部 RPC 框架。自己维护时要注意，TraceId 的生成要足够随机，避免用秒级时间戳或自增数字，否则在高并发下会大量碰撞。
三、日志与追踪的联动：MDC、异步和消息队列
只把 TraceId 写进请求头还不够，业务日志中必须能看到这个值才能发挥联动价值。Logback 和 Log4j2 都支持从 MDC 读取字段。比如在 Logback 的 pattern 中增加 [%X{traceId}]，每行日志就会带上当前线程的追踪标识。如果在日志平台中把 traceId 建为关键字索引，排查时就可以先通过链路查询找到问题 Span，再用同一个 traceId 搜索日志明细。
异步线程是上下文丢失的重灾区。ThreadLocal 的设计决定了子线程不会自动继承父线程的 MDC。如果直接调用 new Thread(task).start() 或者提交到 ThreadPoolExecutor，异步任务里的日志将没有 traceId。一个可靠做法是包装 Runnable，把当前 traceId 传入新线程，执行前重新放入 MDC，结束后恢复原值。
public class TraceRunnable implements Runnable {
private final Runnable task;
private final String traceId;
public TraceRunnable(Runnable task, String traceId) {
this.task = task;
this.traceId = traceId;
}
@Override
public void run() {
String oldTraceId = MDC.get("traceId");
MDC.put("traceId", traceId);
try {
task.run();
} finally {
if (oldTraceId == null) {
MDC.remove("traceId");
} else {
MDC.put("traceId", oldTraceId);
}
}
}
}
更省心的方案是引入阿里巴巴的 TransmittableThreadLocal 或者使用线程池包装工具，它们能自动把父线程的上下文拷贝到子线程。无论哪种方式，都要覆盖所有创建线程和提交任务的入口，否则盲区依然存在。可以用一个全局线程池工厂统一创建线程池，并在代码评审中禁止直接 new Thread。
消息队列的透传同样不能省略。生产者发送消息前，从 MDC 中取出 traceId 放入消息 header。消费者接收到消息后，先把 header 中的 traceId 写入自己的 MDC，再执行业务逻辑。这样异步链路就不会断。Kafka 和 RocketMQ 都支持自定义 header，RabbitMQ 也有消息属性可以用。
String traceId = MDC.get("traceId");
Map<String, Object> headers = new HashMap<>();
headers.put("traceId", traceId);
Message<String> message = MessageBuilder.withPayload(payload)
.copyHeaders(headers)
.build();
kafkaTemplate.send("order-topic", message);
消费者侧要防止空指针：如果消息来自外部系统或者老旧生产者，header 中可能没有 traceId。这时应当生成一个新的 TraceId 并标记为入口 Span，而不是直接 MDC.put("traceId", null)。同时，消费失败重试时不要覆盖原始 traceId，让多次重试保持在同一条追踪链路中，可以更清楚地看到重试次数和失败原因。
@KafkaListener(topics = "order-topic")
public void handle(Message<?> message) {
String traceId = message.getHeaders().get("traceId", String.class);
if (traceId == null || traceId.isEmpty()) {
traceId = UUID.randomUUID().toString().replace("-", "");
}
MDC.put("traceId", traceId);
try {
// 执行业务处理
} finally {
MDC.remove("traceId");
}
}
四、采样、存储与告警联动的落地细节
全量采集追踪数据在生产环境通常不现实。高并发系统每天产生几十亿个 Span，如果全部落库，存储成本会迅速失控。常见的做法是配置采样策略：正常请求只保留百分之几，错误请求和超时请求必须全量保留。这就是尾部采样，它不是简单在入口随机丢弃，而是等到 Span 结束时根据状态决定是否保留整个 Trace。这样即可控制成本，又不会漏掉真正需要排查的异常链路。
日志侧则建议按时间或大小滚动，并给 traceId 建立 keyword 类型索引。不要对 traceId 做分词，否则搜索时可能把完整 ID 切碎。Elasticsearch 中可以用 traceId.keyword 字段精确匹配。保留周期可以根据业务需要设置为 7 到 30 天，同时把错误日志单独接入热数据集群，方便快速查询。
{
"query": {
"bool": {
"must": [
{
"term": {
"traceId.keyword": "9f2c0b3e8d4a4b2f8b9e6d1c8a2f4e0b"
}
}
]
}
}
}
告警联动是最后一步，也是很多团队容易忽视的一环。监控系统发现某个接口错误率超过阈值时，如果只是发一条通知，值班人员仍然要手工翻日志找 traceId。更好的方式是在告警模板中自动附带典型 traceId，点击后直接跳转到追踪平台或日志平台。也可以基于日志关键词触发告警，例如出现 OutOfMemoryError 时，携带最近 5 条相关 traceId。这样不仅知道出事了，还能第一时间进入具体调用链。
最后要避免一个误区：全链路追踪不是银弹。如果业务日志本身只打印了一句错误码，没有入参、出参和关键分支信息，即使有了 traceId，也只能看到哪个 Span 失败，仍然不知道失败原因。追踪负责定位路径，日志负责解释细节，两者缺一不可。落地时应当约定关键服务的日志规范，比如统一打印订单号、用户 ID、耗时、重试次数和下游响应码，并且这些字段同样进入日志平台索引，才能让 traceId 真正成为一条可用的线索。