核心要点
- 夜莺 v8.0.0-beta13 新增 MySQL 数据源支持，继续扩展多数据源告警能力。
- MySQL 告警更适合业务指标监控，例如围绕订单数据、商品数据等 OLTP 数据做异常判定。
- 这个版本延续了 v8 的告警引擎定位：重点支持告警，而不是把每个数据源都做成完整可视化工具。
- 本版本修复了通知媒介联系方式无法保存、Elasticsearch 数据源 KQL 语法报错未显示两个问题。
- v6/v7 版本可以平滑升级，升级前建议备份并检查数据库迁移权限和配置差异。
夜莺监控项目最核心的定位，是做一个告警引擎，支持多种数据源的告警。v8.0.0-beta13 的主要更新，是增加 MySQL 数据源支持，进一步增强夜莺在业务指标监控方面的能力。
之前版本的夜莺主要聚焦在 Prometheus、VictoriaMetrics、ElasticSearch 等传统监控数据源上。从上个版本引入 ClickHouse 开始，夜莺开始支持更多样化的数据源。本次版本迭代引入 MySQL 数据源支持，给用户更多灵活性和选择空间。
MySQL 告警适合什么场景
很多关键业务指标并不一定先进入 Prometheus 或日志系统，而是天然存在于业务数据库里。例如订单数据、商品数据等 OLTP 数据，可能本身就存储在 MySQL 中。
MySQL 数据源告警的价值，是让这类业务数据可以直接进入夜莺告警体系。业务监控的告警规则数量通常不需要很多，但每一条都很关键：一旦订单、商品或其他核心业务数据出现异常，告警需要尽快触达值班人员。
| 数据源 | 常见用途 | 夜莺 v8 里的定位 |
|---|---|---|
| Prometheus / VictoriaMetrics | 传统指标监控、机器和服务指标 | 指标告警与查询 |
| ElasticSearch | 日志检索与日志告警 | 日志告警 |
| ClickHouse | 分析型数据、日志或业务聚合数据 | 数据源告警 |
| MySQL | OLTP 业务数据，如订单、商品等 | 业务指标告警 |
这也说明夜莺 v8 的主线不是只服务基础设施监控，而是把告警引擎扩展到更多真实数据源上。
本版本修复的问题
v8.0.0-beta13 还修复了两个 Bug：
- 通知媒介联系方式无法保存的问题。
- Elasticsearch 数据源 KQL 语法报错未显示的问题。
第一个问题影响通知配置保存，第二个问题影响 Elasticsearch 查询配置时的错误反馈。对于正在试用 v8 多数据源告警和新版通知链路的用户，这两个修复都建议关注。
更多改动请参考 GitHub release 的 changelog。
升级须知
大家可以从夜莺的 GitHub releases 页面下载最新发布包。
v6/v7 版本都可以平滑升级：
- 建议先备份老版本的二进制、配置、integrations 目录等，留好后路，然后再升级。
- 如果夜莺所用的 DB 账号有建表、改表权限，会自动更新表结构；否则要参考代码仓库里的
docker/migratesql手工改表结构。 - integrations 目录可以直接替换成新版。
- 配置文件
etc/config.toml建议认真 diff 一下。 - 容器启动的话，直接拉取 latest 镜像重启即可。
夜莺产品特性介绍 PPT
有些人可能对夜莺产品还不太了解，特准备了一份 PPT，请参考：PPT。
FAQ
Q1：v8.0.0-beta13 的重点更新是什么？ A：新增 MySQL 数据源告警支持，让夜莺可以围绕 MySQL 中的业务数据配置告警规则。
Q2：MySQL 告警适合替代所有业务监控吗？ A：不应该这么理解。它更适合少量但关键的业务数据异常判定，例如订单、商品等数据的关键指标告警。
Q3：v6/v7 用户升级时要注意什么？
A：建议先备份二进制、配置和 integrations 目录，确认 DB 账号是否有建表、改表权限，并认真 diff etc/config.toml。
