A arquitetura clássica de Zabbix em provedor é simples: um server central e um proxy em cada POP grande, coletando OLTs, switches e rádios da região. Funciona — até o dia em que o proxy de um POP trava, o disco enche ou a VM reinicia sem voltar. Aí a região inteira some do monitoramento, e o NOC só descobre porque "está tudo quieto demais".
O que os grupos de proxy resolvem
O Zabbix 7.0 introduziu grupos de proxy: em vez de amarrar cada host a um proxy específico, você amarra o host a um grupo, e o próprio Zabbix:
- Distribui os hosts entre os proxies do grupo.
- Rebalanceia a carga quando um proxy entra ou sai.
- Faz failover: se um proxy fica fora por mais tempo que o período configurado, os hosts dele são redistribuídos pros outros proxies online do grupo.
Pra provedor, o desenho natural é ter dois proxies por região (ou por POP crítico) no mesmo grupo. Um cai, o outro assume — sem intervenção manual, sem reconfigurar host.
Um cuidado importante: todos os proxies do grupo precisam alcançar todos os hosts do grupo (rota, ACL, credencial SNMP). Proxy em POP A que não enxerga OLT do POP B não pode estar no mesmo grupo dela.
Buffer: o proxy que aguenta link ruim
Outro recurso do 7.0 que casa com POP remoto é o buffer em memória do proxy. Em vez de gravar tudo no banco local antes de enviar, o proxy pode guardar os dados em memória e só cair pro disco quando necessário (modo hybrid, recomendado pra instalações novas). Parâmetros: ProxyBufferMode, ProxyMemoryBufferSize e ProxyMemoryBufferAge. Resultado: menos I/O no proxy — bom pra VM modesta em POP — e o link com o server pode oscilar sem perder dado.
O que o 8.0 acrescenta: permissão por proxy
A RC1 do Zabbix 8.0 trouxe um modelo de visibilidade por permissão para proxies e grupos de proxy, no mesmo estilo do controle por grupo de host. Na prática, abre caminho pra cenários que antes eram desconfortáveis:
- Equipe regional que administra só os proxies da sua região.
- Provedor que presta monitoramento pra cliente corporativo ou pra outro provedor menor (modelo MSP), sem expor a infraestrutura de coleta inteira.
Checklist de arquitetura
- Pelo menos dois proxies por região crítica, no mesmo grupo.
- Confirmar que cada proxy alcança todos os hosts do grupo.
- Monitorar o próprio proxy (fila, última comunicação, uso de buffer) — proxy parado é um alarme que precisa existir.
- Modo de buffer hybrid nos proxies novos.
- Planejar as permissões por proxy pro upgrade do 8.0.
Se quiser enxergar no mapa quais regiões dependem de qual proxy, fale com a gente.
Fontes: Zabbix — What's new in Zabbix 7.0.0, Zabbix — Proxy load balancing and high availability e Zabbix — Release Notes for Zabbix 8.0.0rc1.