云原生监控的核心是指标、日志、链路三类数据通过统一标识（如trace_id、pod_name）和标准化采集路径实现关联与交叉验证，而非简单堆砌Prometheus、Loki、Tempo等工具。
云原生监控不是堆砌工具，而是让指标、日志、链路三类数据彼此可关联、可交叉验证。核心在于统一标识（如 trace_id、pod_name、namespace）和标准化采集路径，而非单独把 Prometheus、Loki、Tempo 都装上。
用 OpenTelemetry 统一埋点与导出
避免在应用里分别对接 metrics SDK、log library、tracing agent。OpenTelemetry SDK 支持同时生成指标、日志、trace，并通过统一上下文传递 trace_id 和 span_id。Java/Go/Python 等主流语言均有稳定 SDK。
- 在服务启动时初始化全局 TracerProvider 和 MeterProvider，启用自动仪器化（如 HTTP client/server、DB driver）
- 日志框架（如 log4j2、zap）接入 OTel 日志桥接器，自动注入 trace_id、span_id、service.name 字段
- 导出端统一配置为 OTLP 协议，后端由 OpenTelemetry Collector 接收并路由到不同存储（Prometheus 做指标、Loki 做日志、Tempo 做链路）
在 Prometheus 中打标对齐业务上下文
默认抓取的指标缺少 trace 关联能力。需在 scrape 配置中注入静态标签或通过 relabel_configs 动态提取 Pod/Service 元信息。
- 利用 kubernetes_sd_configs 自动发现 Pod，通过 __meta_kubernetes_pod_label_app 注入 app 名，__meta_kubernetes_namespace 注入命名空间
- 在容器运行时（如 containerd）开启 cgroup v2 并暴露指标，配合 node_exporter + kube-state-metrics 补全资源拓扑关系
- 自定义指标（如业务请求数）务必带上 service、endpoint、status_code、trace_sampled 等标签，便于后续与 trace_id 关联分析
用 Loki 实现日志与 trace 的双向跳转
Loki 本身不存 trace_id，但可通过 logql 查询 + Grafana 前端联动实现“从日志查 trace”或“从 trace 查日志”。关键在日志行必须包含 trace_id 字段且格式可提取。
- 确保应用日志 JSON 格式中含 trace_id 字段（如 {"level":"info","msg":"req done","trace_id":"abcd1234..."}
- Grafana 中配置 Loki 数据源后，在 Logs panel 使用 logql：{job="myapp"} | json | trace_id="abcd1234..."
- 在 Tempo 数据源已配置的前提下，Grafana 可自动识别日志中的 trace_id 并渲染“Jump to Trace”按钮，点击直达调用链详情
用 Tempo 构建可下钻的分布式链路视图
Tempo 不依赖采样率预设，支持按 trace_id 全量存储（配合合理的 retention 和 block size）。重点是让 span 携带足够业务语义，而非仅技术层调用。
- HTTP handler span 设置 name 为 ${method} ${route}（如 GET /api/users/{id}），而非固定 "http.server.request"
- DB 查询 span 添加 db.statement 标签（截断防敏感），并设置 db.operation=select/update
- 在 Grafana 中使用 Trace Viewer 面板，开启 “Show logs” 选项，自动拉取同 trace_id 的 Loki 日志流，实现 trace-log 同屏比对
指标看趋势、日志看细节、链路看路径——三者真正打通，靠的不是界面拼接，而是采集时就写入一致标识、存储时保留原始上下文、查询时支持跨数据源关联。不复杂但容易忽略。
