Foi lançado o projeto IncidentRelay 2.0, que desenvolve um sistema aberto para organizar plantões, roteamento de alertas e acompanhamento de incidentes, implementável em servidor próprio (self-hosted). O projeto é direcionado a equipes de SRE, DevOps e infraestrutura, que precisam de uma alternativa local às plataformas de gerenciamento de plantões em nuvem. O código é escrito em Python e distribuído sob a licença MIT.
O IncidentRelay recebe eventos do Prometheus Alertmanager, Grafana Alerting, Zabbix, Sentry, LibreNMS, RMON, AWS SNS/CloudWatch, Datadog, Uptime Kuma e de manipuladores de webhook arbitrários. Após a normalização, o evento é vinculado ao serviço, à equipe e à rotação, são aplicadas regras de roteamento e políticas de escalonamento, e a notificação é enviada ao plantonista atual. Para entrega, são suportados Mattermost, Slack, Telegram, Discord, Microsoft Teams, email, webhook, push no navegador/PWA e provedores de chamadas de voz.
A principal novidade da versão 2.0 é o mecanismo de Orquestração de Eventos, que fornece uma camada separada de processamento de eventos entre as integrações de entrada e o ciclo de vida do alerta. As principais mudanças são:
- 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 aninhadas e alteradas sequencialmente em prioridade, nível de importância, rótulos, equipe, rota, método de agrupamento, políticas de notificação e escalonamento;
- Implementadas 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. Suportadas verificação de configuração, publicação, reversão para versões anteriores e adição de comentários às alterações;
- Estão disponíveis os modos disabled, shadow e active. No modo shadow, os resultados da execução das regras são salvos para análise, mas não influenciam a roteação real. Para o período de transição, estão disponíveis os modos de compatibilidade legacy, hybrid e orchestration;
- Adicionados recursos de simulação e reprodução de eventos. Eles permitem testar as regras em um evento normalizado ou payload original da integração sem gerar um alerta real. Para a análise dos resultados, são fornecidas informações de rastreamento de execução, dados Explain e métricas de modo sombra.
- Implementadas ações webhook reutilizáveis, executadas de forma assíncrona após o processamento do evento. Os cabeçalhos são armazenados de forma criptografada, segredos são ocultados na API e nos logs, e chamadas para redes privadas são, por padrão, proibidas. É possível configurar timeouts, tentativas de repetição e uma lista de endereços internos permitidos.
- Adicionada integração com Uptime Kuma, que recebe mensagens de webhook padrão sobre o estado dos monitores. Implementadas a normalização dos estados UP e DOWN, a determinação de importância, o processamento de tags e um novo tipo de rota de entrada uptime_kuma.
- Para silences e janelas de manutenção foram adicionados os parâmetros apply_to_existing e reactivate_on_end. O primeiro permite aplicar a supressão a alertas já abertos, enquanto o segundo determina se deve reiniciar o processamento após o término do período de supressão. Notificações, lembretes e cadeias de escalonamento são suspensos e restaurados.
- Para tokens API pessoais, foram introduzidos direitos de leitura e modificação separados para grupos, equipes, usuários, rotas, canais, serviços, rotações, políticas, janelas de manutenção, verificações de heartbeat, SSO e orquestrações. Os antigos direitos agregados resources:read, resources:write e * foram mantidos para compatibilidade retroativa.
- Adicionado um interface de registro de auditoria com filtragem e paginação. O registro documenta operações com orquestrações, ações webhook, silences e janelas de manutenção, enquanto valores confidenciais são removidos dos dados exibidos.
- No interface web, surgiu um tema escuro e configurações personalizadas de idioma e estilo. Adicionada a localização em francês, ampliadas as traduções das seções de orquestração e manutenção, corrigida a edição de regras de correspondência de grupos SSO.
- Melhorado o funcionamento das verificações de heartbeat: eliminado a recriação de eventos de expiração, a recuperação do sinal fecha corretamente o alerta e envia uma notificação sobre a resolução do problema, e unificado a apresentação dos timestamps.
- Foi elaborada a documentação para implantação no Kubernetes usando Helm. Um manipulador separado do Slack Socket Mode foi adicionado ao chart Helm, necessário para o funcionamento dos botões interativos de confirmação e fechamento de incidentes;
- A proteção contra solicitações HTTP de saída, expressões regulares e dados confidenciais foi reforçada, o processamento em UTC e fusos horários foi centralizado, os cálculos de cronograma de rotações foram reestruturados e a cobertura de testes automáticos foi expandida.
Antes da atualização, é recomendável criar um backup do banco de dados. As mudanças necessárias no esquema são realizadas pelo mecanismo padrão de migrações do IncidentRelay. Para uma implementação gradual do Event Orchestration, os desenvolvedores recomendam inicialmente usar os modos shadow e hybrid, verificar os rastreamentos da execução das regras e só então alternar a orquestração para o modo active.
Fonte: opennet.ru
