Nightingale: Alerting-Engine für bestehende Metrik-Quellen
Nightingale ist für die Überwachung und Alarmierung zuständig, was Grafana für die Visualisierung ist.
Auf einen Blick
- Was ist das?
- Bewertung von Nightingale (n9e) als Alerting-Schicht über Prometheus, VictoriaMetrics und ElasticSearch, inklusive Categraf-Datenfluss, MCP-Endpunkt und den von der README selbst gezogenen Grenzen.
- Für wen ist es gedacht?
- Nightingale passt für Teams, die Zeitreihen bereits in Prometheus, VictoriaMetrics oder ElasticSearch halten und eine eigene Alerting-Engine mit 20 Benachrichtigungskanälen, Event-Pipelines und optionalem MCP-Zugriff suchen. Unpassend ist es als Collector-Ersatz, als Grafana-Alternative für komplexe Dashboards und als On-Call-Portal mit Eskalation, wofür die README PagerDuty oder FlashDuty nennt.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Go, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Nightingale als Alerting-Engine neben Grafana und Prometheus
Nightingale positioniert sich laut README als Open-Source-Monitoring-Projekt mit Fokus auf Alerting. Die Analogie im Projekttext lautet: Was Grafana für die Visualisierung ist, soll n9e für Alarme sein. Praktisch heißt das, das Werkzeug bindet bestehende Datenspeicher an und kümmert sich um Regelprüfung, Ereignisverarbeitung und Zustellung. Gesammelt werden die Messwerte woanders. Das Projekt wurde ursprünglich von DiDi entwickelt und am 11. Mai 2022 an das Open Source Development Committee der China Computer Federation (CCF ODTC) übergeben. Die Repository-Metadaten nennen Go als Implementierungssprache und Apache-2.0 als Lizenz, weisen rund 13.273 Sterne sowie 242 offene Issues aus und zeigen einen aktiven Hauptzweig main, zuletzt gepusht vor dem Release v9.1.1 vom 18. August 2026.
Datenfluss von Categraf bis VictoriaMetrics über Remote Write
Der Datenfluss beginnt beim Collector. Nightingale selbst bietet nach Angaben der README keine Datenerfassung; empfohlen wird Categraf aus dem Hause FlashCat, das Betriebssysteme, Netzgeräte, Middleware und Datenbanken abfragt und die Ergebnisse per Prometheus Remote Write an n9e schiebt. Dort landen die Zeitreihen in einer angeschlossenen Datenbank wie Prometheus oder VictoriaMetrics. Neben Remote Write akzeptiert die Engine laut README auch Formate nach OpenTSDB, Datadog und Falcon, was den Wechsel bestehender Agents erleichtert. Als abfragbare Quellen für Regelprüfungen listet die Dokumentation Prometheus, ElasticSearch, Loki, ClickHouse, MySQL und Postgres auf, Alarmierung ist also über jede dieser Quellen möglich.
Ein praktischer Hinweis steht ebenfalls in der README: Categraf orientiert sich bei den Metriknamen an Telegraf, nicht an Node Exporter. Für Maschinenmetriken empfiehlt das Projekt deshalb die mitgelieferten n9e-Dashboards, weil die Namen sonst nicht zur Erwartung passen.
Alarmregeln, Mute-Regeln und 20 Benachrichtigungsmedien in n9e
Für die Alarmierung liefert n9e Alert-Regeln, Mute-Regeln, Abonnement-Regeln und Benachrichtigungsregeln, verwaltet in einem Berechtigungssystem auf Basis von Business Groups. Laut README sind 20 Benachrichtigungsmedien eingebaut, von Telefonanruf und SMS über E-Mail bis DingTalk und Slack; die Nachrichtenvorlagen lassen sich anpassen. Viele Datenbanken und Middleware-Komponenten bringen fertige Regelimporte mit, auch Prometheus-Regeln lassen sich übernehmen. Event-Pipelines verarbeiten Ereignisse vor der Zustellung, etwa durch Relabeling oder das Anhängen interner Metadaten für eigene Systeme.
Für Selbstheilung startet die Engine nach einem Alarm ein Skript mit vordefinierter Logik, beispielsweise zum Räumen von Speicherplatz oder zum Sammeln des aktuellen Systemzustands. Ob dieses Skript-Modell in der eigenen Umgebung tragbar ist, hängt davon ab, wer Business Groups und Regeln verwalten darf; die Feinheiten der Rechtevergabe beschreibt die README an dieser Stelle nicht.
MCP-Endpunkt /mcp mit X-User-Token und 74 Tools
Der auffälligste Baustein ist der eingebaute MCP-Server. Der n9e-Prozess bedient das Model Context Protocol direkt unter /mcp per Streamable HTTP, der Endpunkt liegt also unter http(s)://<nightingale>:17000/mcp und nicht unter /api/n9e. Die Authentifizierung läuft über ein persönliches Zugriffstoken aus der Web-UI (Profil, Token Management), das im Header X-User-Token mitgeschickt wird. Jeder Toolaufruf wird im Prozess auf die eigene HTTP-API von Nightingale umgeleitet und trägt dieses Token, RBAC- und Gruppenrechte gelten also unverändert; ein Client erreicht niemals mehr als sein Token-Inhaber in der UI.
Die README zählt 74 Tools in 13 Toolsets auf, von alerts, targets, datasource und mutes bis dashboards und roles. Standardmäßig ist der Endpunkt nur lesend, Schreiboperationen werden über MCPEnableWriteTools in etc/config.toml freigeschaltet, zusätzlich lassen sich Toolsets mit MCPToolsets einschränken. Zusätzlich versteht /mcp OAuth-Bearer-Tokens, entweder mit Nightingale als Autorisierungsserver (RFC 7591 mit dynamischer Registrierung und PKCE) oder als Ressourcenserver vor Keycloak, Entra ID, Okta oder Auth0. Wer MCP als separaten Prozess gegen eine entfernte Instanz betreibt, findet dafür das eigenständige Repository n9e/n9e-mcp-server.
n9e-edge für Rechenzentren mit schwacher Anbindung
Für Standorte mit schlechter Verbindung zum Zentrum beschreibt die README einen verteilten Modus der Alerting-Engine. Im Beispieldiagramm nutzt Rechenzentrum A den zentralen n9e-Prozess, während Rechenzentrum B n9e-edge betreibt und seine eigenen Datenquellen lokal prüft. Bleibt die Verbindung zum zentralen Standort getrennt, funktioniert die Alarmierung laut README trotzdem weiter.
Was das Dokument an dieser Stelle nicht liefert: Bereitstellungsschritte für n9e-edge, Ressourcenbedarf und das Schicksal von Ereignissen, die während einer Unterbrechung warten. Wer dieses Muster plant, sollte vor der Einführung an einem Teststandort prüfen, wie die Edge-Konfiguration anzulegen ist und ob Benachrichtigungen aus dem Edge nachgeholt oder verworfen werden; dazu schweigt die README, die Antworten stehen in der Dokumentation bei flashcat.cloud oder im Issue-Tracker.
Grenzen laut README: PagerDuty statt Nightingale bei On-Call
Die README zieht selbst enge Grenzen. Nightingale sei nicht geeignet, wenn Ereignisse aus mehreren Monitoring-Systemen auf einer Plattform zusammengeführt, Rauschen einheitlich reduziert, Bereitschaftsdienste nach Plänen verteilt und Alarme eskaliert werden sollen; dafür verweist das Projekt auf On-Call-Produkte wie PagerDuty oder FlashDuty. Auch bei der Visualisierung empfiehlt der Text Grafana für alle, die dort bereits Erfahrung haben, weil die Expertise dieses Ökosystems tiefer sitzt.
Diese Ehrlichkeit spart Integrationsaufwand. Wer nur Alarmregeln auf vorhandenen Zeitreihen braucht, bleibt bei n9e. Wer ein vollständiges On-Call-Portal mit Dienstplänen und Statistiken sucht, installiert es daneben und lässt n9e lediglich die Ereigniserzeugung übernehmen. Eine dritte Variante ist der Einsatz als reine Alerting-Schicht hinter Grafana-Dashboards mit Categraf als Collector.
Releases bis v9.1.1 und Lizenz Apache-2.0
Die Metadaten zeigen eine aktive Entwicklung: v9.0.0 erschien am 25. Juli 2026, v9.1.0 am 6. August, v9.1.1 am 18. August 2026. Die Lizenz ist Apache-2.0, die Patentklausel endet für denjenigen, der eine Patentklage gegen das Werk einreicht. Für kommerzielle Nutzung bleiben damit kaum Hürden, beim Fork gelten die üblichen Bedingungen dieser Lizenz. Erste Anlaufstellen sind die Projektseite n9e.github.io und die Dokumentation bei flashcat.cloud, Fehlermeldungen laufen über den GitHub-Issue-Tracker.
Die README macht keine Zusagen zu Support oder Gewährleistung. Wer interne SLA-Anforderungen hat, muss diese Punkte über die Dokumentation oder die Community-Kanäle klären, bevor n9e in der Produktion landet.
Redaktionelles Fazit
Nightingale passt für Teams, die Zeitreihen bereits in Prometheus, VictoriaMetrics oder ElasticSearch halten und eine eigene Alerting-Engine mit 20 Benachrichtigungskanälen, Event-Pipelines und optionalem MCP-Zugriff suchen. Unpassend ist es als Collector-Ersatz, als Grafana-Alternative für komplexe Dashboards und als On-Call-Portal mit Eskalation, wofür die README PagerDuty oder FlashDuty nennt. Vor der Einführung lohnt ein Test, ob /mcp mit einem X-User-Token in der eigenen RBAC-Konfiguration sauber antwortet.
Community-Notizen