3. 值班台业务场景分析：告警关联、故障定位、SLO看板、根因分析需求
值班台是平台工程中面向运维与开发人员的统一作战界面。在分布式追踪数据接入后，值班台需要支撑四个核心业务场景：告警关联、故障定位、SLO看板与根因分析。每个场景对追踪查询接口的延迟、维度、聚合粒度都有不同要求。本章逐一拆解这些场景的输入、输出与关键查询模式。
3.1 告警关联：从指标异常到Trace的快速跳转
告警系统通常基于指标（如P99延迟、错误率）触发。值班台需要将告警事件与具体的分布式追踪上下文关联起来，帮助值班人员从“系统异常”快速定位到“哪条请求链路出了问题”。
核心需求：告警触发时，自动携带时间窗口、服务名、标签（如HTTP状态码、异常类型），查询该窗口内所有匹配的Trace列表，并按错误类型或延迟排序。
关联流程如下图所示：
| 参数 | 来源 | 说明 |
|---|---|---|
| 时间窗口 | 告警触发时间 ± 5分钟 | 避免时钟偏差，通常使用[start, end]范围查询 |
| 服务名 | 告警标签中的service | 精确匹配，支持多服务联合查询 |
| 错误标签 | 告警规则定义的异常类型 | 如http.status_code >= 500 或 error=true |
| 排序 | 按持续时间降序 | 优先展示最慢或最异常的Trace |
3.2 故障定位：基于Trace拓扑的依赖关系分析
当告警关联返回多条Trace后，值班台需要展示单条Trace的完整调用拓扑，包括服务间调用顺序、各Span的耗时、错误分布。故障定位场景要求接口能够返回完整的Span列表以及父子关系，以便前端绘制火焰图或调用链图。
设计要点：查询单条Trace时，接口应返回所有Span的原始数据，包括span_id、parent_span_id、service_name、operation_name、start_time、duration、status、tags。前端根据parent_span_id自行构建树形结构。
故障定位的典型查询路径：
- 输入TraceID：从告警关联列表或日志中获取。
- 查询完整Trace：返回该Trace下所有Span。
- 识别关键路径：标记持续时间最长的Span、错误Span、外部依赖Span。
- 展示依赖拓扑：按服务维度聚合，显示服务间调用次数、平均延迟、错误率。
3.3 SLO看板：基于追踪数据的服务等级聚合
SLO（Service Level Objective）看板需要从追踪数据中实时计算服务的延迟分布、错误率、吞吐量。与告警关联不同，SLO看板不关心单条Trace细节，而是关注聚合统计。
| SLO指标 | 追踪数据来源 | 聚合方式 |
|---|---|---|
| P50 / P95 / P99 延迟 | Span.duration | 按服务+操作名分组，使用百分位聚合 |
| 错误率 | Span.status.code | 错误Span数 / 总Span数 × 100% |
| 请求速率 (RPS) | Span.start_time | 按时间桶计数，通常1分钟粒度 |
| Apdex 得分 | Span.duration + 阈值 | 满意请求数 / 总请求数 |
性能警告：SLO看板通常需要扫描大量Span数据（数千万/分钟）。查询接口必须支持预聚合或物化视图，避免实时全表扫描。建议在存储层（如Elasticsearch、ClickHouse）建立按分钟+服务+操作名的聚合表。
SLO看板查询接口设计示例：
// 查询某服务过去1小时的P99延迟趋势
GET /api/slo/latency?service=order&metric=p99&start=1700000000&end=1700003600&granularity=1m
// 返回格式
{
"service": "order",
"metric": "p99",
"data": [
{"timestamp": 1700000100, "value": 245.3},
{"timestamp": 1700000160, "value": 312.1},
...
]
}3.4 根因分析：从错误传播到因果推断
根因分析（RCA）是值班台最高阶的场景。当故障定位发现多条Trace包含错误时，值班台需要自动推断最可能的根因服务或根因Span。这要求查询接口支持错误传播路径分析和异常模式匹配。
根因分析的核心逻辑：
- 错误传播图：从错误Span向上游追溯，标记所有调用链中首次出现错误的Span。
- 异常模式库：匹配已知的根因模式，如“数据库超时导致上游重试”、“缓存穿透引发雪崩”。
- 置信度评分：基于错误出现频率、影响范围、历史相似度给出根因排序。
接口设计建议：根因分析接口应返回一个根因候选列表，每个候选包含：service_name、operation_name、span_id、置信度分数、影响Trace数量、首次错误时间。前端根据置信度排序展示，值班人员可一键确认或驳回。
3.5 场景对比与接口优先级
四个场景对查询接口的延迟、数据量、聚合能力要求不同。下表总结了各场景的关键差异：
| 场景 | 查询类型 | 数据量级 | 延迟要求 | 核心接口 |
|---|---|---|---|---|
| 告警关联 | 列表查询 + 过滤 | 百级Trace | < 2秒 | GET /api/traces |
| 故障定位 | 单Trace全量查询 | 千级Span | < 1秒 | GET /api/traces/{trace_id} |
| SLO看板 | 时间序列聚合 | 百万级Span/分钟 | < 5秒 | GET /api/slo/* |
| 根因分析 | 关联分析 + 模式匹配 | 千级Trace | < 10秒 | POST /api/rca/analyze |
在值班台自助查询接口设计中，告警关联和故障定位是基础能力，必须优先实现低延迟查询；SLO看板依赖预聚合管道，需要与存储层配合设计；根因分析属于高阶智能场景，可基于前三个场景的数据逐步迭代。