Em provedor, SNMP é o que sustenta o monitoramento: OLT, switch de agregação, rádio, concentrador — quase tudo é coletado por ele. E conforme a rede cresce, o gargalo aparece do mesmo jeito: poller ocupado, fila de itens atrasados, coleta que "às vezes falha" em equipamento que está perfeitamente de pé. O Zabbix 8.0 traz três mudanças que mexem justamente nesse ponto — menos chamativas que ClickHouse ou CEP, mas que qualquer um que coleta SNMP em escala vai sentir.
1. Cache do engineID no SNMPv3
No SNMPv3, antes de consultar um equipamento, o cliente precisa descobrir o engineID dele — uma troca extra de pacotes. Até aqui, essa descoberta se repetia com frequência, o que dobra o número de idas e voltas em redes com muitos hosts SNMPv3.
No 8.0, o Zabbix guarda a associação engineID → IP em cache e reaproveita nas verificações seguintes. Se o engineID reaproveitado não responder (troca de equipamento, reset de configuração), o poller volta a sondar e descarta a entrada velha.
Na prática:
- Menos tráfego de gerência — relevante em link de gerência estreito até POP remoto.
- Menos trabalho por verificação no poller.
- Menos motivo pra ficar no SNMPv2c por desempenho. SNMPv3 é o recomendado por segurança (autenticação e criptografia), e o custo de performance que servia de desculpa diminui.
Um cuidado: equipamentos clonados ou com engineID duplicado (acontece com imagem de configuração copiada entre dispositivos) já davam problema no SNMPv3 — com cache, vale conferir se isso existe na sua rede antes de migrar.
2. Verificações SNMP de discovery em paralelo
As verificações assíncronas de serviço SNMPv1 e v2c usadas no network discovery passam a ser processadas concorrentemente pelos discovery workers. Pra quem usa discovery pra achar equipamento novo em faixas de IP de gerência (ou pra varrer PON, rádio e CPE gerenciável), significa varredura mais rápida sem precisar aumentar desproporcionalmente o número de workers.
3. DNS com cache e failover (c-ares)
Servidor, proxy e agent podem usar o resolvedor c-ares pra todas as consultas DNS, com cache de resposta e failover entre resolvedores quando o Zabbix é compilado com esse suporte. Parece detalhe, mas quem monitora host por nome já viu o cenário: o DNS interno oscila, e de repente uma leva de itens fica "não suportado" por falha de resolução — alarme falso em massa por causa de uma dependência que nem é monitorada direito.
Como se preparar
- Levante quantos hosts ainda estão em SNMPv1/v2c e se o motivo é desempenho — com o cache, reavaliar a migração pra v3 faz sentido.
- Verifique engineIDs duplicados antes da troca de versão.
- Meça o poller hoje (utilização dos processos SNMP, fila de itens atrasados) pra ter com o que comparar depois do upgrade.
- Confira se seu pacote/compilação traz c-ares antes de contar com o cache de DNS.
Coleta SNMP mais leve é o tipo de ganho que não aparece em slide de lançamento, mas aparece na conta do servidor — e na confiança de que o alarme que chegou é real. Se quiser ver como isso vira mapa e alarme útil pro seu NOC, veja como o NOC Geomap funciona.
Fontes: Zabbix — What's new in Zabbix 8.0 e Zabbix — ZBXNEXT-2352: Cache and reuse EngineID to improve SNMPv3 checks.