夜莺 v9 不只是加了 AI：它瞄准了 SRE 最耗时的三件事

夜莺 v9 多数据源告警与 AI SRE 工作流

一套监控系统上线之后，真正昂贵的往往不是机器成本，而是三类反复消耗工程师的工作：配一条规则要在多个页面之间找信息；规则上线后没人敢保证通知一定能到；事故过去了，还要花很久解释“为什么当时没有告警”。

夜莺 v9 最显眼的更新是 AI，但更值得现有用户关注的，是它开始处理这三笔隐性成本。AI、告警测试和执行记录被放进同一条工作链路，目标不是让产品显得更“智能”，而是减少那些低效、重复、又容易出错的人工操作。

夜莺的核心定位没有改变：它仍然重点解决多数据源告警。Prometheus、Elasticsearch、Loki、VictoriaLogs、MySQL、PostgreSQL、ClickHouse 等数据可以继续留在原来的系统中，夜莺负责统一查询、判断、生成事件和发送通知。v9 改变的，是人使用这套告警引擎的方式。

第一件事：少在工具之间搬运上下文

通用大模型能写 PromQL，也能给出一份排障清单，但它通常不知道企业当前有哪些数据源、告警规则、机器和历史事件。值班人员仍然要把现场信息复制出来，再判断回答是否适用于自己的环境。

Nightingale AI 把对话入口放进了告警、查询、配置和排障流程。它可以在当前用户权限范围内读取相关上下文，帮助创建告警规则和仪表盘、生成 PromQL 或 SQL、分析告警事件、诊断主机接入问题。缺少业务组、数据源等必要条件时，系统会要求用户补充，而不是替用户猜一个答案。

v9 正式版内置 22 个 Skill，覆盖规则创建、数据查询、主机健康诊断、通知配置、仪表盘分析和文档问答等场景。企业还可以把自己的 SOP 写成 Skill，让 AI 按团队约定的步骤排障。这样一来，AI 的价值不只是“懂监控知识”，而是可以复用这家企业自己的运维方法。

大模型也不是绑定的。夜莺支持集中配置 OpenAI 兼容接口、Claude 和 Gemini 等模型接口，既可以使用公网服务，也可以接企业内部网关或私有化模型。不配置模型时，原有监控告警能力仍然可以正常使用。

对使用者来说，直接收益不是“多了一个能聊天的按钮”，而是少做上下文搬运：不用先复制告警，再查规则、找业务组、翻指标，最后把一堆材料拼成提示词。对平台团队来说，Skill 还能把常见操作和排障顺序固化下来，减少同一个问题反复找资深同事确认。

第二件事：少在事故现场追问“它为什么没报”

监控系统最危险的状态，不是没有规则，而是规则看起来存在，真正出故障时却没有发出通知。查询写错、数据源没匹配、持续时间未满足、事件被屏蔽、流水线丢弃、通知规则没有接收人，都可能让一条告警停在半路。

v9 增加了告警规则“测试触发”。用户不必修改阈值制造假故障，可以直接用当前配置合成测试事件，检查查询与判断、生效条件、事件流水线、屏蔽规则和通知发送。测试既可以干跑，也可以向真实接收人发送带 [TEST] 标记的消息。

v9.1 又补上了告警评估执行记录。每个真实评估周期查到了什么、判定出了多少异常、事件在哪一步被拦下，都可以回看。测试触发解决上线前验证，执行记录解决事后追查，两者把过去依赖日志和经验的排障过程变成了可检查的证据链。

从上线前测试到运行后回放的告警可信闭环

这件事对告警系统很关键。没有测试和执行记录，团队不会立刻“损失”一个功能，却会一直承担同一种风险：平时无法证明规则有效，出事后也难以证明链路在哪一步断了。规则越多、人员交接越频繁，这笔成本越高。

第三件事：少在第一张图之前搭半天基础设施

夜莺过去坚持不自带存储，这让它能灵活接入不同数据源，却也提高了新用户的上手门槛。为了看见第一张图，用户往往要先安装 Categraf，再部署 Prometheus 或 VictoriaMetrics，最后配置数据源、仪表盘和告警规则。

v9.1 内置了一个 Prometheus TSDB。对于单实例、约 10 万活跃序列以内的小规模环境，Categraf 上报的指标可以直接写入夜莺，本地完成查询和告警。配合 Categraf 安装与采集向导、内置监控模板推荐、Grafana 数据源导入，新用户可以更快跑通“机器上线—看到数据—导入大盘—收到测试告警”。

边界也需要说清楚：内置时序库的数据保存在单个中心节点的本地磁盘，不适合中心多副本或更大规模的生产环境。这些场景仍应使用外部 Prometheus 兼容时序库。夜莺没有为了追求“一体化”而放弃多数据源架构，而是给小规模用户增加了一条更短的起步路线。

内置时序库的意义不是替代成熟的外部存储，而是让试用、小团队和边缘场景不必先完成一套基础设施项目，才有资格验证监控效果。对于准备正式扩容的团队，外部时序库仍然是更稳妥的选择。