O IncidentRelay 2.0, um sistema de código aberto para gerenciamento de plantão, roteamento de alertas e resposta a incidentes, foi lançado. Ele pode ser implantado em um servidor próprio. O projeto é voltado para SREs, DevOps e equipes de infraestrutura que buscam uma alternativa local às plataformas de gerenciamento de plantão baseadas em nuvem. O código é escrito em Python e distribuído sob a licença MIT.
O IncidentRelay aceita eventos do Prometheus Alertmanager, Grafana Alerting, Zabbix, Sentry, LibreNMS, RMON, AWS SNS/CloudWatch, Datadog, Uptime Kuma e manipuladores de webhook personalizados. Após a normalização, o evento é associado a um serviço, equipe e rotação, as regras de roteamento e as políticas de escalonamento são aplicadas e uma notificação é enviada ao manipulador de plantão no momento. Os métodos de entrega suportados incluem Mattermost, Slack, Telegram, Discord, Microsoft Teams, e-mail, webhook, notificações push em navegadores/PWAs e provedores de chamadas de voz.
A principal inovação da versão 2.0 é o mecanismo de Orquestração de Eventos, que fornece uma camada de processamento de eventos separada entre as integrações recebidas e o ciclo de vida dos alertas. As principais alterações incluem:
- Foi adicionado um editor visual de regras de orquestração. As regras podem ser aplicadas globalmente ou a um serviço específico, agrupadas em grupos de condições aninhados e modificadas sequencialmente em relação à prioridade, nível de gravidade, rótulos, comando, rota, método de agrupamento, políticas de notificação e escalonamento.
- Implementei ações para suprimir, descartar e pausar o processamento de eventos, extrair valores usando expressões regulares e JSON Path, dividir strings, criar variáveis e converter valores;
- A configuração de orquestração é dividida em rascunhos editáveis e versões publicadas imutáveis. São suportadas a revisão da configuração, a publicação, a reversão para uma versão anterior e a adição de comentários às alterações;
- Os modos desativado, sombra e ativo estão disponíveis. No modo sombra, os resultados da execução das regras são armazenados para análise, mas não afetam o roteamento real. Os modos de compatibilidade legado, híbrido e de orquestração estão disponíveis durante um período de transição.
- Foram adicionadas ferramentas de simulação e reprodução de eventos. Elas permitem testar regras em um evento normalizado ou na carga útil de integração original sem gerar um alerta real. Rastreamentos de execução, dados explicativos e métricas do modo sombra são fornecidos para análise dos resultados.
- As ações de webhook reutilizáveis são implementadas e executadas de forma assíncrona após o processamento do evento. Os cabeçalhos são armazenados criptografados, os segredos são ocultados na API e nos logs, e o acesso a redes privadas é proibido por padrão. É possível configurar tempos limite, novas tentativas e uma lista de endereços internos permitidos.
- Adicionada integração com o Uptime Kuma, que aceita mensagens webhook padrão sobre o status do monitor. Foram implementadas a normalização dos status "Ativo" e "Inativo", a detecção de importância, o processamento de tags e um novo tipo de rota de entrada, uptime_kuma.
- Os parâmetros `apply_to_existing` e `reactivate_on_end` foram adicionados aos silenciamentos e às janelas de trabalho agendadas. O primeiro aplica a supressão a alertas já abertos, enquanto o segundo determina se o processamento deles deve ser retomado após o término do período de supressão. Notificações, lembretes e cadeias de escalonamento são pausados e restaurados.
- Para tokens de API pessoais, foram introduzidas permissões separadas de leitura e modificação para grupos, equipes, usuários, rotas, canais, serviços, rotações, políticas, janelas de manutenção, verificações de pulsação, SSO e orquestrações. As antigas permissões agregadas resources:read, resources:write e * foram mantidas para compatibilidade com versões anteriores.
- Foi adicionada uma interface de registro de auditoria com filtragem e paginação. O registro armazena operações envolvendo orquestrações, webhooks, silenciamentos e janelas de trabalho agendadas, com valores sensíveis removidos dos dados exibidos.
- A interface web agora apresenta um tema escuro e configurações de idioma e design definidas pelo usuário. A localização em francês foi adicionada, as traduções para as seções de orquestração e manutenção foram expandidas e a edição das regras de correspondência de grupos SSO foi aprimorada.
- Melhorias nas verificações de pulsação: eliminou-se a criação repetida de eventos atrasados, a recuperação do sinal fecha corretamente o alerta e envia-se uma notificação sobre a resolução do problema, e a apresentação dos registros de data e hora foi padronizada;
- A documentação para implantação do Kubernetes usando o Helm foi preparada. Um manipulador dedicado para o Modo Socket do Slack foi adicionado ao gráfico do Helm, necessário para os botões interativos de confirmação e fechamento de incidentes.
- Reforçamos a segurança das solicitações HTTP de saída, expressões regulares e dados sensíveis, centralizamos o tratamento de UTC e fusos horários, reformulamos os cálculos da escala de rotação e ampliamos a cobertura de testes automatizados.
Antes de atualizar, recomenda-se criar um backup do banco de dados. As alterações de esquema necessárias são realizadas usando o mecanismo de migração integrado do IncidentRelay. Para uma implementação gradual da Orquestração de Eventos, os desenvolvedores recomendam usar primeiro os modos sombra e híbrido, verificar os rastreamentos de execução das regras e somente então ativar a orquestração no modo ativo.
Fonte: opennet.ru
