运维养龙虾--AI+可观测+根因分析（P99 延迟飙到 4.7 秒？五步用 AI 找出罪魁祸首）

七七powerful

649人浏览 · 2026-04-26 16:41:40

七七powerful · 2026-04-26 16:41:40 发布

PagerDuty 告警炸开：checkout-service p99 延迟 > 2s，当前 4.7s，3 分钟前触发。

你知道哪个服务出了问题，但为什么慢，一眼看不出来。

这时候 SigNoz AI 助手可以帮你从"知道哪慢"到"知道为什么慢"，全程用自然语言，不用手写一行查询。

这篇文章基于 SigNoz 官方文档 - Latency Spike Explainer，完整还原一次延迟排查的实战过程。

为什么延迟排查这么让人头大？

告警触发之后，摆在你面前的问题往往不是一个，而是一串：

是单个请求慢，还是所有请求都慢？
慢在哪一层？前端？网关？下游服务？
是最近改了什么引起的，还是外部依赖的问题？
影响了多少用户？要不要现在回滚？

传统做法：拉 Trace 看 span、翻 Grafana 看折线、搜日志找关键词——每一步都要你自己知道去哪找、怎么问。

SigNoz AI 助手通过 MCP Server 把这些查询能力打通，你只需要用自然语言描述你想知道什么，它帮你查、帮你解读。

实战复盘：checkout-service 延迟飙到 4.7s

下面是一次完整的排查过程，按顺序走五步。

🔍 第一步：打开慢链路，看 span 结构

PagerDuty 告警已经告诉你是 checkout-service，但慢在哪一层还不知道。第一步就是找一条具体的慢请求，把调用链展开来看。

提问方式：

显示过去 30 分钟内 checkout-service 中时长超过 2 秒的链路追踪，
拆解最慢的一条的 span 结构

AI 返回的 span 树：

POST /api/checkout (checkout-service, 4,712ms)
  |-- ValidateCart        (checkout-service,   8ms)
  |-- GetCustomerProfile  (customer-service,  41ms)
  |-- ProcessPayment      (payment-service,  4,480ms)  ← 占总时长 95%
  |     |-- ChargeCard    (stripe-gateway,   4,430ms)
  |-- SendConfirmation    (notification-service, 已跳过，上游失败)

一眼就看出来了：95% 的耗时在 ChargeCard 这一个 span 上，是调用 Stripe 网关的那步。

📌 经验：直接看 span 树，比看监控折线更快定位瓶颈层。找出占比最高的那个 span，那就是重点。

🔍 第二步：判断是个别请求慢，还是全部都慢？

慢链路找到了，但要搞清楚：这是个别倒霉请求，还是所有用户都受影响了？

提问方式：

显示过去 2 小时内 checkout-service /api/checkout 接口的 p50 和 p99 延迟，
按 5 分钟间隔拆分

AI 返回的趋势：

01:47 之前：p50 和 p99 都稳定在 ~400ms
01:47 之后：p50 跳到 3.8s，p99 跳到 4.7s，同步飙升

结论：

p50 和 p99 一起涨，说明这不是尾部延迟（tail latency）问题，而是系统性故障——几乎所有请求都变慢了。

📌 经验：只看 p99 容易误判。p50 正常 + p99 异常 = 少数请求慢（可能是某类特殊数据）；p50 p99 都异常 = 全面故障，优先级更高。

🔍 第三步：拿出"健康对照组"，找出唯一差异

知道了问题在 ChargeCard，下一步要搞清楚：是代码改了，还是外部依赖出问题了？

拉一条故障发生前的健康链路做对比。

提问方式：

帮我找 2-3 小时前 checkout-service 中时长低于 500ms 的链路追踪

故障前的健康 span 树：

POST /api/checkout (checkout-service, 387ms)
  |-- ValidateCart        (checkout-service,   6ms)
  |-- GetCustomerProfile  (customer-service,  38ms)
  |-- ProcessPayment      (payment-service,  291ms)
  |     |-- ChargeCard    (stripe-gateway,   248ms)
  |-- SendConfirmation    (notification-service, 31ms)

