ninoxAI 场景实战：凌晨三点 50 条告警，AI SRE 如何一键找出根因
场景速览：你的监控系统在凌晨 3 点狂发 50 条告警，PagerDuty 把你叫醒。你需要在 15 分钟内判断：这是磁盘满了、服务挂了、还是上游依赖断了？ninoxAI 是一个本地优先、只读的 AI SRE 工具——它先把 50 条告警聚类为 1 个故障，再用 Agent 自动调查根因，最后给出分级修复建议给人审批。
场景入口
假设你在管理一个中等规模的微服务集群，使用了 Prometheus、Checkmk、Grafana 等多套监控。一次典型的故障是这样的：
01:00 — Checkmk 告警：node3 磁盘空间 > 90% 01:02 — Prometheus 告警：api-server 响应延迟 > 5s 01:03 — Checkmk 告警：node3 上 logstash 进程不存在 01:05 — Prometheus 告警：api-server error rate > 5% ... 01:15 — 你已经收到了 50 条告警，但不知道哪条是根因
传统 SRE 的做法：在 5 个监控工具之间来回切换，先确认磁盘是否真的满了，再看日志有没有报错，然后回忆最近有没有发过新版本。如果运气好，15 分钟找到根因；运气不好，一个钟头过去了，告警还挂着。
一个 AI SRE 的思路转变
ninoxAI（项目名 Nightwatch）把这个问题拆成三步：
- 聚类：把 50 条告警按照主机、服务、时间窗口聚合成 1 个故障
- 调查：用 Agent 自动读取 Docker 日志、Kubernetes events、AWS CloudTrail 等信息，生成根因假设
- 建议：给出分级修复方案，让人类审批
关键设计原则：只读（read-only）——它不执行任何操作、不回复告警、不修改配置，所有修复建议都是给人复制粘贴的。
安装：60 秒零成本启动
ninoxAI 支持 Docker Compose 一键部署，不依赖任何 LLM API 密钥就能跑起来：
git clone https://github.com/ninoxAI/nightwatch.git cd nightwatch cp .env.example .env docker compose up --build
想立刻看到效果？跑内置的模拟数据：
docker compose exec ninoxai ninoxai generate-mocks docker compose exec ninoxai ninoxai import data/mock_alerts.json docker compose exec ninoxai ninoxai reprocess
打开 Dashboard，你就能看到模拟的 50 条告警被自动聚类成了 2-3 个故障。
连接真实监控
ninoxAI 支持多种监控源的只读接入。所有适配器都是只读的——不会 ack 告警、不会停机、不回写任何数据：
| 监控系统 | 状态 |
|---|---|
| Checkmk | ✅ 可用 |
| Prometheus Alertmanager | ✅ 可用 |
| Icinga2 | ✅ 可用 |
| Zabbix | ✅ 可用 |
| 通用 Webhook | ✅ 可用 |
| PRTG | ❌ 规划中（stub） |
配置方式很简单：在 Dashboard 的 Connections 页面填上监控系统的 API 地址和凭据，凭据用 Fernet 加密存储。
Agent 调查：自动读你的线上系统
这是 ninoxAI 最亮眼的功能。连接 LLM（支持 Anthropic、OpenAI、Mistral，也可以挂本地 Ollama），Agent 会驱动一系列只读能力去调查根因：
| 能力 | 读取的内容（全部只读） |
|---|---|
| Docker | 容器状态、日志、stats、inspect |
| Kubernetes | Pod 状态、日志、Events、Deployment |
| AWS | CloudTrail 变更事件、EC2、安全组 |
| Grafana | 通过数据源代理执行 PromQL + LogQL |
| GitHub | CI 运行、Release、PR 变更 |
| Git | 本地仓库 commit、diff、代码搜索 |
| 主机 | CPU/内存/磁盘/进程/socket/日志 |
每条 Agent 动作都被分类为 只读 · 可逆 · 不可逆 三档，加上影响范围评估。未知操作默认归入不可逆——永远不会有静默自动执行。
一个完整案例：从 50 条告警到 1 条修复建议
假设你的 api-server 掉线了，触发了一大波告警。连接到 ninoxAI 并配置好 LLM 后，Agent 的调查流程：
第一步：Agent 分析告警聚类
- 发现 38/50 条告警都关联到
api-server这个服务 - 时间窗口集中在 01:00-01:05
- 聚类结果为 1 个故障：「api-server 疑似宕机，连带触发下游依赖超时」
第二步：Agent 读取 Docker 日志
→ docker logs api-server --tail 200 → 发现 OOM Killer 杀掉进程的记录：" Memory cgroup out of memory: Killed process 12345 (api-server)"
第三步：Agent 查 Kubernetes Events
→ kubectl describe pod api-server-7d8f9g → 发现 Pod 的 memory limit 设置为 512Mi，但容器实际 peak 使用为 768Mi
第四步：Agent 生成根因假设 + 修复建议
Agent 自动生成一份报告：
📋 根因分析： api-server 容器内存限制（512Mi）低于实际需求（768Mi）， 触发 OOM Killer 导致进程退出，K8s 重启 Pod。 🔧 修复建议（按风险排序）： 1. [低风险] 将 memory limit 提升到 1Gi（kubectl patch） 2. [低风险] 添加 memory request = 768Mi，limit = 1Gi 3. [中风险] 在部署配置中添加 resources.requests 并对应调整 HPA
所有建议都附带了可以直接复制粘贴的命令，由你审批后执行。
分布式调查：ninox 哨兵节点
如果线上环境跨越多个 VPC 或 Kubernetes 集群，ninoxAI 支持部署 ninox 哨兵节点——一个轻量的、纯出站连接的 Runner：
ninoxAI 大脑（Dashboard） ←── 出站连接 ──→ ninox Runner（在目标集群内）
凭据留在本地，不留入站防火墙
每个 ninox 自动暴露自己的能力集（Docker、K8s、AWS 等），在大脑的「Parliament of Owls」视图中统一展示。大脑调用它们就像调用本地能力一样——区别只是数据不经过大脑的宿主环境。
横向对比：与其他方案的差异
| 维度 | 传统 SRE（手动） | PagerDuty + Runbook | ninoxAI |
|---|---|---|---|
| 告警聚类 | 人工在 5 个工具间切换 | 依赖规则引擎（if-then） | 语义 + 时间 + 主机聚类 |
| 根因调查 | 凭经验逐条排查 | 需要预写 Runbook | Agent 自动读线上状态 |
| 修复建议 | 自己推理 | 静态文档 | Agent 动态生成分级建议 |
| LLM 依赖 | 不依赖 | 不依赖 | 可选（template 模式离线可用） |
| 数据安全 | — | SaaS 方可能接触告警数据 | 本地优先，凭据 Fernet 加密 |
值得注意的点
- 离线可用：默认 template 模式完全离线，不调用任何 LLM API，但 Agent 调查功能需要 LLM（支持本地 Ollama）
- 连接器缺失：目前缺少 Sentry、Jira、Datadog 等常用工具的适配器，但支持通过 MCP Server 或 Python 能力插件扩展
- 定位是辅助而非替代：ninoxAI 设计的初衷是「加速人类 SRE 的判断」，不是用 AI 完全取代值班工程师
- 许可证友好：Apache 2.0，可自由用于商业和非商业项目
总结
ninoxAI 的核心价值不是「AI 取代 SRE」——而是让值班工程师在凌晨 3 点接到 50 条告警时，能在 5 分钟内而不是 30 分钟内找到根因。它的只读设计、本地优先、多监控源接入能力，组合起来让 AI SRE 从一个营销概念变成了一个可落地的开源工具。
如果你正在管理中等规模的线上服务，且每天被告警疲劳困扰，ninoxAI 值得在周末抽一小时部署试试——60 秒就能看到它在模拟数据上的效果。
项目地址：github.com/ninoxAI/nightwatch（90⭐, Apache-2.0）