Voltar às atualizações
New releaseJul 25, 2026

nightingale v9.0.0

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

Compartilhar

nightingale - monitoramento nativo de nuvem

Especialista em Alertas 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

Inglês | Chinês

🎯 O que é o Nightingale

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

💡 Como o Nightingale Funciona

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.

Arquitetura de Produto do Nightingale

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.

Modo de Implantação na Borda

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-edge como motor de alertas para lidar com os alertas de suas próprias fontes de dados.

🤖 Servidor MCP

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.

Conectando um cliente

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.

Ferramentas

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.

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.

OAuth 2.1 em vez de um token

/mcp também aceita tokens de acesso OAuth via Authorization: Bearer, em duas variantes:

  • O Nightingale atua como o próprio servidor de autorização, com registro dinâmico de clientes RFC 7591 e PKCE, de modo que clientes hospedados como Claude ou ChatGPT possam se conectar sem pré-registro — veja doc/api/mcp-oauth-as.md.
  • O Nightingale atua como servidor de recursos para seu IdP corporativo existente (Keycloak, Entra ID, Okta, Auth0), mapeando cada token para seu usuário local, de modo que permissões e auditoria permaneçam por pessoa — veja doc/api/a2a-oauth-rs.md.

Categorias