nightingale v9.0.0

Open-Source-Alerting-Experte

English | 中文

🎯 Was ist Nightingale

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 /mcp bereit, 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.

💡 So funktioniert Nightingale

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-edge als Alerting-Engine ein, um das Alerting für seine eigenen Datenquellen zu übernehmen.

🤖 MCP Server

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.

Einen Client verbinden

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.

Tools

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.

Konfiguration

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.

OAuth 2.1 statt Token

/mcp akzeptiert auch OAuth-Zugriffstokens über Authorization: Bearer, in zwei Varianten:

• Nightingale fungiert selbst als Autorisierungsserver, mit dynamischer Client-Registrierung nach RFC 7591 und PKCE, sodass gehostete Clients wie Claude oder ChatGPT ohne jegliche Vorregistrierung eine Verbindung herstellen können – siehe doc/api/mcp-oauth-as.md.
• Nightingale fungiert als Ressourcenserver für Ihren bestehenden Enterprise-IdP (Keycloak, Entra ID, Okta, Auth0) und ordnet jedes Token seinem lokalen Benutzer zu, sodass Berechtigungen und Audit pro Person erhalten bleiben – siehe doc/api/a2a-oauth-rs.md.