08 · 夜莺 Nightingale 落地：告警治理与事件闭环（实战）
08 · 夜莺 Nightingale 落地：告警治理与事件闭环（实战）
接 07 篇，我们在中心节点 ecs-0001 上把快猫星云的Nightingale（n9e v6.7.3）跑起来，
复用已有的 Prometheus / MySQL / Redis，实现「告警治理 + 事件闭环 + 自愈(ibex)」能力。
配套仓库：https://gitee.com/LiaCin/monitoring-observability-practice
一、为什么还要夜莺
Prometheus + Alertmanager 已经能「产生告警 + 路由通知」，但它不擅长：
- 告警治理：告警订阅、值班、沉默、升级策略、聚合降噪；
- 事件闭环：告警来了 → 认领 → 处理 → 关闭，全程留痕；
- 自愈：告警触发后自动执行脚本（重启服务、扩容等），即 ibex 任务。
这些正好是Nightingale的强项。Nightingale 不替代 Prometheus，而是站在它肩膀上：
复用 Prometheus 做采集/存储，Nightingale 做「告警引擎 + 事件中心 + 自愈」。
Prometheus(9090, 已部署) │ ① 指标查询(TsDB) ③ 告警转发(webhook /api/v1/alerts) │ │ ▼ ▼ Nightingale n9e(17000) ──── 事件中心 / 告警规则 / ibex自愈 │ ② 元数据/事件/用户 ▼ MySQL(ecs-0002) + Redis(ecs-0002)二、部署拓扑与组件
| 项 | 值 |
|---|---|
| 节点 | ecs-0001（192.168.0.120 / 113.44.202.151） |
| 二进制 | n9e v6.7.3（center + web + ibex 三合一） |
| 端口 | 17000（Web UI / API） |
| 后端 DB | ecs-0002 的 MySQLn9e_v6（私网 192.168.0.109:3306） |
| 缓存 | ecs-0002 的 Redis（JWT session，192.168.0.109:6379） |
| 数据源 | 本机 Prometheushttp://127.0.0.1:9090（TsDB/Alerting） |
| 自愈 | 内置 ibex（/ibex/v1/tasks） |
关键网络前提：ecs-0002 的MySQL 与 Redis 必须监听
0.0.0.0（默认只听 127.0.0.1）。
本实战已将它们改为bind 0.0.0.0并关闭 Redisprotected-mode（演示环境）。
三、实操步骤（已在 4 台机器上真跑通）
1. 准备后端（ecs-0002）
-- 在 ecs-0002 创建专用库与账号（nova 用户通过 TCP 访问）CREATEUSER'n9e'@'%'IDENTIFIEDBY'n9e123456';GRANTALLPRIVILEGESON*.*TO'n9e'@'%'WITHGRANTOPTION;MySQLbind-address=0.0.0.0、Redisbind 0.0.0.0+protected-mode no，并systemctl restart。
2. 获取二进制（绕过 GitHub 限速）
ECS 直连 GitHub Release 仍限速，改用本机下载 + SFTP 上传最快：
# 本地（有较好带宽）curl-L-on9e-v6.7.3-linux-amd64.tar.gz\https://github.com/ccfos/nightingale/releases/download/v6.7.3/n9e-v6.7.3-linux-amd64.tar.gz# 经 paramiko SFTP 传到 ecs-0001 /tmppython orch.py...# put_file('113.44.202.151', local, '/tmp/n9e.tar.gz')速度对比：本机 ~460KB/s（39MB ≈ 85s）vs ECS 经 ghproxy ~35KB/s（≈19min）。结论：大二进制走本地中转。
3. 解压 + 配库 + 导表
mkdir-p/opt/n9e&&tarxzf /tmp/n9e.tar.gz-C/opt/n9e# 修改 etc/config.toml 的 DSN / Redis 指向 ecs-0002（见 deploy/nightingale/config.toml）mysql-un9e-pn9e123456-h192.168.0.109</opt/n9e/n9e.sql# 建 32 张表默认管理员：root / root.2020。
4. 关键配置（config.toml 三段）
[DB] DSN="n9e:n9e123456@tcp(192.168.0.109:3306)/n9e_v6?charset=utf8mb4&parseTime=True&loc=Local&allowNativePasswords=true" [Redis] Address = "192.168.0.109:6379" # 复用本机 Prometheus 作为数据源 / 时序库 / 告警引擎 [[TsDB]] Name = "prometheus" QueryAddr = "http://127.0.0.1:9090" AlertingEnabled = true [[Alerting]] TsDB = "prometheus"注意：n9e v6.7.3 的启动参数是
-configs /opt/n9e/etc（目录），不是-config xxx.yml，
否则会报flag provided but not defined: -config。
5. 启动并验证
systemctl daemon-reload&&systemctlenable--nown9e systemctl is-active n9e# -> activess-tlnp|grep17000# -> LISTENcurl-shttp://localhost:17000/health# -> 返回 Web UI HTMLcurl-shttp://localhost:17000/metrics|grepn9e_alert_alert_queue_size# -> 自监控指标Web UI 公网可达：http://113.44.202.151:17000（默认管理员root/root.2020）。
四、事件闭环：怎么用（Web UI 流程）
本版本 n9e 的「数据源 / 告警规则」通过Web UI配置（这两个 REST 路由在本构建中未编译进二进制，
直接调/api/n9e/datasources会落到 SPA 兜底页）。在 UI 里的标准路径：
- 基础设施 → 数据源：新增
Prometheus类型，URL 填http://127.0.0.1:9090，设为默认。 - 告警管理 → 告警规则：新建规则，数据源选上面的 Prometheus，表达式例如：
配置「触发条件 / 持续时长 / 严重级别 / 通知媒介」。up == 0 # 任意抓取目标掉线 - 触发与闭环：手动停掉某台机器的
node_exporter（systemctl stop prometheus-node-exporter），
约 1 分钟后规则命中 →事件中心出现一条告警事件 → 在 UI 里「认领 → 处理 → 关闭」，
全程留痕，即事件闭环。 - 自愈（ibex）：在规则里挂一个 ibex 任务（如「重启 node_exporter」），告警触发时自动执行，
实现无人值守恢复。
闭环的另一条路径：让 Prometheus 的Alertmanager 把告警转发给 n9e 的接收器
（n9e 兼容 Prometheusv1/alertswebhook 语义），由 n9e 统一做事件中心与认领关闭。
这样 Prometheus 负责「算」，Nightingale 负责「管」。
五、踩坑笔记
- MySQL/Redis 私网不可达：默认只听 127.0.0.1，n9e 跨机连不上 → 改
0.0.0.0监听。 - 启动参数：
-configs <dir>而非-config <file>，否则启动即退出（status=2/INVALIDARGUMENT）。 - ghproxy 限速：n9e 二进制 ~39MB，ECS 经 ghproxy 实测 ~35KB/s；改用「本机下载 + SFTP」快 20 倍。
- REST 路由差异：本构建仅暴露
auth/login、busi-groups、self/*等少数 REST；datasource/alert-rule走 Web UI。别在未知路由上耗时间——以 UI 为准。 - Grafana 密码：本环境 Grafana 13 首次启动后默认
admin/admin失效，需用cd /usr/share/grafana && grafana cli admin reset-admin-password 'admin123'重置。
六、与 07 篇的关系
- 07 篇：Prometheus 全家桶 9/9 Targets 全绿（采集 + 存储 + 基础告警）。
- 本篇：在之上叠加Nightingale，把「告警」升级为「可治理、可闭环、可自愈」的事件体系。
- 两者并存：Prometheus 继续抓数据，Nightingale 复用它做查询与告警引擎，互不替代。
至此，监控体系从「能告警」进化到「能治理、能闭环、能自愈」——一套真正可落地的 SRE 工具体系。