对比一眼看穿：

span	健康时	故障时	倍数
ValidateCart	6ms	8ms	1.3×
GetCustomerProfile	38ms	41ms	1.1×
ChargeCard	248ms	4,430ms	17.9×
SendConfirmation	31ms	跳过	—

调用链结构完全一样，只有 ChargeCard 耗时暴涨了近 18 倍。问题不在本地代码，根因在下游。

📌 经验：对比"健康 trace vs 故障 trace"是最快排除自身代码问题的方法。结构不变、某个 span 暴涨，就去查那个依赖。

🔍 第四步：顺着依赖链追到真相

现在确定问题在 payment-service → stripe-gateway 这条链路上，去看这两个服务的延迟和日志。

提问方式：

显示过去 2 小时内 payment-service 的 p99 延迟，按 5 分钟间隔拆分。
同时拉取过去 30 分钟内 payment-service 的所有错误/警告日志

AI 返回的日志（关键片段）：

01:47:12 WARN  Stripe 端点配置重载：区域从 us-east-1 切换为 eu-west-1
01:47:14 WARN  ChargeCard 延迟升高（2,341ms），正在重试
01:47:15 ERROR ChargeCard 5000ms 后超时
01:47:18 WARN  ChargeCard 延迟升高（4,102ms）

根因确认：

01:47:12 有一次配置变更，把 Stripe 的 API 端点从 us-east-1 切换到了 eu-west-1。

之后每次支付请求都要跨大西洋往返——延迟从 248ms 涨到 4,430ms，完美吻合。

📌 经验：找到"第一条告警之前的日志"是关键。01:47:12 的配置变更比第一条延迟告警（01:47:14）早了整整 2 秒——根因往往藏在错误开始之前。

📊 第五步：量化影响，决定要不要回滚

找到根因还不够，要说清楚"损失多大"，才能决定下一步动作。

提问方式：

显示过去 2 小时内 checkout-service 的总请求量和错误率，按 5 分钟间隔拆分。
超过 2 秒的请求占比是多少？

AI 返回的影响数据：

指标	数据
故障后总请求数	847 次
超过 2 秒的请求占比	94%
错误率（超时）	12%
趋势	稳定，未继续恶化

94% 的支付请求都在等 4 秒以上，用户体验全面崩盘。决策：立即回滚配置变更。

📌 经验：量化数据不只是为了汇报，更是决策依据。"影响 94% 用户"和"影响少数用户"的处置优先级是完全不同的。

整个排查路径，梳理成一张图

PagerDuty 告警 (p99 = 4.7s)
        ↓
[步骤1] 展开慢 trace → 定位 ChargeCard 占 95% 耗时
        ↓
[步骤2] 看 p50/p99 趋势 → 确认系统性故障（01:47 起）
        ↓
[步骤3] 对比健康 trace → 排除代码问题，锁定下游依赖
        ↓
[步骤4] 查 payment-service 日志 → 发现 01:47:12 配置变更
        ↓
[步骤5] 量化影响（94% 请求受影响）→ 决策：回滚

五步，平均每步一个自然语言问题，从"知道哪慢"到"知道为什么慢"，不需要手写一行查询语句。

底层是怎么跑的？

这套流程背后，AI 助手通过 SigNoz MCP Server 调用了以下工具：

步骤	MCP 工具	用途
1	`signoz_search_traces`	按时长和时间范围筛选慢链路
1	`signoz_get_trace_details`	返回完整 span 树
2	`signoz_aggregate_traces`	计算 p50/p99 时序数据
3	`signoz_search_traces`	找故障前的健康基线链路
4	`signoz_get_service_top_operations`	获取下游服务的延迟拆分
4	`signoz_search_logs`	拉取 payment-service 的告警日志
5	`signoz_aggregate_traces`	统计请求量和错误率