investigating-metric-anomalies

调查指标异常

任务：快速从指标症状（“摄取延迟正在上升”）追溯到可能的原因，并提供证据。指标告诉你_发生了什么_以及_何时发生_；日志和链路追踪告诉你_为什么_。按照以下流程操作——先执行成本低、信息量高的调用，只有在影响范围不明确时才扩大排查范围。

流程

1. 确定指标

如果你知道准确的指标名称，可以跳到下一步。否则，使用症状中的部分词语（lag、error、latency、queue）调用 metric-names-list。返回的 metric_type 决定了分析方式：计数器（sum）只有用 rate/increase 才有意义；仪表盘指标使用 avg；直方图使用 histogram_quantile。

2. 先刻画异常——一次调用，回答三个问题

使用指标名称和 anomalyFrom（告警触发时间，或用户表示指标开始异常的时间）调用 characterize-metric-anomaly。如果不确定，可向前多留一些余量。默认情况下，它会与前一个时间窗口进行比较，并回答：

• 有多严重： direction、change_ratio、anomaly_peak 与 baseline_mean。如果 direction 为 flat，说明时间窗口或指标选错了——扩大时间窗口，或使用 baselineFrom/baselineTo 与昨天同一时间段进行比较（具有每日模式的指标与紧邻的前几个小时相比，往往看起来“异常”）。
• 何时发生： onset_time——将此时间戳视为后续所有排查的转折点。
• 发生在哪里： top_movers——行为发生变化的标签值。只有一个变化项（单个 pod、分片或端点）意味着问题可能局部化；所有项都一起变化则意味着问题可能源于共享原因（上游依赖、部署、基础设施）。

3. 使用有针对性的指标查询进一步分析

使用 query-metrics 验证报告提出的假设：

• 深入分析变化项：使用 filters 固定可疑标签值重新查询，并按第二个键分组，进一步定位问题（pod → 容器，端点 → 状态码）。
• 归一化：如果流量翻倍，错误计数上升并不能说明问题——使用 clauses + formula（errors / requests）区分比率变化和流量变化。
• 检查相关指标：查询同一时间窗口内明显相关的指标（对于延迟，查询同一服务的吞吐量和错误计数器；对于延时，查询请求速率和饱和度仪表盘指标）。使用相同的 interval，以便网格在视觉上对齐。

4. 在异常开始时对照不同信号

使用相同的服务，以及覆盖 onset_time 前后的时间窗口切换到日志和链路追踪（从峰值前几个数据桶开始，持续到峰值时段）：

• 日志： 使用 query-logs（遵循其自身的先发现工作流），按涉及的 service.name 和时间窗口筛选，先查 error 级别，再查 warn。在异常开始前出现的重启、崩溃循环、连接错误和部署标记，都是典型原因。如果服务自身的日志没有异常，则扩大范围，检查请求链路中的其他服务。
• 链路追踪： 使用 APM span 工具（例如 query-apm-spans）查询同一服务和时间窗口——运行缓慢或报错的 span 能显示_哪个依赖_出现了问题；示例或日志行中的 trace_id 则可将一个具体请求关联到这三种信号。

5. 用证据得出结论，而不是凭感觉

说明：症状（指标、幅度、开始时间）、可能的原因（在日志/链路追踪中发现了什么，以及其发生时间如何与异常开始时间吻合）、影响范围（根据变化项和分组查询确定受影响的服务/标签），以及置信度。如果原因仍不明确，请说明证据更支持哪种假设，以及还需要什么信息才能区分（例如：“延迟从 20:12 开始回落——这与消费者重启的情况一致；请确认是谁重启了它。”）。

演练示例：“摄取延迟正在上升——为什么？”

1. 使用 metric-names-list，参数为 value: "lag" → logs_rate_limiter_message_lag_seconds（直方图）及相关指标。
2. 对该指标使用 characterize-metric-anomaly，并将 anomalyFrom 设为告警时间 → 方向为 up，变化率为 40 倍，onset_time 为 20:10，变化最大的维度为 service_name = logs-ingestion（其他服务的延迟保持平稳）——因此，落后的具体是日志消费者，而不是整个流水线。
3. 使用 query-metrics：在同一时间窗口内计算消费者吞吐量计数器的 rate → 间隔期间吞吐量为零，且在开始时间后激增：消费者不是运行缓慢，而是_已停止运行_，“延迟上升”是它正在清空积压。
4. 使用 query-logs 查询 20:00–20:15 左右 service.name = logs-ingestion（及其相邻服务）的日志 → 间隔边界处有进程退出和重启日志。
5. 结论：消费者在 20:01–20:10 故障（日志中可见重启）；延迟峰值是积压清空所致，且会自行恢复；受影响的信号：仅日志新鲜度——没有数据丢失（主题保留了消息）。证据：该时间窗口内吞吐量为零、消息年龄峰值与故障时长相同，以及重启日志。

常见问题

• 进程重启时计数器会重置——rate/increase 已能处理这种情况；切勿凭肉眼查看原始累计计数器值。
• 指标停止上报不等于“零”——如果 series 中出现间断，且 top_movers 显示某个标签值消失，说明_指标发射器_已停止运行；应立即转向查看日志。
• 不要只相信单一聚合值：平稳的 avg 可能掩盖异常飙升的 p95。对于类似延迟的仪表盘指标和直方图，也要分析尾部。
• 抓取的 Prometheus 指标会比实时数据延迟约 15–60 秒；不要把序列的最后一个数据桶当作“当前值”。