跳到主要内容

常见排查工作流

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

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

这些例子从哪来

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

从哪问，答案不一样​

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

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

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

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

分诊：现在什么在烧​

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

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

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

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

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

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

分析这条告警事件的根因

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

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

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

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

这台机器为什么失联了？

这条告警为什么触发，那条规则为什么没触发​

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

这个告警为什么会触发

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

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

找噪声​

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

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

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

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

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

最后这句来自告警自愈页，它是一个很好的过渡：每周都来一次的机械告警， 就是脚本的候选。见用 ibex / webhook 做告警自愈。

解释一个尖峰，或者写出那条查询​

每个 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 天」，它查的东西就变了。
  • 指定输出格式。 「用表格，一条规则一行」它是听的，看起来也省事得多。
  • 待在同一个对话里。 追问会复用已经取到的东西；新开会话是从零开始。
  • 说清楚你不要什么。 「什么都别改，只告诉我你会改什么」能让这一轮保持只读。
  • 看那行状态提示。 它干活的时候，回复上方有一行字写着当前进行到哪一步。 答案单薄的时候，卡得最久的那一步就是要看的地方。

下一步​

本页目录