ccfos/nightingaleMotor de alerta de código aberto para dados de monitoramento de séries temporais. Conecta-se ao Prometheus, VictoriaMetrics, ElasticSearch e outras fontes de dados. Suporta mais de 20 canais de notificação, redução de ruído de alertas, escalonamento e automação de autocorreção.
Especialista em Alertas Open-Source
O Nightingale é um projeto de monitoramento open-source focado em alertas. Assim como o Grafana, o Nightingale também se conecta a diversas fontes de dados existentes. No entanto, enquanto o Grafana enfatiza a visualização, o Nightingale dá maior ênfase ao motor de alertas, bem como ao processamento e à distribuição de alarmes.
💡 O Nightingale agora suporta MCP pronto para uso: o próprio servidor expõe um endpoint MCP integrado em
/mcp, permitindo que assistentes de IA gerenciem alertas e explorem dados de observabilidade em linguagem natural, sem a necessidade de implantar um processo extra. Veja Servidor MCP abaixo.O projeto Nightingale foi inicialmente desenvolvido e aberto como open-source pela DiDi.inc. Em 11 de maio de 2022, foi doado ao Comitê de Desenvolvimento de Código Aberto da Federação Chinesa de Computação (CCF ODTC).
Muitos usuários já coletam métricas e dados de logs. Nesse caso, você pode conectar seus repositórios de armazenamento (como VictoriaMetrics, ElasticSearch etc.) como fontes de dados no Nightingale. Isso permite configurar regras de alerta e regras de notificação dentro do Nightingale, possibilitando a geração e a distribuição de alarmes.
O Nightingale em si não oferece capacidades de coleta de dados de monitoramento. Recomendamos usar o Categraf como coletor, que se integra perfeitamente ao Nightingale.
O Categraf pode coletar dados de monitoramento de sistemas operacionais, dispositivos de rede, diversos middlewares e bancos de dados. Ele envia esses dados ao Nightingale via protocolo Prometheus Remote Write. O Nightingale então armazena os dados de monitoramento em um banco de dados de séries temporais (como Prometheus, VictoriaMetrics etc.) e fornece capacidades de alerta e visualização.
Para determinados data centers de borda com conectividade de rede ruim com o servidor central do Nightingale, oferecemos um modo de implantação distribuída para o motor de alertas. Nesse modo, mesmo que a rede seja desconectada, a funcionalidade de alertas permanece inalterada.
No diagrama acima, o Data Center A possui boa conectividade de rede com o data center central, por isso usa o processo do Nightingale no data center central como motor de alertas. O Data Center B possui conectividade de rede ruim com o data center central, por isso implanta
n9e-edgecomo motor de alertas para lidar com os alertas de suas próprias fontes de dados.
O Nightingale possui um Servidor MCP integrado: o próprio processo n9e atende ao Model Context Protocol em /mcp por meio do transporte HTTP Streamable. Qualquer cliente MCP — Claude Code / Claude Desktop, Cursor, conectores ChatGPT ou seu próprio agente — pode consultar e gerenciar o Nightingale em linguagem natural, sem a necessidade de implantar um processo extra.
O endpoint é http(s)://<nightingale>:17000/mcp — um caminho raiz, não sob /api/n9e. Autentique-se com um token de acesso pessoal (criado na interface web em Perfil → Gerenciamento de Tokens) enviado no cabeçalho X-User-Token:
{
"mcpServers": {
"nightingale": {
"type": "http",
"url": "http://127.0.0.1:17000/mcp",
"headers": { "X-User-Token": "<your-token>" }
}
}
}
Cada chamada de ferramenta é despachada para a própria API HTTP do Nightingale dentro do processo, carregando seu token, de modo que as permissões de RBAC e de grupos de negócios se aplicam exatamente como para aquele usuário na interface — um cliente nunca pode acessar algo que o dono do token não possa.
74 ferramentas granulares (42 de leitura, 32 de escrita) em 13 conjuntos de ferramentas: alerts, targets, datasource, mutes, busi_groups, notify_rules, alert_subscribes, event_pipelines, users, metrics, logs, dashboards, roles.
O endpoint é somente leitura por padrão — as ferramentas de escrita (criar / atualizar / excluir) são uma adesão explícita via configuração.
Tudo abaixo é opcional; /mcp já está habilitado nativamente (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 reutiliza [HTTP.TokenAuth] para autenticação, portanto mantenha isso habilitado.
/mcp também aceita tokens de acesso OAuth via Authorization: Bearer, em duas variantes:
Junto com o MCP, o mesmo processo expõe um endpoint A2A em /a2a que encapsula o assistente de IA integrado do Nightingale para integração agente-a-agente (doc/api/a2a.md). Se você preferir executar o MCP como um processo separado contra um Nightingale remoto, o n9e-mcp-server autônomo fornece as mesmas ferramentas.
O Nightingale foca em ser um motor de alertas, responsável por gerar alarmes e distribuí-los com flexibilidade com base em regras. Ele suporta 20 mídias de notificação integradas (como chamadas telefônicas, SMS, e-mail, DingTalk, Slack etc.).
Se você tiver requisitos mais avançados, como:
Então o Nightingale não é adequado. Recomenda-se escolher produtos de plantão como PagerDuty e FlashDuty. Esses produtos são simples e fáceis de usar.
