Operadoras, dependências e correlação

29 alarmes não significam necessariamente 29 falhas

Imagine três operadoras atendendo 100 circuitos: 40, 30 e 30. Se 29 dos 40 circuitos da Operadora A ficarem indisponíveis quase ao mesmo tempo, olhar apenas para a lista de problemas produz 29 sintomas. Para a operação, porém, existe forte evidência de uma causa comum.

OPERADORA A              OPERADORA B              OPERADORA C
40 circuitos              30 circuitos              30 circuitos

11 UP                     30 UP                     30 UP
29 DOWN                    0 DOWN                    0 DOWN

72,5% indisponíveis        0% indisponíveis          0% indisponíveis
        │
        ▼
FORTE INDÍCIO DE FALHA COMUM

Dependência, correlação, Services e agregação não são a mesma coisa

A correlação começa muito antes do incidente

Eventos de trigger podem carregar tags. Essas tags podem ser usadas em ações, filtros de problemas e correlação. Sem uma taxonomia consistente, o Zabbix sabe que existem vários problemas, mas não necessariamente qual contexto operacional os conecta.

carrier=operadora-a
circuit=CIR-A-001
site=rj-centro
region=rj
service=internet
scope=availability
component=wan
criticality=high

O valor de carrier deve ser canônico. Evite misturar “Claro”, “CLARO”, “Embratel”, “Claro Empresas” e siglas internas sem uma regra, porque cada variação vira uma dimensão diferente para filtros e serviços.

Circuito é ativo; operadora é dimensão; serviço é impacto

HOST
└── circuit-rj-centro-a01
    ├── carrier=operadora-a
    ├── circuit=CIR-A-001
    ├── site=rj-centro
    ├── service=internet
    └── role=wan-link

TRIGGER
└── WAN unavailable
    ├── scope=availability
    ├── component=wan
    └── severity=High

SERVICE
└── Operadora A
    └── filhos: circuitos / sites / serviços associados

Use dependência quando a relação causal é conhecida

O Zabbix não cria dependências diretamente entre hosts; a dependência é definida entre triggers. Enquanto a trigger raiz estiver em PROBLEM, triggers dependentes não são reavaliadas normalmente e suas ações/notificações podem ser suprimidas.

Router Core DOWN
      │
      ▼
Switch distribuição DOWN
      │
      ▼
OLT DOWN
      │
      ▼
Circuitos/serviços inacessíveis

Dependências podem formar uma cadeia de causa raiz

A checagem de dependências é recursiva. Isso permite modelar camadas como Router1 → Router2 → Host. Cuidado com o desenho: dependências circulares não são permitidas, e uma dependência errada pode suprimir eventos que deveriam aparecer ao operador.

Correlação de evento trata relacionamento e resolução

Event correlation pode existir no nível da trigger ou globalmente. Regras globais conseguem relacionar eventos usando tags, valores de tags e host groups. É especialmente útil quando um evento novo precisa fechar, relacionar ou substituir problemas anteriores segundo uma regra explícita.

Evento antigo:
carrier=operadora-a
circuit=CIR-A-001
state=down

Novo evento:
carrier=operadora-a
circuit=CIR-A-001
state=up

Regra:
mesmo carrier + mesmo circuit → resolver evento anterior correspondente

Suba do componente para o serviço

Services permitem construir uma árvore lógica de serviços. Um Service possui service tags, usadas para ações de serviço e SLA, e problem tags, usadas para associar problemas ao serviço. Esses dois tipos de tag têm funções diferentes e não devem ser confundidos.

INTERNET WAN
├── Operadora A
│   ├── CIR-A-001
│   ├── CIR-A-002
│   ├── ...
│   └── CIR-A-040
│
├── Operadora B
│   ├── CIR-B-001
│   └── ...
│
└── Operadora C
    ├── CIR-C-001
    └── ...

Uma das distinções mais importantes dessa arquitetura

Transforme N problemas em uma saúde agregada

Services permitem regras adicionais de status baseadas na situação dos filhos. Isso abre espaço para representar “falha parcial”, “degradação severa” e “falha massiva” usando quantidade ou percentual de serviços filhos afetados.

Operadora A — 40 circuitos

0–1 DOWN        → OK / impacto isolado
2–7 DOWN        → Warning
8–19 DOWN       → High
20+ DOWN        → Disaster / provável falha massiva

OU

>= 10% DOWN     → Warning
>= 25% DOWN     → High
>= 50% DOWN     → Disaster

Os limites acima são exemplos de engenharia operacional, não defaults do Zabbix. Eles precisam refletir quantidade de links, redundância, geografia e comportamento histórico de cada ambiente.

Percentual sozinho pode enganar

Uma regra robusta pode combinar mínimo absoluto e percentual: “pelo menos 3 circuitos e pelo menos 25% do total”.

Falha comum também é um problema de tempo

