ccfos/nightingaleOpen-Source-Benachrichtigungs-Engine für Zeitreihen-Überwachungsdaten. Verbindet sich mit Prometheus, VictoriaMetrics, ElasticSearch und anderen Datenquellen. Unterstützt über 20 Benachrichtigungskanäle, Alarm-Rauschunterdrückung, Eskalation und Self-Healing-Automatisierung.
Open-Source-Alerting-Experte
Nightingale ist ein Open-Source-Monitoring-Projekt, das sich auf Alerting konzentriert. Ähnlich wie Grafana verbindet sich Nightingale ebenfalls mit verschiedenen bestehenden Datenquellen. Während Grafana jedoch den Schwerpunkt auf Visualisierung legt, fokussiert Nightingale stärker auf die Alerting-Engine sowie auf die Verarbeitung und Verteilung von Alarmen.
💡 Nightingale unterstützt MCP jetzt direkt out of the box: Der Server selbst stellt einen integrierten MCP-Endpunkt unter
/mcpbereit, sodass KI-Assistenten Alerting verwalten und Observability-Daten in natürlicher Sprache erkunden können – ohne dass ein zusätzlicher Prozess bereitgestellt werden muss. Siehe MCP Server unten.Das Nightingale-Projekt wurde ursprünglich von DiDi.inc entwickelt und als Open Source veröffentlicht. Am 11. Mai 2022 wurde es dem Open-Source-Entwicklungsausschuss der China Computer Federation (CCF ODTC) gespendet.
Viele Nutzer sammeln bereits Metriken und Logdaten. In diesem Fall können Sie Ihre Speicher-Repositories (wie VictoriaMetrics, ElasticSearch usw.) als Datenquellen in Nightingale anbinden. So können Sie Alerting-Regeln und Benachrichtigungsregeln in Nightingale konfigurieren und damit die Erzeugung und Verteilung von Alarmen ermöglichen.
Nightingale selbst bietet keine Funktionen zur Erfassung von Monitoring-Daten. Wir empfehlen, Categraf als Collector einzusetzen, das sich nahtlos in Nightingale integriert.
Categraf kann Monitoring-Daten von Betriebssystemen, Netzwerkgeräten, verschiedenen Middleware-Komponenten und Datenbanken sammeln. Es überträgt diese Daten über das Prometheus Remote Write-Protokoll an Nightingale. Nightingale speichert die Monitoring-Daten anschließend in einer Zeitreihendatenbank (wie Prometheus, VictoriaMetrics usw.) und bietet Alerting- und Visualisierungsfunktionen.
Für bestimmte Edge-Rechenzentren mit schlechter Netzwerkanbindung zum zentralen Nightingale-Server bieten wir einen verteilten Bereitstellungsmodus für die Alerting-Engine an. In diesem Modus bleibt die Alerting-Funktionalität auch bei getrennter Netzwerkverbindung uneingeschränkt erhalten.
Im obigen Diagramm verfügt Rechenzentrum A über eine gute Netzwerkanbindung zum zentralen Rechenzentrum und nutzt daher den Nightingale-Prozess im zentralen Rechenzentrum als Alerting-Engine. Rechenzentrum B hat eine schlechte Netzwerkanbindung zum zentralen Rechenzentrum und setzt daher
n9e-edgeals Alerting-Engine ein, um das Alerting für seine eigenen Datenquellen zu übernehmen.
Nightingale verfügt über einen integrierten MCP-Server: Der n9e-Prozess selbst stellt das Model Context Protocol unter /mcp über den Streamable-HTTP-Transport bereit. Jeder MCP-Client – Claude Code / Claude Desktop, Cursor, ChatGPT-Konnektoren oder Ihr eigener Agent – kann Nightingale in natürlicher Sprache abfragen und verwalten, ohne dass ein zusätzlicher Prozess bereitgestellt werden muss.
Der Endpunkt ist http(s)://<nightingale>:17000/mcp – ein Root-Pfad, nicht unter /api/n9e. Authentifizieren Sie sich mit einem persönlichen Zugriffstoken (in der Web-UI unter Profil → Token-Verwaltung erstellen), das im X-User-Token-Header gesendet wird:
{
"mcpServers": {
"nightingale": {
"type": "http",
"url": "http://127.0.0.1:17000/mcp",
"headers": { "X-User-Token": "<your-token>" }
}
}
}
Jeder Tool-Aufruf wird innerhalb des Prozesses an Nightingales eigene HTTP-API weitergeleitet und trägt Ihr Token, sodass RBAC- und Business-Group-Berechtigungen exakt so greifen wie für diesen Benutzer in der UI – ein Client kann niemals auf etwas zugreifen, das der Inhaber des Tokens nicht erreichen kann.
74 feingranulare Tools (42 lesend, 32 schreibend) in 13 Toolsets: alerts, targets, datasource, mutes, busi_groups, notify_rules, alert_subscribes, event_pipelines, users, metrics, logs, dashboards, roles.
Der Endpunkt ist standardmäßig schreibgeschützt – die Schreib-Tools (create / update / delete) sind ein expliziter Konfigurations-Opt-in.
Alles unten ist optional; /mcp ist standardmäßig aktiviert (etc/config.toml):
[HTTP.A2A]
# DisableMCP = true # turn off /mcp (Disable = true turns off /a2a as well)
# MCPToolsets = ["alerts", "dashboards"] # restrict the exposed toolsets; empty = all of them
# MCPEnableWriteTools = true # also register the write tools; read-only by default
/mcp verwendet [HTTP.TokenAuth] für die Authentifizierung – lassen Sie diese daher aktiviert.
/mcp akzeptiert auch OAuth-Zugriffstokens über Authorization: Bearer, in zwei Varianten:
Neben MCP stellt derselbe Prozess einen A2A-Endpunkt unter /a2a bereit, der Nightingales integrierten KI-Assistenten für die Agent-zu-Agent-Integration kapselt (doc/api/a2a.md). Wenn Sie MCP lieber als separaten Prozess gegen ein entferntes Nightingale ausführen möchten, bietet der eigenständige n9e-mcp-server dieselben Tools.
Nightingale konzentriert sich darauf, eine Alerting-Engine zu sein, die für die Erzeugung von Alarmen und deren flexible Verteilung auf Basis von Regeln verantwortlich ist. Es unterstützt 20 integrierte Benachrichtigungsmedien (wie Telefonanrufe, SMS, E-Mail, DingTalk, Slack usw.).
Wenn Sie weitergehende Anforderungen haben, wie etwa:
Dann ist Nightingale nicht geeignet. Wir empfehlen, auf On-Call-Produkte wie PagerDuty und FlashDuty zurückzugreifen. Diese Produkte sind einfach und leicht zu bedienen.
