夜莺 v9 AI 尝鲜：让告警分析和规则管理多一个全天候副驾驶

预计阅读时间：11 分钟

做 SRE 的人都知道，凌晨三点被电话叫醒看告警，脑子还没转起来就要判断影响范围、定位根因、决定要不要升级——这个过程既耗精力又容易出错。夜莺监控今年的 V9 版把 AI 能力直接嵌进了日常操作流程里，beta 已经放出，核心思路很明确：给每个 SRE 配一个 7×24 在线的资深副驾驶，不是替代你决策，而是帮你快速拿到上下文和初步判断。

LLM Provider：先把"大脑"接进来

V9 的 AI 能力不是绑死某个模型厂商，而是走 Provider 模式——你自己配 LLM 后端，夜莺负责调度。这意味着你可以用 OpenAI、用国内的大模型服务、甚至用本地部署的 Ollama，只要接口兼容就能接入。

一个典型的 Provider 配置大致是这样的（以 OpenAI 兼容接口为例）：

# 夜莺 v9 AI Provider 配置示例
# 文件位置：etc/ai.toml（具体路径以实际部署为准）

[[ai.provider]]
name = "openai"
type = "openai"          # 目前支持 openai 兼容协议
base_url = "https://api.openai.com/v1"
api_key = "sk-xxxxxxxxxxxxxxxx"
model = "gpt-4o"
max_tokens = 4096
temperature = 0.3        # 分析类任务建议偏低，减少幻觉

# 如果用的是国内模型服务，改 base_url 即可
# [[ai.provider]]
# name = "deepseek"
# type = "openai"
# base_url = "https://api.deepseek.com/v1"
# api_key = "sk-xxxxxxxxxxxxxxxx"
# model = "deepseek-chat"
# max_tokens = 4096
# temperature = 0.2

# 本地 Ollama 也可以
# [[ai.provider]]
# name = "ollama-local"
# type = "openai"
# base_url = "http://localhost:11434/v1"
# api_key = "ollama"     # Ollama 不需要真实 key，随便填
# model = "qwen2.5:7b"
# max_tokens = 2048
# temperature = 0.2

几个实操要点：

temperature 建议压低。告警分析和规则审查不是创意写作，0.2～0.3 足够，太高容易跑出"看起来合理但实际不对"的推断。
max_tokens 看场景调。分析单条告警 2048 就够，批量审查规则可能需要 4096 以上。
多 Provider 可以共存，不同 Skill 可以指定用不同 Provider，比如简单分类用便宜模型，深度分析用强模型。

Skills：把 AI 能力封装成可复用的动作

Provider 只是接通了模型，Skills 才是让 AI 真正干活的关键。V9 内置了一批 Skills，覆盖了 SRE 日常高频操作：

Skill 类别	能做什么
告警规则管理	审查现有规则是否有重叠/遗漏，建议优化方向
仪表盘辅助	根据监控对象自动推荐面板布局和指标选择
告警分析	收到告警后自动关联历史、梳理可能根因、给出处置建议
即时查询	在查询页面直接用自然语言描述需求，AI 辅助生成 PromQL/SQL

这些 Skill 不是独立弹窗，而是嵌在对应功能页面里。比如你在即时查询页面，旁边就有 AI Assistant 入口，输入"查一下最近一小时 CPU 超过 90% 的机器"，它会帮你拼出查询语句并执行。

即时查询页面的 AI 交互

这是日常用得最频繁的场景。以前写 PromQL 要记函数名、记标签、记语法，现在可以直接描述意图：

# 你在 AI Assistant 输入框里写：
最近 30 分钟内存使用率超过 85% 的主机列表

# AI 生成的查询（示例）：
node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.15
and (now() - 30m)

# 你可以继续追问：
把上面结果按内存剩余量排序，只看 prod 环境的

# AI 追加修改：
(node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.15)
and (now() - 30m)
and (env = "prod")
| sort by node_memory_MemAvailable_bytes

