Alertas com deduplicação: GLPI + ServiceNow + Redis
O incidente crítico não é o alerta que falta, e sim o ruído que faz o time ignorar sinais importantes.
Problema real e contexto
Alertas duplicados geravam tickets repetidos e aumento de MTTA. O fluxo entre monitoramento e ITSM precisava de controle de repetição.
A proposta foi centralizar deduplicação e roteamento antes da abertura de chamados.
Decisões técnicas
- Chave idempotente por fingerprint de alerta.
- Janela de dedup por severidade e tipo de evento.
- Redis como camada de estado temporal.
- Regras explícitas de abertura, atualização e fechamento de ticket.
Tip
Defina a fingerprint do alerta com campos estáveis para evitar falsos positivos de dedup.
Checklist final
- Padronizar payload de alerta antes da deduplicação.
- Definir TTL por criticidade e serviço.
- Registrar trilha de auditoria para cada decisão do fluxo.
- Medir redução de tickets duplicados por semana.
Erros comuns
- TTL curto demais e reabertura excessiva de incidentes.
- Fingerprint com campos voláteis.
- Falta de observabilidade no próprio pipeline de alertas.
Keywords
- alert deduplication
- incident management
- Redis
- ITSM
Related reading
- Docker → Kubernetes (K3s) em ambiente multi-tenant DevOps Checklist prático da migração para K3s: rollout, isolamento por tenant e trade-offs que evitaram incidentes.
- Observabilidade para 1.200 servidores: VictoriaMetrics vs Prometheus Observability Quando usar Prometheus puro e quando o VictoriaMetrics traz melhor retenção e custo em escala.
- Exporters Prometheus custom: Aruba, Meraki e Zabbix Observability Como padronizar métricas heterogêneas de rede e observabilidade para consultas consistentes.