Exemplos resolvidos para IncidentRelay v2.3.1, verificado em . Os nomes, identificadores e horários abaixo são ilustrativos; valide-os em uma implantação de teste antes de usar credenciais de produção.
Exemplo de negócios · Configuração · Exemplo prático · Verificações de aceitação · Limites e modos de falha
Exemplo de negócio: três sistemas clientes, um chat de suporte barulhento
Cenário ilustrativo, não um estudo de caso de cliente. As métricas abaixo são sugestões para o seu piloto, não economias medidas ou uma afirmação de que o RI inclui todos os painéis de relatórios.
Situação e risco. Um provedor de serviços oferece suporte a três clientes, cada um com alertas de aplicativos e infraestrutura. Tudo cai em um bate-papo. Os engenheiros encaminham mensagens para outras equipes enquanto alertas repetidos enterram o relatório original. O risco comercial é a propriedade atrasada e o esforço de suporte evitável, mesmo quando o monitoramento detectou a falha prontamente.
Fluxo de trabalho com IR. Mapeie cada serviço do cliente para sua equipe responsável e use o token de rota pretendido para cada remetente. Combine rótulos de ambiente e serviço, escolha o alvo de plantão e agrupe repetições apenas dentro do limite de propriedade pretendido. Teste o serviço de faturamento de produção de um cliente usando o matcher abaixo antes de estender o padrão.
Benefício operacional a ser validado. Substitua o encaminhamento rotineiro de mensagens por roteamento explícito. Mantenha a primeira resposta com a equipe que pode agir, preservando alertas separados para crianças quando vários hosts reportarem o mesmo problema.
O que medir. Contar alertas reatribuídos após a primeira decisão de roteamento, grupos sem proprietário e notificações por falha subjacente para cada cliente. Revise também os eventos de teste rejeitados ou sem correspondência: menos páginas não será um sucesso se a interrupção de um cliente se tornar invisível.
Limite. A correspondência de rótulo não é o isolamento de dados do cliente. Revise as permissões de acesso, credenciais e limites de implantação separadamente. Rótulos inconsistentes ou agrupamentos excessivamente amplos ainda podem enviar trabalho para a equipe errada ou combinar sintomas não relacionados; valide esses casos antes de integrar outro cliente.
Entrada, propriedade e entrega separadas
Um serviço de faturamento de produção e uma cópia de teste não devem acordar as mesmas pessoas por acidente. Para o primeiro piloto, crie uma rota de Webhook para a equipe de faturamento de produção, selecione seu serviço e rotação ou política padrão e anexe canais. Seu token de entrada seleciona a rota; os rótulos correspondentes por si só não autenticam um remetente nem selecionam uma rota arbitrária.
Uma correspondência de rota estreita e uma chave de agrupamento explícita
Cole isso no editor correspondente da rota. É um objeto correspondente, não o corpo do webhook de entrada. Todas as condições usam semântica AND. A exigência de rótulos de produção e de serviço mantém a preparação e os eventos não rotulados fora desse caminho.
{
"source": "webhook",
"labels": {
"environment": "production",
"service": "billing-api"
}
}Neste exemplo, defina o campo group_by da rota como:
["alertname", "severity", "labels.cluster"]Dois hosts que relatam o mesmo alerta no mesmo cluster podem então compartilhar um AlertGroup, mantendo identidades filhas separadas. Para um webhook genérico, use impressões digitais estáveis, como billing:node-1:health e billing:node-2:health. Inclua os rótulos esperados em caso de falha e recuperação e nunca use um novo carimbo de data/hora como identidade de cada nova tentativa.
Desduplicação e agrupamento são diferentes: a mesma impressão digital atualiza um filho; impressões digitais diferentes com a mesma chave de grupo criam filhos separados em um grupo. Rota, equipe, origem e serviço também agrupam escopo. Adicione instance aos campos de agrupamento somente se cada host for um grupo separado.
Quando um remetente realmente atende várias equipes
Use a orquestração global quando a propriedade precisar ser escolhida no conteúdo do evento. No Construtor, comece com as condições labels.environment equals production e labels.service equals billing-api e, em seguida, selecione objetos válidos de equipe, rota e serviço do mesmo grupo. Não copie IDs de objetos numéricos entre instalações.
Valide e simule correspondências e não correspondências, publique e use shadow com compatibilidade hybrid. Revise as execuções reais antes de mudar para active. Shadow registra decisões sem alterar o comportamento da produção; o Simulador não comprova a entrega ponta a ponta.
Use uma pequena matriz de teste de roteamento
| Entrada | Resultado esperado para este exemplo |
|---|---|
| Evento de faturamento de produção | Passes de matcher; o serviço, o responsável e os canais selecionados correspondem à propriedade planejada. |
| Preparação ou rótulo de serviço ausente | Matcher não passa. Confirme o caminho alternativo pretendido pelo remetente; este exemplo não cria uma rota abrangente. |
| Impressão digital duplicada | A mesma criança é atualizada. Uma impressão digital de host diferente cria um segundo filho no mesmo grupo quando os rótulos de agrupamento correspondem. |
| Recuperação de apenas um dos dois filhos | Essa criança resolve; o grupo continua atirando até que todas as crianças que dispararam se recuperem. Uma recuperação órfã não cria nenhum novo grupo. |
Evite regras que apagam silenciosamente as evidências
Um matcher vazio corresponde a tudo. Um rótulo denominado severity não é automaticamente o mesmo campo que a gravidade do evento normalizado; use o caminho do campo documentado e inspecione um evento normalizado real. Não exija status=firing em um caminho de entrada que também precise aceitar recuperação.
active + legacy não aplica decisões de orquestração. Em hybrid, combinações de entidades inválidas podem retornar ao caminho herdado; o modo autoritativo orchestration bloqueia o processamento em falhas de avaliação ou validação de entidade. Escolha o comportamento de falha intencionalmente.
Comece sem regras drop ou suppress amplas. A supressão e o agrupamento podem reduzir as notificações, mas nenhum deles torna útil um sinal de monitoramento ruim. Mantenha uma versão anterior testada e revise as não correspondências inesperadas antes de expandir o lançamento.