用途：把指标症状（如“ingestion lag is rising”）快速转化为有证据支撑的可能原因。指标说明“是什么、何时发生”，日志与追踪说明“为什么”。
主要能力与流程：
- 锁定指标：若不知确切名称，调用 metric-names-list，用症状子串（lag、error、latency、queue）搜索；返回的 metric_type 决定视角——counter 只按 rate/increase 看，gauge 按 avg，histogram 按 histogram_quantile。
- 先做特征刻画：调用 characterize-metric-anomaly，传入指标名与 anomalyFrom（告警触发时间或用户认为开始异常的时间）。它默认与前一窗口对比，给出：严重程度（direction、change_ratio、anomaly_peak 与 baseline_mean）、起始时间 onset_time、以及 top_movers（行为变化的标签值）。单一 mover 指向局部原因，全部一起变化指向共享原因。
- 用 query-metrics 验证假设：按可疑标签值过滤并二次分组定位；用 clauses + formula（如 errors / requests）区分速率变化与流量变化；查询同窗口的伴随指标（吞吐、错误计数、饱和度等），保持相同 interval 便于对齐。
- 在 onset_time 附近跨信号关联：用 query-logs 按 service.name 与窗口查日志，先 error 后 warn，关注重启、崩溃循环、连接错误与部署标记；用 APM span 工具（query-apm-spans 等）查同服务同窗口的慢/错 span，trace_id 可串联三类信号。
- 结论需含：症状（指标、幅度、起始）、可能原因及其时间对齐、影响范围（受影响服务/标签）、置信度；若仍不确定，说明证据倾向哪种假设及如何进一步区分。
限制与注意：counter 在进程重启时会重置，不要直接看累计值；指标停止上报不等于零，序列出现缺口且 top_movers 中标签值消失通常意味着采集端已死，应立即转查日志；单一聚合不可信，均值平稳可能掩盖 p95 飙升；Prometheus 抓取指标通常滞后约 15–60 秒，最后一个桶不代表“当前”。