要真正掌握Linux服务可观测性，必须打通日志、指标、链路三者：日志结构化并用trace_id关联，指标聚焦延迟/错误/流量/饱和度四大黄金信号，链路实现全路径trace_id透传与跨系统对齐。
想真正掌握 Linux 服务的可观测性，光看概念没用，得动手把日志、指标、链路这三块打通。它们不是孤立工具，而是一套协同工作的“诊断组合拳”：日志告诉你“发生了什么”，指标告诉你“运行得怎么样”，链路则告诉你“请求卡在哪一环”。下面直接上实操要点，不绕弯。
日志：别只 tail -f，先做结构化和集中采集
原始文本日志难检索、易丢失、跨机器查起来头疼。关键不是“有没有日志”，而是“能不能快速定位问题上下文”。建议从这几点入手：
- 应用日志尽量输出 JSON 格式（如用 logrus 的 JSONFormatter 或 Python 的 python-json-logger），字段包含 timestamp、level、service、trace_id、request_id 等，方便后续关联
- 用 filebeat 或 fluent-bit 收集本地日志，过滤掉调试日志，添加主机/环境标签，转发到 ELK（Elasticsearch + Logstash + Kibana）或 Loki + Grafana
- Kibana 或 Grafana 中，用 trace_id 聚合一次请求的所有日志行——这是打通链路的关键锚点
指标：聚焦四大黄金信号，用 Prometheus 做轻量采集
CPU、内存这些基础指标只是起点。真正反映服务健康度的是“业务可感知”的指标，即 延迟（Latency）、错误率（Error）、流量（Traffic）、饱和度（Saturation） ——也就是 USE 和 RED 方法的交集。实践建议：
- 在应用中暴露 /metrics 端点（Go 用 promhttp，Java 用 Micrometer + PrometheusRegistry），重点埋点：HTTP 请求成功率、P95 延迟、DB 查询耗时、缓存命中率
- 用 Prometheus 抓取服务指标，配合 node_exporter 抓主机层指标（磁盘 IO wait、TCP retransmit、load1）
- 在 Grafana 中建看板，设置告警规则：比如 连续 2 分钟 5xx 错误率 > 1% 或 API P95 延迟突增 200%
链路：从单机 trace 到全链路透传，别让 trace_id 断在中间
一个请求经过 Nginx → API 网关 → 用户服务 → 订单服务 → MySQL → Redis，如果 trace_id 只在第一跳生成、后面就丢了，链路就废了一半。核心是“透传+注入”：
- 入口服务（如 Nginx 或网关）需支持从 HTTP Header（如 traceparent 或 X-Trace-ID）提取并传递 trace 上下文；OpenTelemetry SDK 默认支持 W3C Trace Context 标准
- 所有中间件调用（HTTP client、gRPC、Redis client、DB driver）都要集成 OpenTelemetry 自动插桩，或手动在 context 中注入 span
- 后端存储（MySQL、Redis）日志里也带上 trace_id，便于和应用日志对齐；慢查询日志可通过 pt-query-digest 提取 trace_id 并关联分析
- 用 Jaeger 或 Tempo 查看完整调用树，点击某个 span 可直接跳转到对应时间范围的 Loki 日志或 Prometheus 指标
三者真正起效，靠的是统一标识（trace_id / service_name / instance）、统一时间（UTC）、统一存储查询入口（Grafana）。不需要一步到位，先确保每个服务能打结构化日志 + 暴露基础指标 + 生成 trace_id，再逐步串联。不复杂但容易忽略。
