ccfos/nightingaleMotore di allerta open-source per dati di monitoraggio di serie temporali. Si connette a Prometheus, VictoriaMetrics, ElasticSearch e altre fonti di dati. Supporta oltre 20 canali di notifica, riduzione del rumore degli avvisi, escalation e automazione di auto-riparazione.
Esperto di Alerting Open-Source
Nightingale è un progetto open-source di monitoraggio incentrato sull'alerting. Come Grafana, Nightingale si connette anche a varie sorgenti dati esistenti. Tuttavia, mentre Grafana enfatizza la visualizzazione, Nightingale pone maggiore enfasi sul motore di alerting, oltre che sull'elaborazione e la distribuzione degli allarmi.
💡 Nightingale ora supporta MCP out of the box: il server stesso espone un endpoint MCP integrato su
/mcp, così gli assistenti AI possono gestire l'alerting ed esplorare i dati di osservabilità in linguaggio naturale, senza dover distribuire processi aggiuntivi. Vedi Server MCP di seguito.Il progetto Nightingale è stato inizialmente sviluppato e reso open-source da DiDi.inc. L'11 maggio 2022 è stato donato al Comitato per lo Sviluppo dell'Open Source della China Computer Federation (CCF ODTC).
Molti utenti hanno già raccolto dati di metriche e log. In questo caso, puoi connettere i tuoi repository di storage (come VictoriaMetrics, ElasticSearch, ecc.) come sorgenti dati in Nightingale. Questo ti permette di configurare regole di alerting e regole di notifica all'interno di Nightingale, abilitando la generazione e la distribuzione degli allarmi.
Nightingale stesso non offre funzionalità di raccolta dati di monitoraggio. Consigliamo di utilizzare Categraf come collector, poiché si integra perfettamente con Nightingale.
Categraf può raccogliere dati di monitoraggio da sistemi operativi, dispositivi di rete, vari middleware e database. Invia questi dati a Nightingale tramite il protocollo Prometheus Remote Write. Nightingale memorizza quindi i dati di monitoraggio in un database time-series (come Prometheus, VictoriaMetrics, ecc.) e fornisce funzionalità di alerting e visualizzazione.
Per alcuni data center periferici con scarsa connettività di rete al server Nightingale centrale, offriamo una modalità di distribuzione distribuita per il motore di alerting. In questa modalità, anche se la rete è disconnessa, la funzionalità di alerting rimane invariata.
Nel diagramma sopra, il Data Center A ha una buona rete con il data center centrale, quindi utilizza il processo Nightingale nel data center centrale come motore di alerting. Il Data Center B ha una rete scadente con il data center centrale, quindi distribuisce
n9e-edgecome motore di alerting per gestire l'alerting delle proprie sorgenti dati.
Nightingale ha un server MCP integrato: il processo n9e stesso serve il Model Context Protocol su /mcp tramite il trasporto Streamable HTTP. Qualsiasi client MCP — Claude Code / Claude Desktop, Cursor, connettori ChatGPT o il tuo agente personalizzato — può interrogare e gestire Nightingale in linguaggio naturale, senza dover distribuire alcun processo aggiuntivo.
L'endpoint è http(s)://<nightingale>:17000/mcp — un percorso root, non sotto /api/n9e. Autenticati con un personal access token (creane uno nella UI web sotto Profilo → Gestione Token) inviato nell'header X-User-Token:
{
"mcpServers": {
"nightingale": {
"type": "http",
"url": "http://127.0.0.1:17000/mcp",
"headers": { "X-User-Token": "<your-token>" }
}
}
}
Ogni chiamata a uno strumento viene inoltrata all'API HTTP di Nightingale all'interno del processo, trasportando il tuo token, quindi le autorizzazioni RBAC e dei business group si applicano esattamente come per quell'utente nella UI — un client non può mai accedere a qualcosa che il proprietario del token non può raggiungere.
74 strumenti granulari (42 in lettura, 32 in scrittura) distribuiti su 13 toolset: alerts, targets, datasource, mutes, busi_groups, notify_rules, alert_subscribes, event_pipelines, users, metrics, logs, dashboards, roles.
L'endpoint è di sola lettura per impostazione predefinita — gli strumenti di scrittura (create / update / delete) sono un'opzione esplicita di configurazione.
Tutto quanto sotto è opzionale; /mcp è abilitato out of the box (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 riutilizza [HTTP.TokenAuth] per l'autenticazione, quindi tienilo abilitato.
/mcp accetta anche OAuth access token tramite Authorization: Bearer, in due varianti:
Oltre a MCP, lo stesso processo espone un endpoint A2A su /a2a che incapsula l'assistente AI integrato di Nightingale per l'integrazione agent-to-agent (doc/api/a2a.md). Se preferisci eseguire MCP come processo separato verso un Nightingale remoto, il n9e-mcp-server autonomo fornisce gli stessi strumenti.
Nightingale si concentra sull'essere un motore di alerting, responsabile della generazione degli allarmi e della loro distribuzione flessibile in base alle regole. Supporta 20 mezzi di notifica integrati (come chiamate telefoniche, SMS, email, DingTalk, Slack, ecc.).
Se hai requisiti più avanzati, come:
In tal caso Nightingale non è adatto. Si consiglia di scegliere prodotti on-call come PagerDuty e FlashDuty. Questi prodotti sono semplici e facili da usare.
