从 Grafana Alerting 迁移
Grafana 仪表盘留着；搬告警规则和联系点，以及统一告警的状态怎么处理。
看完这页，你能把 Grafana 的统一告警拆成夜莺的对象，知道哪些能自动搬、哪些只能重写， 以及 Grafana 那些「无数据 / 执行错误」的状态该怎么落地。
什么留着，什么被替掉
| 你现在跑的 | 迁移后 |
|---|---|
| Grafana 仪表盘、面板、变量 | 不动。 夜莺自带仪表盘，但不要求你搬走，见配合 Grafana 使用 |
| Grafana 的数据源（Prometheus、Loki、ES…） | 不动，两边各自连同一个后端 |
| Grafana 的记录规则 | 不动，或按需搬成记录规则 |
| Grafana 告警规则（Grafana-managed） | 重写成夜莺的告警规则 |
| Grafana 告警规则（Data source-managed） | 它们其实就是 Prometheus 的 ruler 规则，走 Prometheus + Alertmanager 那条路 |
| 通知策略（Notification policies） | 拍平成夜莺的通知规则 |
| 联系点（Contact points） | 通知媒介 + 通知规则 |
| 静音时段、静默 | 屏蔽规则 |
一件能自动化的事：数据源
规则搬不了，数据源可以一键搬。集成中心 → 数据源页右上角有「从 Grafana 导入」 （只有管理员能看到）：
- 填 Grafana 地址，选鉴权方式（API Token 或用户名 / 密码）。 自签证书可以勾「跳过 TLS 证书校验」。
- 点拉取。会出一张预览表，列出 Grafana 类型、名称、映射类型、是否支持、 是否重名、是否待补充鉴权。这一步不写库。
- 勾选要导的，点导入。结果按条返回：成功导入 / 待补充鉴权 / 跳过 / 失败。
两件要注意的：
- 密钥不会跟着过来。 预览表里标了「需补填密钥」的，导入后是半成品， 要去数据源详情里把密码或 Token 补上才能用。
- 不支持的类型会被标出来跳过。 夜莺支持的数据源类型是有限的一组， Grafana 里那些没有对应实现的插件导不进来。
验证：导完在数据源列表里逐个点开做连通性检查。
对象映射
告警规则
| Grafana Alerting | 夜莺 |
|---|---|
| 规则的查询 A + Reduce B + Threshold C 这条表达式链 | Prometheus 类规则把阈值写进 PromQL（avg_over_time(...[5m]) > 80）；日志类和 SQL 类规则则有独立的触发条件，写成 $A.value > 80 |
| Pending period（待处理时长） | 持续时长 |
| Evaluation group 的 interval | 执行频率 |
| Labels | 附加标签 |
Annotations 的 summary / description | 注释 |
Annotations 的 runbook_url | 规则上的「预案链接」字段 |
| 规则的 folder | 业务组——但它同时是权限边界，不只是文件夹，见业务组 |
| Alert instance（一条规则展开出的多个实例） | 事件。一条规则的查询返回几条序列就产生几个事件 |
| 状态历史 / State history | 告警事件，加上判定记录 |
Grafana 的表达式链是这次迁移里最费手的部分：Grafana 把「查什么」和「阈值多少」拆成两步，
夜莺的 Prometheus 类规则把它们合成一条 PromQL。翻译时把 Reduce 换成 PromQL 的聚合函数
（avg_over_time / max_over_time / last_over_time），把 Threshold 换成比较运算符。
通知策略与联系点
Grafana 的统一告警内嵌了一个 Alertmanager，所以通知策略就是 Alertmanager 的路由树，
continue 那一套语义完全一样。夜莺没有树形路由，是平铺的多条通知规则各自匹配、各自发送。
拍平的方法、以及「空条件在两边含义相反」「缺标签一律不匹配」这两个坑， 和 Alertmanager 那页完全一致，不再重复：见 从 Prometheus + Alertmanager 迁移。
| Grafana | 夜莺 |
|---|---|
| Contact point | 通知媒介（怎么发）+ 通知规则（发给谁） |
| Notification template | 消息模板 |
| 通知策略的 matcher | 通知配置上的「适用标签」「适用属性」 |
group_by / group_wait / group_interval | 没有对应物，夜莺一次通知只装一个事件 |
repeat_interval | 告警规则上的「重复通知频率」，单位分钟 |
静默与静音时段
| Grafana | 夜莺 |
|---|---|
| Silence（一次性） | 「固定时间」屏蔽规则 |
| Mute timing（静音时段） | 「周期时间」屏蔽规则，或通知配置上的「适用时段」 |
| 静默的 matcher | 屏蔽规则的事件标签条件，六个操作符 |
| （无对应） | 屏蔽方式可选「只屏蔽通知」，事件照常留档 |
静音时段有两种落法，选哪个取决于范围：想让某类事件在这个时段里谁都收不到，用周期屏蔽； 只想让某一条通知规则在这个时段不发（别的照发），用通知配置上的「适用时段」。
Grafana 独有、夜莺没有的
这几样是必须做取舍的地方，迁移前先想清楚：
- No data / Error 状态机。 Grafana 规则可以单独指定「查不到数据时算什么状态」
和「执行出错时算什么状态」（
NoData/Alerting/OK/KeepLast）。 夜莺没有这个状态机：Prometheus 类规则里，序列消失就等于恢复； 想在「数据没了」时告警，要单写一条规则（比如up == 0）。 日志类和 SQL 类规则有一个「无数据」开关，带自己的级别和自动恢复超时， 是最接近 GrafanaNoData的东西。见判定与恢复。 - Keep last state。 没有对应物。
- 告警规则的版本历史和 provisioning。 夜莺没有内建的规则版本管理； 等价做法是导出规则 JSON 进版本库，见导入、导出与复用。
- 每条规则可以配多个联系点的多步升级。 没有对应物； 最接近的是订阅规则的「持续时长」做一层超时抄送。
迁移顺序
Grafana 全程不停，随时能退。
- 导数据源。 用上面的「从 Grafana 导入」，补齐密钥。 验证：每个数据源连通性检查通过。
- 建通知媒介和消息模板。 把每个 Contact point 的地址和密钥搬过来。 验证：保存前点「测试」，真的收到消息。
- 拍平通知策略成通知规则。 方法见 Alertmanager 那页。 验证：每份通知配置点「发送测试」，模拟事件和历史事件两种模式都过一遍。 见测试通知。
- 重写告警规则，先不启用。 从最重要的一批开始，Reduce + Threshold 合成 PromQL。 验证：每条规则点试运行，看查询→阈值→事件→通知各段是否都通。
- 搬静默和静音时段。 还没过期的静默重建成固定时间屏蔽，静音时段按上面的取舍落地。 验证：屏蔽规则表单上的「测试」会拿现有事件跑一遍匹配。
- 并行跑一段。 Grafana 侧的规则先别删，两边都发通知，对比触发结果。 做法见并行运行与回退方案。
- 切换。 确认无差异后，在 Grafana 里把这批规则暂停（不要删），观察一周再删。 仪表盘留着不动。
回退
第 7 步之前，回退就是把夜莺这批规则批量禁用，Grafana 那边一直在跑。
第 7 步之后要回退，就是在 Grafana 里把暂停的规则恢复。所以那一步用「暂停」不用「删除」—— 删了就得重建，暂停一秒钟就能回来。
下一步
- 仪表盘怎么和 Grafana 共存：配合 Grafana 使用
- 路由树拍平的完整方法：从 Prometheus + Alertmanager 迁移
- 两边同时跑、怎么切：并行运行与回退方案