2. 可观测性三大支柱：指标(Metrics)、日志(Logs)、链路追踪(Traces)的定义与关系
在可观测性工程实践中，指标(Metrics)、日志(Logs) 和 链路追踪(Traces) 被公认为三大核心数据支柱。它们各自从不同维度描述系统状态，又通过关联分析形成完整的可观测性视图。理解三者的定义、差异与协同关系，是构建自助服务接入体系的理论基础。
2.1 三大支柱的定义
| 支柱 | 核心定义 | 数据特征 | 典型用途 |
|---|---|---|---|
| 指标 (Metrics) | 对系统状态在时间维度上的数值化聚合度量 | 结构化、可聚合、低基数、时序性 | 告警触发、容量规划、趋势分析、SLO 计算 |
| 日志 (Logs) | 系统、应用或服务在运行过程中产生的离散事件记录 | 半结构化/非结构化、高基数、带时间戳 | 故障根因定位、审计合规、调试排错 |
| 链路追踪 (Traces) | 一次请求在分布式系统中经过的所有服务与组件的完整调用路径 | 结构化、有向无环图、跨服务关联 | 性能瓶颈分析、依赖关系梳理、分布式事务诊断 |
关键认知：三大支柱并非相互替代的关系，而是互补关系。单一支柱只能提供系统状态的局部快照，只有三者协同才能还原完整的系统行为全貌。
2.2 三大支柱的关系模型
三大支柱在数据采集、存储和消费层面存在紧密的关联关系。下图展示了它们之间的核心交互与数据流向：
2.3 三大支柱的协同工作模式
在实际运维场景中，三大支柱通过以下方式协同工作，形成完整的可观测性闭环：
- 指标驱动告警与趋势发现：指标提供高密度、低成本的系统健康度概览，是告警和仪表盘的首选数据源。
- 日志提供事件级上下文：当指标出现异常时，通过时间窗口和标签关联到具体日志，获取事件级别的详细上下文。
- 链路追踪还原请求路径：在日志中发现错误或慢请求后，通过 TraceID 关联到完整的调用链，定位瓶颈服务或故障节点。
- 三者交叉验证：指标的趋势变化、日志的异常事件、追踪的调用耗时三者相互印证，避免单一数据源误判。
实践要点：在自助服务接入模板中，必须为每个服务预设三大支柱的关联标识（如 TraceID 注入日志、指标标签携带服务名），否则后续的关联分析将无法自动完成。
2.4 三大支柱的数据特征对比
| 对比维度 | 指标 (Metrics) | 日志 (Logs) | 链路追踪 (Traces) |
|---|---|---|---|
| 数据量级 | 低（聚合后恒定） | 高（随事件数线性增长） | 中（随请求数增长） |
| 存储成本 | 低 | 高 | 中 |
| 查询延迟 | 毫秒级 | 秒级（需索引） | 毫秒~秒级 |
| 关联能力 | 弱（仅标签维度） | 中（需解析提取） | 强（内置 TraceID） |
| 典型保留周期 | 数月~数年（降采样） | 数天~数周 | 数小时~数天 |
2.5 三大支柱的接入优先级建议
在自助服务接入的标准化流程中，建议按照以下优先级逐步接入三大支柱：
- 第一阶段：指标接入 — 成本最低、见效最快，覆盖 CPU、内存、请求量、错误率、延迟等黄金信号。
- 第二阶段：日志接入 — 在指标告警基础上，接入结构化日志并注入 TraceID，建立日志与追踪的关联桥梁。
- 第三阶段：链路追踪接入 — 在关键服务中部署追踪探针，形成完整的分布式调用拓扑。
常见误区：不要试图一次性接入所有支柱。缺乏指标基础的日志和追踪会导致存储成本失控，且难以建立有效的告警体系。建议遵循“指标先行、日志跟进、追踪补全”的渐进式策略。
2.6 三大支柱在自助服务模板中的体现
在标准模板驱动的自助服务接入体系中，每个支柱对应一组独立的配置模板：
| 支柱 | 模板组件 | 关键配置项 |
|---|---|---|
| 指标 | Prometheus ServiceMonitor / PodMonitor | 指标端口、路径、采集间隔、标签映射 |
| 日志 | Fluentd / Logstash 采集配置 | 日志路径、解析规则、TraceID 提取、输出目标 |
| 链路追踪 | OpenTelemetry SDK 配置 / Agent 注入 | 采样率、导出端点、服务名、Span 属性 |
模板设计的关键原则是：三大支柱的关联标识必须在模板层面统一约定。例如，所有模板中强制要求服务名标签一致、TraceID 格式统一、时间戳精度对齐，这样才能在消费层实现无缝关联。