微服务需日志与链路追踪协同定位跨服务问题：日志追踪绑定请求标识，链路追踪还原调用路径；核心是用trace_id/span_id贯穿全程，通过contextvars透传并注入日志与HTTP头。

为什么需要日志追踪和链路追踪

微服务架构下，一次用户请求常经过多个服务，传统单机日志难以定位问题。日志追踪关注“某条日志属于哪次请求”，链路追踪则还原整个请求路径（从入口到各服务调用顺序、耗时、状态）。二者配合，才能快速排查超时、错误或性能瓶颈。

核心思路：用唯一标识贯穿全程

关键不是记录更多内容，而是让同一次请求的所有日志和调用共享一个上下文标识。最常用的是 trace_id（整条链路唯一） + span_id（当前操作唯一） + parent_span_id（标识调用来源）。

• HTTP 请求进入时生成 trace_id（如用 uuid4()），注入到当前线程/协程的本地存储（threading.local 或 contextvars.ContextVar）
• 每次写日志时，自动读取当前上下文，把 trace_id、span_id 等字段塞进日志 record
• 服务间调用（如 HTTP、gRPC）需透传这些 ID，下游服务解析后继续使用，不覆盖

Python 实现要点（不依赖框架）

以标准 logging + contextvars 为例：

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

• 定义全局 ContextVar 存 trace_id / span_id：
  ctx_trace_id = ContextVar("trace_id", default=None)
• 自定义 logging.Filter，在 filter(record) 中读取 ctx_trace_id 并赋值给 record.trace_id
• 配置 Formatter，输出格式包含 %(trace_id)s
• HTTP 入口（如 Flask 或 FastAPI 中间件）提取 X-Trace-ID 头，设置 ctx_trace_id；若无，则新生成
• 发起下游请求前，在 headers 中带上 {"X-Trace-ID": ctx_trace_id.get(), "X-Span-ID": new_span_id, "X-Parent-Span-ID": current_span_id}

推荐轻量组合方案

不想从零造轮子？可用成熟小而专的库降低复杂度：

立即学习“Python免费学习笔记（深入）”；

• loguru + structlog：loguru 易扩展，structlog 支持绑定上下文键值对，适合结构化日志+trace_id 注入
• opentelemetry-python：符合 OpenTelemetry 规范，自动集成 Flask/FastAPI/aiohttp，支持导出到 Jaeger、Zipkin、Prometheus 等，是目前最主流选择
• jaeger-client：较老但稳定，适合已用 Jaeger 的团队，需手动埋点较多

选型建议：新项目直接上 OpenTelemetry；已有项目想最小改动，优先用 contextvars + 自定义 Filter + loguru。