# 常见排查工作流

可直接粘贴的排查提示词，配上回答它们的内置 Skill：分诊活跃事件、找最吵的规则、解释一次指标尖峰。

最后校对于 2026-10-10

一本菜谱。每一节都把「可以直接粘贴的问题」和「专门为它写的那个内置 Skill」放在一起， 这样你能看懂它为什么命中，而不是靠猜措辞。

这些例子从哪来

下面每一条提示词，要么是产品自己推荐的——新会话的起手卡片，以及 **Nightingale AI** 按钮按页面给出的推荐问题——要么是从 22 个内置 Skill 各自声明的适用范围推导出来的。 它们**不是**实测结论：答得好不好，取决于你配的模型和你有的数据。

## 从哪问，答案不一样[​](#从哪问答案不一样 "从哪问，答案不一样的直接链接")

同一句话在三个地方问，得到的答案不一样，值得先分清自己在哪。

**在某个页面里问。** 页头的 **Nightingale AI** 按钮打开的对话知道你在哪个页面。 在事件详情页问「分析这条告警的根因」，不用再说是哪条事件；在工作区里问就得说清楚。

**在工作区里问。** 没有页面上下文，所以要把对象点名：哪条规则、哪台机器、哪个业务组。 跨领域的问题反而更适合在这里问。

**从 MCP 客户端问。** Claude Code、Cursor 自带模型也自带工具箱——没有 Skill、 没有文档检索、没有确认卡片。依赖 Skill 的提示词在那边不会是同样的表现。 那边就老老实实做检索：*「列出我能看到的所有业务组」*、 *「现在有哪些活跃告警？按级别分组。」* 见[接入 MCP 客户端](https://n9e.github.io/zh/docs/ai/mcp-clients.md)。

## 分诊：现在什么在烧[​](#分诊现在什么在烧 "分诊：现在什么在烧的直接链接")

在告警事件页问，或者在别处把范围说清楚：

> 总结当前活跃告警的分布情况

> 哪些规则或对象的活跃告警最多

> 按级别和业务组汇总当前活跃告警

背后是 `query-alert-events`，它会筛选和聚合事件，而不是一条条列。 预期结果：一张表，不是一屏散装告警。

然后收敛到一条。在事件详情页：

> 分析这条告警事件的根因

> 查找同对象 / 同规则下的相似历史告警

> 看下同一对象在这个时间点附近还有哪些活跃告警

这一路由 `ops-troubleshooting` 驱动，给了 25 次工具调用的预算，因为链条很长： 拉事件、拉规则、把查询在那个窗口上跑一遍、看邻居机器、看当时有没有屏蔽规则在起作用。 它给出的是一条证据链——最后还是你来判断。

「心跳停了但我 ping 得通」这一类，对应的是 `host-health-diagnose`， 它明确的立场是**采集器失联不等于主机宕机**：

> 这台机器为什么失联了？

## 这条告警为什么触发，那条规则为什么没触发[​](#这条告警为什么触发那条规则为什么没触发 "这条告警为什么触发，那条规则为什�么没触发的直接链接")

这是两个不同的问题，对应两个不同的 Skill，说清楚问的是哪个才拿得到对的那个。

> 这个告警为什么会触发

> 为什么某个告警规则没有发出告警

后者是 `alert-rule-troubleshoot`：它按顺序走规则定义、计算日志、事件哈希、 处理日志、屏蔽规则。**把规则点名。** 它最常查出来的三个原因是： 数据源没返回数据、持续时长从来没被满足、以及一条谁都不记得了的屏蔽规则。

## 找噪声[​](#找噪声 "找噪声的直接链接")

新会话里的起手卡片就是这件事，下面是产品自带的原话：

> 帮我盘点当前的告警规则：最近 7 天哪些触发最频繁，哪些规则一次都没触发过

两半都重要：吵的规则消耗注意力，而一年没触发过的规则通常是坏了而不是运气好。 在同一个对话里接着追问：

> 按级别、业务组、对象拆解当前告警

> 我最近哪些告警频繁触发？有没有适合自愈的场景推荐？

最后这句来自告警自愈页，它是一个很好的过渡：每周都来一次的机械告警， 就是脚本的候选。见[用 ibex / webhook 做告警自愈](https://n9e.github.io/zh/docs/events/self-healing.md)。

## 解释一个尖峰，或者写出那条查询[​](#解释一个尖峰或者写出那条查询 "解释一个尖峰，或者写出那条查询的直接链接")

每个 PromQL 输入框旁边——即时查询、告警规则表单、记录规则、仪表盘图表—— 都有一个小 AI 按钮，它的推荐问题都是查询形状的：

> 帮我生成一个查询主机 CPU 使用率的语句

这类由 `promql-generator` 接，它会去查你库里实际有哪些指标，而不是编一个像样的名字。 `sql-generator` 对 MySQL、PostgreSQL、ClickHouse、Doris 做同样的事。 预期结果：一张能就地执行的查询卡片，而不是一段要你自己复制的代码块。

在仪表盘上：

> 分析下此仪表盘

> 找出指标异常或趋势异常的图表

`analyze-dashboard` 会读图表定义、在一个时间窗上跑一遍、报告哪些看着不对—— 仪表盘长到四十个图没人看的时候特别有用。

## 另外两个天天遇到的[​](#另外两个天天遇到的 "另外两个天天遇到的的直接链接")

**机器一直没出现。** 在设备列表页，刚在哪台机器上装完 Categraf：

> 我刚装的机器为什么没出现 / 显示 unknown？

`host-onboard-diagnose` 把上线当成一条流水线来走——心跳、主机名和 `ident`、TLS、 token、路由——而不是停在第一个看起来说得通的原因上。它和 `host-health-diagnose` 是刻意分开的：这个管「从来没注册上」，那个管「之前好好的，现在失联了」。

**通知没收到。** 在通知规则或通知媒介页：

> 这条规则保存后会命中哪些事件？

> 为什么我这条告警没发出通知？

> 为什么测试能收到但实际发不出通知？

最后一句是最有意思的：测试发送是绕过匹配的，所以「测试收得到、真的收不到」 几乎总是规则的条件问题，而不是媒介问题。`notify-rule-copilot` 和 `notify-channel-copilot` 分管这两半。消息正文本身，在模板编辑器里：

> 在通知模板中加入主机名和告警级别

> 把 `trigger_value` 保留两位小数

## 让提示词好使[​](#让提示词好使 "让提示词好使的直接链接")

* **把对象点名。** 「42 号规则为什么没触发」比「我怎么收不到告警」强。 助手会追问，但那要多一个来回。
* **给一个时间窗。** 加上「最近 7 天」，它查的东西就变了。
* **指定输出格式。** 「用表格，一条规则一行」它是听的，看起来也省事得多。
* **待在同一个对话里。** 追问会复用已经取到的东西；新开会话是从零开始。
* **说清楚你不要什么。** 「什么都别改，只告诉我你会改什么」能让这一轮保持只读。
* **看那行状态提示。** 它干活的时候，回复上方有一行字写着当前进行到哪一步。 答案单薄的时候，卡得最久的那一步就是要看的地方。

## 下一步[​](#下一步 "下一步的直接链接")

* 为什么有些问题得靠 Skill：[安装、管理与编写 Skills](https://n9e.github.io/zh/docs/ai/skills.md)
* 放手让它改东西之前：[安全的自动化模式](https://n9e.github.io/zh/docs/ai/automation.md)
* 它答不好或者干脆不答：[AI / Skill / MCP 排障](https://n9e.github.io/zh/docs/ai/troubleshooting.md)