2. 值班台可观测性需求分析：值班场景下的三大支柱优先级与追踪数据的关键作用
在值班场景中，可观测性的三大支柱——日志（Logs）、指标（Metrics）和追踪（Traces）——并非同等重要。值班人员的核心目标是快速发现故障、定位根因、恢复服务。因此，三大支柱的优先级和分工必须根据值班场景的时效性要求进行重新定义。
2.1 值班场景下的三大支柱优先级
值班人员面对的是海量告警和瞬时决策压力。三大支柱在值班流程中的优先级排序如下：
| 优先级 | 支柱 | 值班场景核心价值 | 典型使用时机 |
|---|---|---|---|
| P0（最高） | 指标（Metrics） | 全局状态感知、告警触发、趋势判断 | 值班仪表盘、告警规则、SLO/SLI 监控 |
| P1 | 追踪（Traces） | 跨服务调用链分析、故障传播路径定位 | 告警下钻、慢请求分析、错误链路排查 |
| P2 | 日志（Logs） | 详细上下文、异常堆栈、审计记录 | 追踪定位到具体服务后，深入代码级排查 |
值班黄金法则： 指标告诉你“哪里出了问题”，追踪告诉你“问题是怎么传播的”，日志告诉你“为什么出问题”。在值班场景中，追踪是连接指标告警与日志细节的桥梁。
2.2 追踪数据在故障定位中的关键作用
在微服务架构中，一个用户请求可能跨越数十个服务实例。指标只能暴露某个服务的异常，但无法展示请求的完整路径。追踪数据通过 Trace ID 和 Span 结构，完整还原请求的调用链，是值班人员从“发现异常”到“定位根因”的核心工具。
追踪数据在值班场景中的关键作用体现在以下四个维度：
- 故障传播路径可视化： 通过火焰图或拓扑图，值班人员可以一眼看出故障是从哪个上游服务开始传播的。
- 延迟瓶颈定位： 追踪数据可以精确到每个 Span 的耗时，快速识别出哪个服务调用是延迟的“罪魁祸首”。
- 错误关联分析： 当某个 Span 返回错误码时，追踪数据可以关联该 Span 的日志上下文，避免在大量日志中盲目搜索。
- 依赖关系验证： 在变更或故障恢复后，追踪数据可以验证服务间的依赖关系是否正常，辅助值班人员判断是否已完全恢复。
2.3 值班场景对追踪存储的特殊需求
基于上述关键作用，值班场景对分布式追踪存储系统提出了区别于常规分析场景的硬性要求：
| 需求维度 | 值班场景要求 | 原因说明 |
|---|---|---|
| 写入吞吐 | 支持高并发 Span 写入（≥10万 Span/秒） | 值班期间流量高峰，追踪数据采集不能成为瓶颈 |
| 查询延迟 | Trace ID 查询 < 1秒；标签查询 < 3秒 | 值班人员需要秒级响应，快速下钻分析 |
| 数据持久性 | 至少保留 7-14 天全量数据 | 值班交接、事后复盘需要完整历史链路 |
| 高可用 | 集群部署，单节点故障不影响写入和查询 | 值班系统本身不能成为故障点 |
| 采样策略 | 支持头部采样 + 尾部采样混合策略 | 既要保证关键错误链路不丢失，又要控制存储成本 |
值班提示： 在选型时，不要只关注存储引擎的基准性能，更要关注其在“高并发写入 + 实时查询”混合负载下的表现。许多存储系统在写入压力大时，查询延迟会急剧上升，这在值班场景中是致命的。
2.4 三大支柱在值班流程中的协作关系
为了更直观地展示三大支柱在值班流程中的协作关系，下图展示了从告警触发到根因定位的完整数据流：
常见误区： 不要试图用日志替代追踪。日志是离散的、无结构的文本，而追踪是结构化的、跨服务的调用链数据。在值班场景中，从海量日志中手动拼接调用链是不可行的。追踪数据是连接指标告警和日志细节的“高速公路”。
2.5 值班场景追踪数据的关键字段
为了支撑上述故障定位流程，追踪存储系统必须能够高效索引和查询以下关键字段：
- Trace ID： 全局唯一标识，用于关联所有 Span。
- Span ID： 单个服务调用的唯一标识。
- Parent Span ID： 用于构建调用链父子关系。
- Service Name： 服务名称，用于按服务维度过滤。
- Operation Name： 操作名称（如 HTTP URL、RPC 方法名）。
- Start Time / Duration： 开始时间和耗时，用于延迟分析。
- Status Code： 状态码（OK / ERROR），用于错误过滤。
- Tags / Attributes： 自定义标签（如用户 ID、订单 ID），用于业务维度下钻。