这种交互方式对不常写查询的人尤其友好——新入职的同事不用翻文档就能上手查数据，老手也能省下拼复杂表达式的时间。

告警分析：凌晨三点的第一反应

告警触发后，AI Assistant 会自动介入分析。它做的事情包括：

提取告警关键信息——哪个机器、什么指标、阈值多少、当前值多少。
关联近期历史——这个指标是不是一直在涨？之前有没有类似告警？
给出初步判断——是资源瓶颈、配置问题、还是业务流量突增导致的。
建议处置动作——扩容、重启、回滚、或者先观察。

这些分析结果直接展示在告警详情页，SRE 早上被叫醒时第一眼看到的不只是一条冷冰冰的"CPU 95%"，而是有上下文的判断："该主机 CPU 在过去 2 小时持续上升，同期流量增长 40%，建议检查是否需要扩容，近期同类告警 3 次，均与流量高峰相关。"

当然，AI 的判断需要人核实。它的价值是帮你快速缩小排查范围，而不是替你做最终决策。

告警规则审查：防止规则腐烂

规则写多了容易出问题——重复告警、阈值过松过紧、覆盖不全。V9 的告警规则管理 Skill 可以批量审查现有规则，输出类似这样的报告：

# AI 审查输出（示例）

⚠ 规则重叠：
  - "CPU 高负载告警" 与 "CPU 长期高负载告警" 触发条件高度相似，
    建议合并或调整阈值梯度（如 80% 预警 + 90% 告警）

⚠ 阈值建议调整：
  - "磁盘使用率告警" 当前阈值 95%，对于日志盘建议降至 85%，
    数据盘可保持 95%，建议按挂载点分别设置

✅ 覆盖完整性：
  - 当前共有 12 条主机级规则，覆盖了 CPU/内存/磁盘/网络四大类，
    但缺少 IO wait 相关规则，建议补充

这种审查以前要么靠人肉巡检，要么靠写脚本比对，现在直接让 AI 帮你扫一遍，省下来的时间用来做更有价值的事。

上手建议和注意事项

如果你准备尝鲜 V9 beta，有几件事值得提前想清楚：

1. 模型选择要匹配场景

简单分类/格式化任务：用便宜模型（DeepSeek-Chat、Qwen 7B 本地部署）就够了。
告警根因分析/规则审查：建议用推理能力更强的模型（GPT-4o、DeepSeek-R1 等），这类任务对逻辑链要求高。
不要一刀切全用最强模型，成本会失控。

2. 数据隐私边界

告警内容、指标数据会发给 LLM，确认你的公司政策允许这么做。
如果敏感数据不能外传，优先考虑本地部署的模型（Ollama + Qwen/DeepSeek）。
夜莺的 Provider 机制支持本地模型，这条路是通的。

3. AI 输出要人审

AI 分析告警时可能引用不存在的历史事件（幻觉），关键决策前务必交叉验证。
规则审查建议也要过一遍再落地，AI 不一定了解你的业务特殊性。

4. 逐步启用，别一口气全开

先在即时查询页面用 AI Assistant，这是风险最低的入口——生成的查询你可以直接看到对不对。
告警分析其次，但初期只作为参考信息展示，不进入自动处置流程。
规则审查最后启用，因为改动影响范围大，需要更成熟的流程配合。

5. beta 版本的预期

这是尝鲜版，Skills 的覆盖范围和输出质量还在迭代。
部署文档和 API 可能和正式版有差异，升级时注意看 changelog。
建议在测试环境先跑，不要直接上生产。

夜莺 V9 把 AI 从"旁边的一个聊天窗口"变成了"嵌入每个操作页面的助手"，这个设计方向是对的——SRE 不需要额外打开一个 AI 工具再手动粘贴上下文，而是在干活的地方直接获得辅助。beta 版已经可以体验核心流程，感兴趣的话拉下来配个 Provider 试一圈，看看哪个 Skill 对你日常帮助最大，再决定正式版怎么用。