Retour aux mises à jour
New releaseJul 25, 2026

nightingale v9.0.0

Moteur d'alerte open-source pour données de surveillance de séries temporelles. Se connecte à Prometheus, VictoriaMetrics, ElasticSearch et d'autres sources de données. Prend en charge plus de 20 canaux de notification, réduction du bruit des alertes, escalade et automatisation d'auto-guérison.

Partager

nightingale - supervision cloud native

Expert en 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

Anglais | Chinois

🎯 Qu'est-ce que Nightingale

Nightingale est un projet open source de supervision qui se concentre sur l'alerting. À l'instar de Grafana, Nightingale se connecte également à diverses sources de données existantes. Cependant, là où Grafana met l'accent sur la visualisation, Nightingale accorde une plus grande importance au moteur d'alerting, ainsi qu'au traitement et à la distribution des alarmes.

💡 Nightingale parle désormais MCP nativement : le serveur expose lui-même un endpoint MCP intégré à /mcp, si bien que les assistants IA peuvent gérer l'alerting et explorer les données d'observabilité en langage naturel, sans processus supplémentaire à déployer. Voir Serveur MCP ci-dessous.

Le projet Nightingale a été initialement développé et publié en open source par DiDi.inc. Le 11 mai 2022, il a été donné au comité de développement open source de la China Computer Federation (CCF ODTC).

💡 Comment fonctionne Nightingale

De nombreux utilisateurs ont déjà collecté des métriques et des données de logs. Dans ce cas, vous pouvez connecter vos référentiels de stockage (tels que VictoriaMetrics, ElasticSearch, etc.) comme sources de données dans Nightingale. Cela vous permet de configurer des règles d'alerting et des règles de notification dans Nightingale, permettant la génération et la distribution des alarmes.

Architecture produit Nightingale

Nightingale lui-même ne fournit pas de capacités de collecte de données de supervision. Nous recommandons d'utiliser Categraf comme collecteur, qui s'intègre parfaitement à Nightingale.

Categraf peut collecter des données de supervision depuis les systèmes d'exploitation, les équipements réseau, divers middlewares et bases de données. Il transmet ces données à Nightingale via le protocole Prometheus Remote Write. Nightingale stocke ensuite les données de supervision dans une base de données de séries temporelles (telle que Prometheus, VictoriaMetrics, etc.) et fournit des capacités d'alerting et de visualisation.

Pour certains centres de données périphériques ayant une mauvaise connectivité réseau avec le serveur Nightingale central, nous proposons un mode de déploiement distribué pour le moteur d'alerting. Dans ce mode, même si le réseau est déconnecté, la fonctionnalité d'alerting reste opérationnelle.

Mode de déploiement Edge

Dans le schéma ci-dessus, le centre de données A dispose d'un bon réseau avec le centre de données central, il utilise donc le processus Nightingale du centre de données central comme moteur d'alerting. Le centre de données B dispose d'un mauvais réseau avec le centre de données central, il déploie donc n9e-edge comme moteur d'alerting pour gérer l'alerting de ses propres sources de données.

🤖 MCP Server

Nightingale dispose d'un serveur MCP intégré : le processus n9e sert lui-même le Model Context Protocol à /mcp via le transport HTTP Streamable. Tout client MCP — Claude Code / Claude Desktop, Cursor, connecteurs ChatGPT ou votre propre agent — peut interroger et gérer Nightingale en langage naturel, sans processus supplémentaire à déployer.

Connexion d'un client

Le endpoint est http(s)://<nightingale>:17000/mcp — un chemin racine, et non sous /api/n9e. Authentifiez-vous avec un jeton d'accès personnel (créez-en un dans l'interface web sous Profil → Gestion des jetons) envoyé dans l'en-tête X-User-Token :

{
  "mcpServers": {
    "nightingale": {
      "type": "http",
      "url": "http://127.0.0.1:17000/mcp",
      "headers": { "X-User-Token": "<your-token>" }
    }
  }
}

Chaque appel d'outil est envoyé à l'API HTTP propre de Nightingale dans le processus, avec votre jeton, de sorte que les autorisations RBAC et de groupe d'affaires s'appliquent exactement comme pour cet utilisateur dans l'interface — un client ne peut jamais accéder à ce que le propriétaire de son jeton ne peut pas atteindre.

Outils

74 outils à granularité fine (42 en lecture, 32 en écriture) répartis dans 13 ensembles d'outils : alerts, targets, datasource, mutes, busi_groups, notify_rules, alert_subscribes, event_pipelines, users, metrics, logs, dashboards, roles.

Le endpoint est en lecture seule par défaut — les outils d'écriture (créer / mettre à jour / supprimer) sont une option de configuration explicite.

Configuration

Tout ce qui suit est facultatif ; /mcp est activé par défaut (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 réutilise [HTTP.TokenAuth] pour l'authentification, veillez donc à le laisser activé.

OAuth 2.1 au lieu d'un jeton

/mcp accepte également les jetons d'accès OAuth via Authorization: Bearer, sous deux variantes :

  • Nightingale agit lui-même comme serveur d'autorisation, avec l'enregistrement dynamique de clients RFC 7591 et PKCE, de sorte que les clients hébergés tels que Claude ou ChatGPT peuvent se connecter sans aucun pré-enregistrement — voir doc/api/mcp-oauth-as.md.
  • Nightingale agit comme serveur de ressources pour votre IdP d'entreprise existant (Keycloak, Entra ID, Okta, Auth0), mappant chaque jeton à son utilisateur local afin que les permissions et l'audit restent par personne — voir doc/api/a2a-oauth-rs.md.

Catégories