Uma das mudanças que as análises de mercado de observabilidade de rede de 2026 mais repetem é a troca de regras rígidas definidas à mão por detecção automática de anomalia, pra reduzir ruído. Parece assunto de plataforma cara com "IA" no nome. Mas boa parte do ganho está numa ideia simples, que o Zabbix já implementa: comparar o valor de agora com o que é normal pra este horário, e não com um número fixo.
O problema do limiar fixo em provedor
Tráfego de provedor tem formato conhecido: cai de madrugada, sobe de manhã, explode entre 20h e 23h, muda no fim de semana. Um limiar fixo no uplink de um POP — digamos, alarme abaixo de 1 Gbps — falha dos dois lados:
- De madrugada, o tráfego normal fica abaixo do limiar e o alarme dispara sem motivo — ou você o desliga e perde a cobertura.
- No horário de pico, o tráfego pode cair 40% por um problema real (um upstream com perda, um transporte degradado, uma OLT inteira fora) e ainda ficar acima de 1 Gbps. Ninguém é avisado.
O mesmo vale pra quantidade de ONUs online, sessões PPPoE ativas, consultas DNS por segundo: tudo tem ciclo. O que importa é o desvio do ciclo.
As funções que o Zabbix já tem
Desde a série 6.0, o Zabbix traz funções de tendência que trabalham com sazonalidade. As três mais úteis aqui:
baselinewma— calcula o "normal" pra este horário com média móvel ponderada das mesmas janelas nos ciclos anteriores. Exemplo:baselinewma(/POP-Centro/ifInOctets[uplink],1h:now/h,"d",3)é a média da última hora completa no mesmo horário dos três dias anteriores.baselinedev— diz quantos desvios padrão a última janela está distante das mesmas janelas nos ciclos anteriores.baselinedev(/host/key,1h:now/h,"d",10)compara a última hora com a mesma hora dos dez dias anteriores.trendstl— decompõe a série (tendência, sazonalidade e resíduo) e devolve a taxa de anomalia num período, de 0 a 1. Por padrão, considera anômalo o ponto a mais de 3 desvios absolutos medianos (MAD) do esperado.
Na prática, a trigger fica algo como "a última hora está mais de 3 desvios abaixo do normal pra esse horário" — que pega o pico com tráfego 40% menor e ignora a madrugada tranquila.
Onde usar (e onde não usar)
Essas funções leem os dados de tendência, agregados por hora. Por isso:
- Servem pra desvio que dura uma hora ou mais: queda gradual de clientes ativos numa região, tráfego de pico consistentemente abaixo do esperado, crescimento anormal de consultas DNS, uplink que passou a carregar tráfego que não é dele.
- Não substituem o alarme imediato. ONU caindo em massa, porta down, sessão BGP fora: continuam com trigger convencional, em tempo real.
Algumas boas práticas pra começar sem gerar ruído novo:
- Comece por poucos itens que já têm ciclo claro: tráfego dos uplinks de POP, total de ONUs online por OLT, sessões no concentrador.
- Use pelo menos uma ou duas semanas de histórico antes de confiar no baseline. Feriado e semana atípica distorcem.
- Prefira severidade de aviso no início e acompanhe quantas vezes a trigger acerta antes de promover a alarme de plantão.
- Combine com uma condição mínima (
andcom volume absoluto) pra não alarmar desvio estatístico em POP com tráfego ínfimo.
O ganho real
O valor não está em "ter IA" — está em ter menos alarmes que todo mundo ignora e mais alarmes que ninguém tinha: o problema que derruba metade do tráfego de um POP sem derrubar nenhum equipamento. Se quiser ver como esse tipo de desvio aparece por região no mapa do NOC, dá uma olhada em como funciona o NOC Geomap.
Fontes: Zabbix — documentação de funções de tendência; Broadcom — GigaOm Radar reveals key market shifts.