Se 20 circuitos caíram ao longo de cinco dias, provavelmente não temos o mesmo fenômeno de 20 circuitos que mudaram de estado em dois minutos. Por isso, limiares de massa devem considerar persistência e simultaneidade.

Exemplo de política:

>= 25% dos links DOWN
E
>= 3 links afetados
E
condição persiste por 2 minutos

→ abrir "Possível falha massiva - Operadora A"

Operadora inteira, região ou POP?

Uma falha concentrada em uma cidade não deveria necessariamente tornar toda a operadora “vermelha” nacionalmente. Modele a hierarquia de forma que o contexto geográfico possa emergir.

Operadora A
├── RJ
│   ├── Maricá
│   ├── Niterói
│   └── Rio de Janeiro
├── SP
└── MG

Link DOWN não é sempre serviço DOWN

Se um site possui dois links independentes, a queda de um circuito pode representar degradação de redundância, enquanto a queda dos dois representa indisponibilidade do serviço. Essa distinção deve aparecer na árvore de Services.

Internet — Site Centro
├── Link Operadora A
└── Link Operadora B

1 link DOWN  → redundância degradada
2 links DOWN → serviço indisponível

Crie métricas que expliquem a saúde da operadora

A primeira tela deve responder “onde está concentrado o impacto?”

┌──────────────────────┐  ┌──────────────────────┐
│ OPERADORA A          │  │ OPERADORA B          │
│ 11/40 UP             │  │ 30/30 UP             │
│ 29 DOWN              │  │ 0 DOWN               │
│ 27,5% disponível     │  │ 100% disponível      │
│ DISASTER             │  │ OK                   │
└──────────────────────┘  └──────────────────────┘

┌──────────────────────┐
│ OPERADORA C          │
│ 29/30 UP             │
│ 1 DOWN               │
│ 96,7% disponível     │
│ WARNING / ISOLADO    │
└──────────────────────┘

O problema raiz precisa ser legível fora do dashboard

DISASTER
Possível falha massiva — Operadora A — RJ

29/40 circuitos indisponíveis
72,5% do universo afetado
7 sites impactados
início: 14:32
persistência: 4 min

tags:
carrier=operadora-a
region=rj
scope=availability
event_class=mass-outage

Reduzir notificação não significa apagar visibilidade

Em uma falha massiva, o NOC pode receber uma notificação raiz e manter os problemas individuais disponíveis no Zabbix para investigação. A estratégia ideal é reduzir o ruído no canal de alerta, não destruir o detalhe técnico.

Saúde instantânea e disponibilidade histórica são problemas diferentes

Depois de criar Services, SLAs podem ser associados por service tags. O SLA define SLO, calendário esperado e downtimes excluídos. O relatório entrega SLI, isto é, a disponibilidade observada, que pode ser comparada ao objetivo.

SLO contratado: 99,90%
SLI observado: 99,72%

Resultado:
SLI < SLO → objetivo não atingido

Nem toda simultaneidade é falha da operadora

Uma falha robusta usa mais de um sinal quando possível

Sinais possíveis:
- ICMP
- interface operStatus
- BGP/BFD
- gateway remoto
- perda/latência
- HTTP externo
- SNMP do CPE/roteador
- estado físico da interface

Exemplo:
ICMP DOWN + BGP DOWN + interface física UP
→ indício forte de falha lógica/transporte externo

Sintoma → hipótese

Modelar três operadoras

Teste a lógica antes do incidente real

O que não fazer

Uma arquitetura em camadas

CAMADA 1 — COLETA
ICMP / SNMP / BGP / HTTP / Agent
        │
        ▼
CAMADA 2 — TRIGGERS
circuito down / loss / latência / interface
        │
        ├── tags: carrier / region / site / service
        ▼
CAMADA 3 — TOPOLOGIA
trigger dependencies para causas conhecidas
        │
        ▼
CAMADA 4 — SERVIÇO
Services por operadora / região / site
        │
        ▼
CAMADA 5 — AGREGAÇÃO
N filhos / N% filhos / severidade
        │
        ▼
CAMADA 6 — NOC
Dashboard + ação + mensagem raiz
        │
        ▼
CAMADA 7 — HISTÓRICO
SLA / SLO / SLI / análise de recorrência

Antes de ativar correlação massiva

Base factual

Conteúdo desenvolvido a partir da documentação oficial Zabbix 7.4 sobre trigger dependencies, event correlation, tagging, Services, Service tags, Problem tags e SLA. A taxonomia de operadoras, matriz de interpretação, limites de massa, arquitetura em camadas, laboratórios e recomendações operacionais são uma síntese editorial própria.

Linha Zabbix 7.4

A correlação deve preservar os eventos individuais e acrescentar contexto agregado. Use tags canônicas, dependencies, Services e regras de correlação para separar causa comum de coincidência temporal.