被 50 条告警同时炸醒后：用 Nightwatch 这个开源 AI SRE 把告警风暴变成一条根因
凌晨 3 点，手机疯狂震动。Prometheus 弹了 18 条告警，Checkmk 跟了 22 条，Zabbix 又来 10 条。你一个一个点开看——CPU 飙升、内存告警、Pod 重启循环、API 响应超时、数据库连接数爆满……但你知道，大概率只是一个环节出了事，其他全是连锁反应的噪音。
这就是典型的告警风暴（Alert Storm）：一个故障触发 N 个监控工具各自报警，最后堆成几十条消息。人肉排查的过程是：依次登录每个工具 → 看日志 → 串关联 → 猜根因 → 找修复方案。半个小时后终于找到了，天已经快亮了。
如果有个 AI 能自动完成这个流程呢？
Nightwatch：只读的 AI 站点可靠性工程师
Nightwatch（内部项目名 ninoxAI）是一个 开源、本地优先、只读 的 AI SRE 工具。它的工作流是这样的：
监控告警 → 汇聚 → 聚类 → 噪声打分 → 推荐调优 → 告警看板
↓
AI 调查员：读系统 → 根因假设 → 分类修复建议
解决的核心问题
传统监控工具（Prometheus、Zabbix、Checkmk 等）擅长发出告警，但不擅长回答以下三个问题：
- 什么坏了？——50 条告警里，哪一条是根因？
- 为什么坏了？——根因是什么？代码变更？配置错误？资源耗尽？
- 该怎么办？——修复方案是什么？先修哪个？
Nightwatch 就是针对这三个问题的 AI 层。
架构亮点
1. 告警汇聚与聚类
Nightwatch 通过只读适配器从多个监控源拉取非 OK 状态的告警，统一归一化到一个 schema 上，然后按主机/服务/严重度/时间窗口聚类。
最关键的是跨工具关联：同一个故障可能同时在 Prometheus、Checkmk 和 Zabbix 中触发告警。Nightwatch 会把共享 (host, severity, time-window) 的告警群组合并成一条 Incident——”被 N 个工具确认”——而不是 N 条独立的告警。
2. AI SRE 调查员
这是 Nightwatch 最核心的能力。一个具备工具调用（Tool Calling）能力的 LLM 驱动着 只读能力白名单，通过 ReAct 循环（推理 → 行动 → 观测）在真实系统中收集证据。
它支持哪些只读能力：
| 能力 | 可读取的内容 |
|---|---|
| 🐳 Docker | 容器、日志、统计、inspect |
| ☸️ Kubernetes | Pods、日志、Events、Deployments |
| ☁️ AWS | CloudTrail、EC2、安全组、配额 |
| 📈 Grafana | PromQL + LogQL 查询 |
| 🐙 GitHub | CI runs、Releases、PRs |
| 🌿 Git | 提交、diff、代码搜索 |
| 🖥️ 主机 | CPU/内存/磁盘/进程/日志 |
每个操作都被分类为 只读 · 可逆 · 不可逆 三级，加上影响范围评估。如果 LLM 返回的操作无法识别信用等级，默认强制标记为 不可逆——绝不静默自动执行。
3. 分布式调查：ninox 运行器
一个实际的生产环境通常有多个隔离的网络段（K8s 集群、VPC、本地 IDC）。Nightwatch 通过 ninox 运行器 解决这个问题：每个 ninox 是一个轻量级的仅出站 代理，部署在目标环境内部，凭证永不离境。它主动连接 Nightwatch 大脑——不需要任何入站防火墙规则。
Nightwatch 大脑（控制面板/API/AI 调查员）
↕ 仅出站连接（ninox 主动拨号回家）
ninox 运行器（在 K8s / Docker / AWS / 本地网络中）
凭证本地保存，能力按环境自动适配
4. 连接器生态
Nightwatch 已经内置了 Checkmk、Prometheus Alertmanager、Icinga2、Zabbix、通用 Webhook 等适配器。如果还需要对接 Jira、Sentry、Postgres 等其他系统，可以通过 MCP 服务器、Python 能力插件或运行器协议扩展。
5. LLM 提供商选择
不同的任务可以用不同的模型：
- template（默认）：完全离线，不需要 LLM API，适合做摘要和推荐
- Mistral：性价比高，欧盟托管
- Anthropic：强工具调用能力，适合 AI 调查员
- OpenAI：支持 Azure 和本地模型（vLLM/Ollama/LM Studio）
所有远程调用前都会执行脱敏和密钥擦除——主机名、IP、UUID、邮箱、路径等被替换为确定性占位符，凭证则经过单向清洗，永远不会被返回。
60 秒快速体验
不需要 LLM API Key，完全本地运行：
git clone https://github.com/ninoxAI/nightwatch.git cd nightwatch cp .env.example .env # 设置 NINOXAI_SECRET_KEY（文件里有一步完成的方法） docker compose up --build # 打开 http://127.0.0.1:8765 docker compose exec ninoxai ninoxai generate-mocks docker compose exec ninoxai ninoxai import data/mock_alerts.json docker compose exec ninoxai ninoxai reprocess
执行完这几步，你就能在浏览器中看到 Nightwatch 把一堆模拟的告警噪音自动聚类、打分、生成调优建议和根因分析的全过程。
适用场景
- 告警风暴频发的团队：频繁被批量告警轰炸，需要 AI 辅助串联根因
- 多监控工具并存的环境：有 Prometheus + Zabbix + Checkmk 等多个系统，缺乏统一的告警管理视图
- 值班轮换频繁的小团队：SRE 人手不足，非值班人员不熟悉系统拓扑，需要 AI 提供上下文
- 强调安全合规的场景：只读架构 + 本地优先 + 凭证不出境，适合金融、医疗等受监管行业
与手动排障的对比
| 维度 | 传统手动排查 | 使用 Nightwatch |
|---|---|---|
| 告警数量 | 50 条逐个查看 | 自动聚合成 1-3 条 Incident |
| 根因分析 | 需要登录多个工具，人工串 log | AI 调查员自动收集证据 |
| 修复方案 | 凭经验猜测 | AI 生成按风险分级的修复建议 |
| 新人上手 | 需要数周熟悉系统拓扑 | AI 自带预注入的环境上下文 |
| 排查耗时 | 30 分钟到数小时 | 几分钟内给出根因假设 |
需要注意的几点
- 只读是设计哲学而非限制：Nightwatch 不会自动执行任何命令，所有修复建议都需要人工审批。这对安全是好事，但需要团队建立”收到建议 → 审核 → 执行”的工作流。
- AI 调查员需要 Tool-Calling 模型：免费层使用 template 驱动只能做摘要和推荐，要做根因分析需要接入 Claude、GPT 或本地 vLLM 等服务。
- 76 个 GitHub Stars（仍在早期）：Nightwatch 是一个比较新的项目，社区和文档还在快速演进中。项目使用 Apache 2.0 许可证，欢迎贡献。
总结
Nightwatch 把传统 AIOps 中”看起来很厉害但根本不敢让它碰生产”的复杂方案，简化成一个开源、本地优先、只读的 AI SRE 层。它不代替现有的监控工具，而是在它们之上增加了告警汇聚 → 根因分析 → 分类修复建议这一整套 AI 驱动的排障流程。
对于被告警风暴折磨的运维团队来说，把一个只会喊”出事了！”的监控系统，升级成一个会告诉你”哪里出事了、为什么、该怎么办”的 AI SRE——这个升级的性价比，可能比你想象中高得多。