Torna agli aggiornamenti
New releaseJul 25, 2026

nightingale v9.0.0

Motore 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.

Condividi

nightingale - monitoraggio cloud native

Esperto di Alerting Open-Source

Docs Docker pulls GitHub contributors GitHub Repo stars GitHub forks
GitHub Repo issues GitHub Repo issues closed GitHub latest release License GitHub contributors

English | 中文

🎯 Cos'è Nightingale

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).

💡 Come funziona Nightingale

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.

Architettura del prodotto Nightingale

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.

Modalità di distribuzione periferica

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-edge come motore di alerting per gestire l'alerting delle proprie sorgenti dati.

🤖 Server MCP

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.

Collegare un client

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.

Strumenti

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.

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.

OAuth 2.1 al posto di un token

/mcp accetta anche OAuth access token tramite Authorization: Bearer, in due varianti:

  • Nightingale agisce come authorization server stesso, con registrazione dinamica dei client RFC 7591 e PKCE, così i client ospitati come Claude o ChatGPT possono connettersi senza alcuna pre-registrazione — vedi doc/api/mcp-oauth-as.md.
  • Nightingale agisce come resource server per il tuo IdP aziendale esistente (Keycloak, Entra ID, Okta, Auth0), mappando ogni token al rispettivo utente locale in modo che permessi e audit rimangano per-persona — vedi doc/api/a2a-oauth-rs.md.

Categorie