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-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 里的标准路径：

1. 基础设施 → 数据源：新增Prometheus类型，URL 填http://127.0.0.1:9090，设为默认。
2. 告警管理 → 告警规则：新建规则，数据源选上面的 Prometheus，表达式例如：

   up == 0 # 任意抓取目标掉线

   配置「触发条件 / 持续时长 / 严重级别 / 通知媒介」。
3. 触发与闭环：手动停掉某台机器的node_exporter（systemctl stop prometheus-node-exporter），
   约 1 分钟后规则命中 →事件中心出现一条告警事件 → 在 UI 里「认领 → 处理 → 关闭」，
   全程留痕，即事件闭环。
4. 自愈（ibex）：在规则里挂一个 ibex 任务（如「重启 node_exporter」），告警触发时自动执行，
   实现无人值守恢复。

闭环的另一条路径：让 Prometheus 的Alertmanager 把告警转发给 n9e 的接收器
（n9e 兼容 Prometheusv1/alertswebhook 语义），由 n9e 统一做事件中心与认领关闭。
这样 Prometheus 负责「算」，Nightingale 负责「管」。

五、踩坑笔记

1. MySQL/Redis 私网不可达：默认只听 127.0.0.1，n9e 跨机连不上 → 改0.0.0.0监听。
2. 启动参数：-configs <dir>而非-config <file>，否则启动即退出（status=2/INVALIDARGUMENT）。
3. ghproxy 限速：n9e 二进制 ~39MB，ECS 经 ghproxy 实测 ~35KB/s；改用「本机下载 + SFTP」快 20 倍。
4. REST 路由差异：本构建仅暴露auth/login、busi-groups、self/*等少数 REST；
   datasource/alert-rule走 Web UI。别在未知路由上耗时间——以 UI 为准。
5. 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 工具体系。