微服务需日志与链路追踪协同定位跨服务问题：日志追踪绑定请求标识，链路追踪还原调用路径；核心是用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 为例：
- 定义全局
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。
