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.
Expert en alerting open source
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).
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.
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.
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-edgecomme moteur d'alerting pour gérer l'alerting de ses propres sources de données.
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.
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.
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.
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é.
/mcp accepte également les jetons d'accès OAuth via Authorization: Bearer, sous deux variantes :
En plus de MCP, le même processus expose un endpoint A2A à /a2a qui encapsule l'assistant IA intégré de Nightingale pour l'intégration agent-à-agent (doc/api/a2a.md). Si vous préférez exécuter MCP comme un processus séparé pointant vers une instance Nightingale distante, le serveur autonome n9e-mcp-server fournit les mêmes outils.
Nightingale se concentre sur son rôle de moteur d'alerting, chargé de générer des alarmes et de les distribuer de manière flexible en fonction de règles. Il prend en charge 20 médias de notification intégrés (tels que les appels téléphoniques, les SMS, les e-mails, DingTalk, Slack, etc.).
Si vous avez des besoins plus avancés, par exemple :
Dans ce cas, Nightingale n'est pas adapté. Il est recommandé de choisir des produits d'astreinte tels que PagerDuty et FlashDuty. Ces produits sont simples et faciles à utiliser.
