核心要点
- 告警评估执行记录：每个评估周期查到了什么、判定出了什么、产生的事件后来被谁拦下了，全部结构化落在告警引擎本地磁盘，可在告警规则页的抽屉里回看原始现场。该功能默认开启，默认保留 8 天、总量上限 20GB。
- 内置时序库：夜莺内嵌了一个 Prometheus TSDB，Categraf 推上来的数据直接存本地，小规模场景不必再先部署 Prometheus / VictoriaMetrics。注意只替换二进制不会启用，需要把新版配置文件的
[EmbeddedTSDB]段抄过去。 - 接入路径全面打通：支持从 Grafana 一键导入数据源；数据源保存后会自动探测有哪些内置大盘和告警规则模板可以直接用；新增 Categraf 采集配置向导。
- 配置前先验证：通知媒介支持保存前发测试消息，消息模板支持不保存直接预览渲染结果，事件流水线支持用 mock 事件试运行。
- 升级方式不变：替换二进制和 integrations 目录，重启即可。
v9.0.0 是夜莺历史上体量最大的一次迭代，把 AI 装进了告警链路的每一环（细节见 夜莺 v9 正式版发布）。v9.1.0 则回到了另一条更朴素的主线上：让夜莺更容易跑起来，也更容易说清楚它当时到底做了什么。
告警评估执行记录：把「为什么没告警」变成可回看的现场
做监控的人大概都被问过这个问题：
昨晚那台机器明明 CPU 打满了，时序库里数据也在，为什么没收到告警？
过去回答它只能靠推理：翻日志、对规则、猜是不是被屏蔽了、猜是不是 for 持续时长没满足、猜事件流水线是不是把它丢了。等你想复现的时候，现场早没了。
v9.1.0 给告警引擎加了一层「行车记录仪」。每个评估周期都会写下一条结构化记录，覆盖告警排障漏斗的三段：
- 当时查到了什么 —— 本轮实际执行的查询和返回的时序数据（默认每次最多留 100 条序列、每条 60 个点）；
- 判定出了什么 —— 触发了多少个异常、多少个恢复；
- 事件后来去哪了 —— 触发、被屏蔽、被事件流水线丢弃、
for持续时长未满足、被更高级别事件抑制，分别有多少。
更细一层，每个事件（按 hash）都有自己的逐阶段轨迹：命中屏蔽规则、仅屏蔽通知、被 mute hook 拦截、pending、被抑制、触发并入队、已在告警中本轮不重复通知、恢复入队、事件队列满导致入队失败……同一个事件在同一周期内经过的多个阶段会按发生顺序串起来。于是上面那个问题从「猜」变成了「看」：打开告警规则页的执行记录抽屉，选中那个时间点，链路在哪一步断的一目了然。
上图展开的这一轮就是个典型例子：查询本身正常（cpu_usage_active > 1 查到 1 条曲线、耗时 8ms、值 70.36），阈值也判定出了异常点，但事件处理明细里写着重复静默，裁决说明给出了具体依据——notify_repeat_step_not_matched，也就是距离上次通知还没到重复通知间隔。「有异常但没收到消息」这件事，到这里就不需要再猜了。
实现上刻意避开了数据库：记录按 {规则ID}_{数据源ID}/{日期}/{小时}.jsonl 的路径写在告警引擎本地磁盘，整点滚动后 gzip 压缩，查询靠文件名直接定位，保留清理按天删目录，全程不依赖索引，也不给 MySQL 添负担。
需要留意的是这个功能默认是开启的，会占用告警引擎所在机器的磁盘。默认策略是保留 192 小时（8 天）、总量上限 20GB、单规则每天上限 1024MB，读侧也有并发和单次查询字节数的闸门，避免查询把评估循环拖慢。如需调整或关闭，见新版 etc/config.toml 的 [Alert.EvalLog] 段。
内置时序库：装完夜莺就能看到数据
夜莺一直是「不自带存储」的架构，好处是能对接十几种数据源，代价是新用户的第一步永远卡在同一个地方：为了看一张图，得先部署一套 Prometheus 或者 VictoriaMetrics。
v9.1.0 内嵌了一个 Prometheus TSDB（API 对齐 Prometheus v0.49.1）。开启之后，Categraf 推上来的指标直接落在夜莺本地，首次启动会自动注册一个名为 embedded-tsdb 的 Prometheus 数据源，仪表盘、即时查询、告警规则可以直接选它。默认保留 15 天、磁盘上限 10GiB、容忍 10 分钟内的乱序样本（应对采集端时钟偏差和补发）。
定位要说清楚：这是给小规模场景和快速上手准备的，适合单实例、10 万活跃序列以内。原因是数据存在该 center 实例的本地磁盘上——center 多副本部署时每个副本只会持有一部分数据，这种情况请继续用外部时序库。另外它只由 center 进程处理，n9e-edge / n9e-alert / n9e-pushgw 读到同一个配置目录时会忽略这一段并打印警告。
迁移也留了口子：[EmbeddedTSDB] 和 [[Pushgw.Writers]] 可以同时开启做双写，先让数据两边都有，验证完再切。
从零到第一张图：接入路径的四处打通
内置时序库解决了「存哪」，v9.1.0 还顺手把接入路径上剩下的几个坎填了：
从 Grafana 一键导入数据源。 填入 Grafana 地址和 Token（也支持用户名 / 密码），夜莺会读出上面的数据源并映射成自己的配置，目前覆盖 Prometheus、Loki、Elasticsearch、MySQL、PostgreSQL。拉取后先给预览，按数据源逐条标注：哪些直接可用、哪些类型不支持（不支持的直接置灰不让选）、哪些需要补凭证。
Grafana 接口不返回密钥明文，所以 SQL 类和 ES 类数据源导入后会先存为禁用状态，等你补完密码再显式启用，不会出现一堆连不上的僵尸数据源。点「导入」之后还会给一份结果回执，逐条列出每个数据源是导入成功、待补充鉴权还是因类型不支持被跳过。
数据源保存后主动告诉你「能用哪些模板」。 夜莺内置了大量仪表盘和告警规则模板，但过去用户并不知道自己这套数据源里到底有没有对应组件的数据。v9.1.0 换了个思路：每个内置模板从自己的表达式里挑出 1~3 个「哨兵指标」，保存数据源时把所有哨兵合成一条 instant query 打过去，哨兵最近 5 分钟有样本的组件就会被推荐出来，页面上点一下卡片即可导入对应的仪表盘和告警规则，并引导你走完第一次查询。请求数不随组件数增长（无论多少组件都只发一条查询），只对 Prometheus 系数据源生效。
Categraf 采集配置向导。 服务端新增 /agents/categraf/collect.sh 端点下发配置脚本，向导分四步：选组件 → 填参数 → 在目标机器执行命令 → 回来验证数据。全程不用手写 toml，生成的命令会把配置写进 conf/input.xxx/ 下对应的文件（原文件自动备份），先用 categraf --test 试采，通过后再重启生效；同一份命令可以在多台机器上重复执行。
主机页新增一键监控套餐、测试告警和下一步引导卡片，把「机器上来了 → 有图了 → 收到第一条告警」这条路串成了闭环。
配置前先验证：不用等真出事才知道配错了
这是 v9.0.0「告警规则测试触发」思路的延续——能演练的就别等真实故障来验证：
- 通知媒介支持保存前测试：钉钉、企微、飞书、邮件这些配置填完先发一条试试，通了再保存；
- 消息模板支持不保存直接预览：用 mock 事件渲染出模板的实际效果，改一版看一版，不用来回存草稿；
- 事件流水线支持用 mock 事件试运行：不必等真实事件流过来就能验证每个节点的处理逻辑；执行记录支持按时间范围筛选，流水线支持批量启停。
这里的样例事件由系统合成、不会入库，级别和恢复态都能调——新装的环境里一条历史告警都没有，照样可以把「按级别分支」「按恢复态分支」的处理逻辑验证一遍。
其他改进
告警侧：
- 内置告警规则模板大幅扩充与修订，并补齐英文词条；
- 告警规则列表支持按触发类型筛选；
- 活跃告警事件列表展示触发时的值，标签支持三态显示；筛选栏的展开状态、自动刷新间隔和时间范围都会被记住，刷新页面不用重新调一遍。
查询与展示：
- 日志浏览新增查询语法文档入口，配套文档见 Loki 日志检索 和 VictoriaLogs 日志检索；
- 仪表盘表格图表支持行详情抽屉，长字段不用再横向拖拽。
性能与修复：
- 通知记录的查询与每日清理改走两个新增索引，索引在启动时在线创建；
- 适配新版 OpenAI 模型的
max_completion_tokens参数； - 修复数据源健康检查不通过时无法强制保存的问题；
- 修复告警规则单位显示错误。
如何升级
从 v9.0.0 升级：替换二进制和 integrations 目录，重启即可。表结构变更会自动执行；如果数据库账号没有建表权限，参考 migrate.sql 手动处理。
有三个注意事项建议升级前看一眼：
- 告警评估执行记录默认开启，由告警引擎写在本地磁盘的
./evallog目录，默认保留 8 天、总量上限 20GB。磁盘紧张的环境请先在[Alert.EvalLog]里调低上限或关闭。 - 只替换二进制不会启用内置时序库。
[EmbeddedTSDB]段只存在于新版etc/config.toml，沿用旧配置文件时该功能保持关闭，需要自行把这一段抄过去。 - 库里若已存在启用状态的 Prometheus 数据源，
embedded-tsdb不会自动注册（避免打扰已有部署）。此时数据照常写入本地时序库，但需要自己建一个指向内置时序库地址的 Prometheus 数据源才能查到。
另外，使用了 n9e-edge 或 n9e-pushgw 的环境，需要和 n9e 一起升级；telegraf 用户上报时序数据的地址后面要加 ignore_host=false 参数，否则机器不会注册到机器管理列表。
完整变更列表和从 v6/v7 跨版本升级的详细步骤，见 v9.1.0 发布说明；全新安装参考 部署文档。
更多信息
- 代码仓库：https://github.com/ccfos/nightingale
- 下载地址：https://flashcat.cloud/download/nightingale/
- 产品文档：https://flashcat.cloud/docs/content/flashcat-monitor/nightingale-v9/introduction/
FAQ
Q1：告警评估执行记录会不会把磁盘写满？
A：有多重上限兜底——默认保留 8 天、总量上限 20GB、单规则每天上限 1024MB，超出后从最旧的开始清理。记录写在告警引擎本地磁盘而非数据库，不会影响 MySQL。如果仍然不想开，在 [Alert.EvalLog] 里设置 Disable = true 即可。
Q2：内置时序库能替代 Prometheus / VictoriaMetrics 吗？ A：小规模可以，大规模不建议。它适合单实例部署、10 万活跃序列以内的场景，数据存在 center 实例的本地磁盘上。center 多副本或者规模更大的环境，仍然建议接外部时序库；迁移期间两者可以同时开启做双写。
Q3：已经在用外部 Prometheus，升级后会有什么变化吗？
A：不会。库里存在启用状态的 Prometheus 数据源时，夜莺不会自动注册 embedded-tsdb 数据源；而且沿用旧配置文件时内置时序库本身就是关闭的，需要显式开启。
Q4：v9.1.0 有破坏性变更吗？ A：没有表结构或接口层面的破坏性变更，从 v9.0.0 升级只需替换二进制和 integrations 目录并重启，配置文件可以沿用（代价是用不上内置时序库这类新增配置项）。唯一需要提前留意的是告警评估执行记录默认开启，会占用告警引擎所在机器的磁盘，详见上文升级注意事项。
升级到企业版
