核心要点
- 夜莺 v8.0.0-beta10 支持中心端无法连通边缘时序库时仍然执行告警。
- 新模式适合边缘机房、安全隔离、合规限制等“中心不能访问边缘，但边缘可以访问中心”的网络环境。
- 中心端仍统一管理告警规则，n9e-edge 周期性同步规则并在边缘侧查询时序库做告警判定。
- 数据源配置支持仅保存、不做连通性校验，并配合“时序库内网地址”实现边缘查询。
- 本版本还包含仪表盘、通知规则、Elasticsearch 告警规则和老仪表盘兼容等改进。
以防读者不了解夜莺，开头先做个介绍。
夜莺监控，英文名字 Nightingale，是一款侧重告警的监控类开源项目。类似 Grafana 的数据源集成方式，夜莺也是对接多种既有的数据源，不过 Grafana 侧重在可视化，夜莺侧重在告警引擎。比如把 Prometheus、VictoriaMetrics、ElasticSearch 等作为数据源接入夜莺，即可在夜莺里配置告警规则做指标、日志的告警。当然，夜莺也不止做告警，还提供 ad-hoc 查询、指标视图、仪表盘等可视化能力，不过在可视化方面没有 Grafana 道行深。配合 Categraf 采集器，夜莺可以做到一站式监控。项目地址是：https://github.com/ccfos/nightingale
近期，夜莺监控项目发布了 v8.0.0-beta10 版本。虽然是 beta 版本，实际是稳定的，可以放心升级；只是配合市场工作，正式版会放到每年 7 月发布。
这个版本最重要的变化，是支持中心端无法连通时序库时仍然可以告警。
适用场景：中心端连不通边缘时序库
通常来说，夜莺只需要部署中心端一个 n9e 进程，由这个 n9e 进程对接各个时序库、日志库，执行查询和告警。在网络环境较好的情况下，这种架构没有问题。
但在一些真实环境里，中心端无法直连边缘机房的时序库，原因可能是安全、合规或网络隔离等因素。网络方向只能是边缘机房访问中心，中心不能访问边缘。此时，中心机房无法统一查询边缘数据，但仍然希望在中心统一管理告警规则，并对边缘机房的时序库做告警。
v8.0.0-beta10 支持的就是这个场景。
新版本如何实现边缘告警
老版本夜莺要处理边缘机房场景，需要在“数据源”里配置边缘机房的时序库地址。但中心端连不上边缘机房，保存时就会报错。
新版本支持数据源仅保存、不做连通性校验。配合“时序库内网地址”配置，就可以达成上图的效果。
最终流程是：
- 在中心端配置数据源和告警规则。
- 数据源可以仅保存，不要求中心端立即连通。
- n9e-edge 周期性调用 n9e 接口，同步告警规则。
- n9e-edge 将规则缓存在内存中，即便网络断开，也可以使用内存中的缓存规则。
- n9e-edge 使用时序库内网地址查询边缘机房时序库。
- n9e-edge 在边缘侧完成告警判定。
在这个模式下，夜莺数据源页面最上面 ① 的位置即便配置一个假地址也无所谓，因为不会做连通性校验。真正用于边缘查询的是“时序库内网地址”。
这个能力解决了什么问题
| 问题 | 老方式的限制 | v8.0.0-beta10 的变化 |
|---|---|---|
| 中心端无法访问边缘时序库 | 数据源保存时连通性校验失败 | 支持仅保存，不强制中心端连通 |
| 边缘机房仍需告警 | 中心端无法直接查询边缘数据 | n9e-edge 在边缘侧查询时序库并判定告警 |
| 希望统一管理规则 | 各边缘独立配置会分散管理 | 中心端统一管理，边缘侧同步规则 |
| 网络短暂中断 | 规则同步可能受影响 | n9e-edge 内存缓存规则，可继续使用缓存执行 |
这个设计把“规则管理”和“数据查询”分开：规则仍然由中心统一管理，实际查询和告警判定放到能访问时序库的边缘侧执行。
其他更新
Changelog 和新版下载地址：https://github.com/ccfos/nightingale/releases/tag/v8.0.0-beta.10
其他更新包括：
- feat: 仪表盘新版数据源选择器。
- refactor: 仪表盘包含“机器标识”变量时禁止启用匿名访问。
- refactor: 仪表盘下线“业务组标识”变量。
- refactor: 告警规则默认执行频率改为 60 秒。
- refactor: 记录规则表单页提交按钮统一改名为“保存”。
- refactor: 通知规则优化：
- 告警规则的通知规则选择器添加查看规则功能。
- 消息模板支持克隆。
- 消息模板右侧文档宽度支持调节。
- fix: 修复创建数据源后部分页面数据源类型未刷新问题。
- fix: 修复告警规则克隆时遇规则被其他修改无法保存问题。
- fix: 修复告警规则 Elasticsearch 源保存的字段路径错误问题。
- fix: 修复 Elasticsearch 日志查询 Lucene 模式的过滤条件字段值中包含 and、or 等字符时会被自动转换成大写问题。
- fix: 修复一些比较老的仪表盘导入后因为缺少 legend.placement 导致图例容器溢出问题。
- fix: 修复折线图提示信息没有过滤掉空值图例问题。
升级建议
如果你的网络环境是中心端可以访问所有时序库，这个版本的边缘告警能力未必是刚需，但仍可以关注其他修复和优化。
如果你的环境存在边缘机房、网络隔离、中心端无法直连边缘时序库等情况，v8.0.0-beta10 值得重点验证。建议先在测试环境确认数据源配置、n9e-edge 同步规则、内网地址查询和告警触发链路，再进入生产环境。
欢迎大家下载试用。有问题提 issue 即可，研发人员会持续关注。
FAQ
Q1：中心端完全连不上边缘时序库，还能统一管理告警规则吗？ A：可以。v8.0.0-beta10 支持中心端仅保存数据源配置，不做连通性校验，由 n9e-edge 同步规则并在边缘侧查询时序库。
Q2：n9e-edge 和中心端网络断开后会怎样？ A：文章说明 n9e-edge 会把同步到的告警规则缓存在内存里，即便网络断了，也可以使用内存中缓存的规则继续执行。
Q3：这个版本只适合边缘机房吗？ A：边缘机房是典型场景。凡是中心端无法直连数据源、但边缘侧可以访问中心并能访问本地时序库的网络环境，都可以参考这个模式。
