ccfos/nightingale

项目介绍

Nightingale 是一个架在现有监控数据之上的告警与事件路由层。它直接查询你已经运行的 Prometheus、VictoriaMetrics、Elasticsearch、Loki、ClickHouse 等数据源，用 PromQL、日志查询或 SQL 定义告警条件，处理后把通知发往 Slack、PagerDuty、Discord、邮件、Telegram、Mattermost、Jira 以及 Webhook。规则和看板按业务组组织并分配团队权限，登录可接 OIDC、OAuth2、LDAP 或 CAS。

它适合已有采集器和存储、但需要集中管理规则归属、追查告警为何触发或为何没送达的 SRE 和平台团队。远程数据源可用 n9e-edge 就近评估；内置 TSDB 和 Categraf 采集器只是小规模部署的可选项，可视化仍交给 Grafana，排班升级仍交给专门的 on-call 平台。

Web UI 内置 AI agent，可排查告警、检查评估日志与通知结果，并在确认后修改规则或看板。外部 agent 可通过内置 MCP 服务（/mcp）调用工具，或经 A2A 委派任务。告警核心不依赖 AI。

快速使用

准备 Git 和 Docker Compose，在仓库目录下启动自带的评估环境：

git clone https://github.com/ccfos/nightingale.git
cd nightingale/docker/compose-bridge
docker compose up -d

该栈会启动 Nightingale、MySQL、Redis、VictoriaMetrics 和 Categraf。打开 http://localhost:17000，用 root / root.2020 登录。

1. 接入数据源：填已有的 Prometheus 兼容地址，或使用栈内 VictoriaMetrics 的 http://victoriametrics:8428。
2. 在某个业务组下创建告警规则，填 PromQL 表达式，例如 vector(1) > 0，持续时长设为 0，得到一条持续触发的测试告警。
3. 创建通知渠道和通知规则，挂到该告警规则上，确认测试通知能收到，然后停用测试告警。

Compose 文件使用示例口令并对外暴露服务端口，仅适合本地评估；在共享主机上运行前要改口令并检查网络暴露。其他部署方式包括 Release 中的 Linux 二进制、Kubernetes 用的 Helm chart，以及安装文档。

使用约束

生产部署应固定版本、配置口令与 TLS、备份元数据库，并监控规则评估和通知失败。多实例共享 MySQL 元数据库和 Redis，且需要外部时序存储；内置 TSDB 只适用于单实例、本地磁盘。Compose 栈仅供本地评估。

Prometheus YAML 告警规则可以导入，但 alertmanager.yml 的路由不会完整转换，切换通知前应让两套系统并行一段时间。规则可以导出为 JSON 并通过 HTTP API 修改，便于接入 Git/CI，但项目本身没有规则修订历史或回滚。

AI 助手会把提示词和取到的监控数据发给你配置的 OpenAI 兼容、Claude、Gemini 或自托管模型端点，模型凭据和费用由你承担。MCP 的写工具需要显式开启，服务端沿用调用者已有的 API 权限。排班与升级不由项目提供，需要另接 PagerDuty 一类平台。项目采用 Apache-2.0 许可证。

HotRepo 点评

2026-11-04，Nightingale 在 GitHub Go 日榜上排到第 16 名，当天新增 10 星。对一个 2020 年就公开、如今约 1.34 万星的项目来说，这个位置比较平淡，符合成熟自托管 SRE 工具的特征：价值在于把分散的告警规则和通知路由收拢到一处，而不是替代 Prometheus 或 Grafana。2023 年的一条 Hacker News 讨论把它称为 Prometheus 与 Grafana 的开源替代，有评论者把它视作一体化方案；现在 README 的定位更收敛，只做告警层，可视化留给 Grafana、升级排班留给 on-call 平台。按这个边界来评估它更有参考价值。