08 · 夜莺 Nightingale 落地告警治理与事件闭环实战接 07 篇我们在中心节点 ecs-0001 上把快猫星云的Nightingalen9e 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-0001192.168.0.120 / 113.44.202.151二进制n9e v6.7.3center web ibex 三合一端口17000Web UI / API后端 DBecs-0002 的 MySQLn9e_v6私网 192.168.0.109:3306缓存ecs-0002 的 RedisJWT session192.168.0.109:6379数据源本机 Prometheushttp://127.0.0.1:9090TsDB/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 访问CREATEUSERn9e%IDENTIFIEDBYn9e123456;GRANTALLPRIVILEGESON*.*TOn9e%WITHGRANTOPTION;MySQLbind-address0.0.0.0、Redisbind 0.0.0.0protected-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/s39MB ≈ 85svs ECS 经 ghproxy ~35KB/s≈19min。结论大二进制走本地中转。3. 解压 配库 导表mkdir-p/opt/n9etarxzf /tmp/n9e.tar.gz-C/opt/n9e# 修改 etc/config.toml 的 DSN / Redis 指向 ecs-0002见 deploy/nightingale/config.tomlmysql-un9e-pn9e123456-h192.168.0.109/opt/n9e/n9e.sql# 建 32 张表默认管理员root / root.2020。4. 关键配置config.toml 三段[DB] DSNn9e:n9e123456tcp(192.168.0.109:3306)/n9e_v6?charsetutf8mb4parseTimeTruelocLocalallowNativePasswordstrue [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-reloadsystemctlenable--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_exportersystemctl stop prometheus-node-exporter约 1 分钟后规则命中 →事件中心出现一条告警事件 → 在 UI 里「认领 → 处理 → 关闭」全程留痕即事件闭环。自愈ibex在规则里挂一个 ibex 任务如「重启 node_exporter」告警触发时自动执行实现无人值守恢复。闭环的另一条路径让 Prometheus 的Alertmanager 把告警转发给 n9e 的接收器n9e 兼容 Prometheusv1/alertswebhook 语义由 n9e 统一做事件中心与认领关闭。这样 Prometheus 负责「算」Nightingale 负责「管」。五、踩坑笔记MySQL/Redis 私网不可达默认只听 127.0.0.1n9e 跨机连不上 → 改0.0.0.0监听。启动参数-configs dir而非-config file否则启动即退出status2/INVALIDARGUMENT。ghproxy 限速n9e 二进制 ~39MBECS 经 ghproxy 实测 ~35KB/s改用「本机下载 SFTP」快 20 倍。REST 路由差异本构建仅暴露auth/login、busi-groups、self/*等少数 RESTdatasource/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 工具体系。