关键在于统一标识、结构化输出、集中可查：注入唯一Trace ID贯穿调用链，所有服务输出含timestamp、service、trace_id、level、message等字段的JSON日志，并通过DaemonSet/Sidecar采集后，支持按trace_id秒级聚合查询。
容器日志在分布式环境下实现统一追踪，关键不是“把日志收在一起”，而是让每条日志自带可关联的上下文，再通过标准化采集与存储支撑快速检索和链路还原。核心在于三件事：统一标识、结构化输出、集中可查。
注入唯一 Trace ID 贯穿整个调用链
单个请求进入系统时，在网关或入口服务生成全局唯一的 Trace ID（如 UUID 或 OpenTelemetry 标准格式），并通过 HTTP Header（如 traceparent）、gRPC Metadata 或消息体透传到下游所有服务。每个服务在打日志时，必须将该 ID 写入日志字段，不能只靠时间戳或服务名硬匹配。
- 推荐使用 OpenTelemetry SDK 自动注入，避免手动传递出错
- Go/Java/Python 等主流语言 SDK 均支持从上下文提取 trace_id 和 span_id，并自动附加到日志中
- 若无法集成 SDK，至少确保入口服务生成并透传，下游服务显式读取并写入日志 context 字段
输出结构化日志并固定关键字段
所有容器应用必须输出 JSON 格式日志，且包含以下最小必选字段：
minimax-mcp-docker版（适配极空间）
下载
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
- timestamp：ISO8601 格式（如 2026-08-13T19:19:00Z），避免本地时区差异
- service：服务名称（如 payment-service），用于区分来源
- trace_id：与上一步一致，作为跨服务检索主键
- level：ERROR/INFO/WARN/DEBUG，便于分级过滤
- message：简明描述事件，不拼接变量，留作结构化解析
- context（可选但强烈建议）：嵌套对象，存放 request_id、user_id、order_id 等业务维度信息
用 Sidecar 或 DaemonSet 统一采集，避免日志丢失
容器生命周期短，标准输出日志极易随 Pod 销毁而消失。不能依赖 docker logs 或宿主机本地文件。
- 在 Kubernetes 中，优先采用 DaemonSet + Fluentd / Filebeat 模式，每个节点部署一个采集器，实时 tail 容器日志文件（路径通常为 /var/lib/docker/containers/xxx/xxx-json.log）
- 采集器需启用 docker_metadata 插件，自动补全 container_id、pod_name、namespace 等元数据
- 若资源敏感或需更强定制能力，改用 Sidecar 模式：为每个业务容器配一个轻量采集容器（如 fluent-bit），资源隔离、配置独立、故障不扩散
存储与查询层支持按 Trace ID 快速聚合
日志入库后，必须能以 trace_id 为条件，1 秒内拉出整条链路全部日志。
- ELK 方案：Fluentd → Elasticsearch，建索引时将 trace_id 设为 keyword 类型，配合 Kibana 的 Discover 或 Lens 做 trace_id 过滤
- Loki 方案（更轻量）：日志按 label（如 {service="order", trace_id="abc123"}）索引，用 LogQL 查询：{job="kubernetes-pods"} |~ `abc123`
- 无论哪种方案，都应禁用全模糊搜索，强制要求 trace_id 作为第一级过滤条件
