容器化服务可观测性需打通链路追踪与指标，通过统一上下文（如Trace ID、服务名、环境标识）实现数据关联与下钻；采用SLO驱动的动态采样优化开销；分层采集基础设施、运行时和应用行为指标；故障定位依赖“指标→追踪→日志”闭环下钻。
容器化服务的可观测性不能只靠单点工具堆砌，关键在于把链路追踪和指标真正打通，形成可下钻、可关联、可验证的数据闭环。
用统一上下文串联追踪与指标
链路追踪（Trace）和指标（Metrics）必须共享同一套语义上下文，否则无法交叉分析。核心是让每个请求携带一致的 Trace ID，并在指标采集时自动注入服务名、实例标签、环境标识（如 prod-us-east）、甚至业务维度（如 order_type=premium）。Prometheus 的指标需配置 relabel_configs 将 OpenTelemetry Collector 注入的 trace_id 或 service.namespace 等字段作为 label；Jaeger 或 Tempo 的追踪数据也需确保 span 中包含与指标相同的 job、instance、pod_name 等标识。这样在 Grafana 中点击某条高延迟 trace，就能直接跳转到对应服务+实例的 CPU、GC、HTTP 错误率等指标面板。
基于 SLO 的指标驱动追踪采样
全量追踪开销大，尤其在高吞吐场景下。合理策略是按 SLO 偏离程度动态调整采样率：当某服务的 P95 延迟突破阈值或错误率上升时，Collector 自动将该服务的采样率从 1% 提升至 100%；反之，若指标持续健康，可降至 0.1%。OpenTelemetry Collector 支持基于指标的条件采样（如使用 probabilistic_sampler 配合 metrics_exporter 判断），避免“平时看不见问题，出事了又没留痕”的困境。
容器原生指标要覆盖资源与行为两层
容器化环境的指标不能只看应用层，必须分层采集：
- 基础设施层：cgroup 报告的 CPU throttling 时间、内存 working set、网络 TX/RX 丢包率（来自 /sys/fs/cgroup/）
- 容器运行时层：kubelet 暴露的 container_cpu_usage_seconds_total、container_memory_usage_bytes，反映 Pod 级真实负载
- 应用行为层：通过 OpenTelemetry SDK 上报的 http.server.duration、db.client.operation.duration，带 trace_id 关联
三层指标对齐后，才能判断延迟升高是因容器被限频（CPU throttling > 0）、Pod 内存压力大（working set 接近 limit）、还是下游数据库慢查询（trace 中 db.span 耗时突增）所致。
故障定位时按“指标→追踪→日志”路径下钻
这不是线性流程，而是带反馈的闭环：
- 告警触发（如 orders-service P99 延迟 > 800ms）→ 查看该服务整体指标趋势，确认是否地域/版本/部署批次相关
- 筛选异常时间段内的 trace 列表，按 duration 降序排列，聚焦 top 5 最慢链路
- 打开其中一条 trace，定位耗时最长的 span（比如 payment-gateway 调第三方支付 API 花了 720ms）→ 点击该 span，自动跳转到该实例对应时间窗口的 metrics（如 outbound_http_client_duration_seconds）和结构化日志（含 request_id 和 error_code）
- 若日志显示 timeout，再查该实例的网络指标（如 conntrack table full、SYN timeout）完成根因收口
整个过程依赖各组件间 request_id、trace_id、pod_name、timestamp 的精确对齐，以及前端可视化工具（如 Grafana + Tempo + Loki）的深度集成能力。
