java日志需集成分布式链路追踪，核心是通过mdc注入traceid/spanid，并在日志模板中输出；配合sleuth或opentelemetry实现自动埋点，手动打点记录业务耗时；对接skywalking/elk/arms等平台完成日志与链路关联；注意异步线程传递及http调用透传。
Java 日志要结合分布式链路追踪查看耗时，核心是让日志带上链路唯一标识（如 traceId、spanId），并在链路追踪系统（如 SkyWalking、Zipkin、Jaeger 或阿里 ARMS）中关联日志与调用链路。这样就能在看到慢请求的调用链时，直接下钻查看对应日志，定位耗时瓶颈。
确保日志框架自动注入 traceId 和 spanId
主流日志框架（Logback、Log4j2）可通过 MDC（Mapped Diagnostic Context）动态注入链路信息。需配合 OpenTracing / OpenTelemetry SDK 或 Spring Cloud Sleuth（已整合于 Spring Boot 3+ 的 Micrometer Tracing）使用：
- 引入依赖：如
micrometer-tracing-bridge-brave+logback-classic，或opentelemetry-extension-trace-propagators+opentelemetry-sdk - 配置 Logback 的
%X{traceId}和%X{spanId}到日志 pattern 中，例如：%d{HH:mm:ss.SSS} [%X{traceId},%X{spanId}] [%thread] %-5level %logger{36} - %msg%n - 确保 Web 过滤器或全局拦截器（如
TraceFilter）在请求入口处创建并激活 Span，MDC 才能自动填充
在关键节点打点记录耗时（手动埋点）
自动链路只能看到接口级或 RPC 级耗时；若需分析某段业务逻辑（如 DB 查询、远程调用、复杂计算）的具体耗时，需手动打点并写入带 traceId 的日志：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 用
System.nanoTime()计算毫秒级耗时，避免System.currentTimeMillis()的时钟回拨干扰 - 在方法开始和结束处记录日志，例如：
log.info("queryUser start, userId={}", userId);
... // 执行逻辑
long cost = (System.nanoTime() - startNanos) / 1_000_000;
log.info("queryUser end, userId={}, cost={}ms", userId, cost); - 确保这些日志也走同一 MDC 上下文（通常只要在同一线程且未显式清理 MDC 就会继承）
对接日志采集与链路追踪平台
光有 traceId 不够，还需让日志和链路数据能被同一个平台索引和关联：
- SkyWalking：开启
log-reporter插件，将日志通过 gRPC 推送到 OAP；配置log.tag.format提取traceId字段，并在 UI 中开启「日志关联链路」功能 - ELK + Jaeger/Zipkin：用 Logstash 或 Filebeat 解析日志中的
traceId字段，存入 ES；Kibana 中用该字段关联 Jaeger 的 trace 数据（需共用存储或通过 API 联查） - 阿里 ARMS：自动识别标准格式日志中的
traceId，无需额外配置，控制台点击 trace 即可跳转到对应日志上下文
避免常见陷阱
实际落地中容易忽略的关键细节：
- 异步线程（如
CompletableFuture、线程池）默认不传递 MDC，需用ThreadLocal包装或借助Slf4jMDCAdapter的桥接工具（如logbook-spring-boot-starter或自定义Runnable包装器） - Feign/RestTemplate 调用需启用 Sleuth 或 OpenTelemetry 的 HTTP 插件，否则下游服务无法继承 traceId，导致链路断裂
- 日志中不要截断或哈希
traceId，必须保持原始全量字符串（通常是 32 位 hex 或 UUID 格式），否则无法精确匹配
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
