Proxy e monitoramento distribuído

Proxy aproxima a coleta do alvo e mantém o controle no Server

O Proxy coleta métricas, discovery e autoregistration em nome do Zabbix Server e encaminha esses dados posteriormente. A configuração continua centralizada no Server; o Proxy não possui frontend administrativo próprio e não gera notificações. Isso permite distribuir a coleta sem fragmentar a governança do ambiente.

Localidade, conectividade e escala são os principais motivos

Proxies são especialmente úteis em filiais, POPs, redes remotas, ambientes com latência elevada, segmentos protegidos por firewall e cenários em que o Server não deve abrir conexão diretamente para centenas de alvos. Eles também podem reduzir trabalho de coleta no Server quando grande parte dos checks é executada remotamente.

Proxy não é remédio universal para Zabbix lento

Adicionar Proxy não corrige automaticamente banco saturado, retention excessiva, itens mal desenhados, preprocessing congestionado ou intervalos agressivos. Antes de distribuir coleta, identifique qual componente está limitando o ambiente. Proxy resolve problemas de coleta distribuída; não substitui engenharia de performance.

Cada Proxy precisa de sua própria persistência

O Zabbix Proxy requer banco separado. SQLite, MySQL e PostgreSQL são suportados. SQLite é simples e pode ser suficiente para pequenos proxies; ambientes maiores ou com grande buffer/volume tendem a justificar banco dedicado mais robusto. O Proxy nunca deve compartilhar o banco do Zabbix Server.

O Proxy inicia a comunicação

No modo ativo, o Proxy conecta-se ao Server para buscar configuração e enviar dados. Esse modelo costuma ser conveniente em redes remotas porque a conexão parte do local monitorado para a central, reduzindo necessidade de conexões iniciadas pelo Server através de firewalls.

O Server inicia a comunicação

No modo passivo, o Server conecta-se ao Proxy. Isso pode ser útil em redes onde a central possui rota e política explícita para atingir o Proxy. O desenho deve considerar NAT, firewall, DNS, latência e política de segurança antes de escolher o modo.

Active versus Passive não define sozinho o nível de segurança

O modo de conexão e o método de proteção são decisões diferentes. Zabbix suporta conexões sem criptografia, PSK ou certificados em cenários apropriados. Para Proxy ativo, a documentação alerta que dados sensíveis de configuração podem ser expostos se alguém puder se passar por Proxy e solicitar configuração sem controles adequados. Use criptografia e restrições de endereço conforme o risco.

Restrinja quem pode se apresentar como Proxy ativo

No frontend, Active Proxy pode ter Proxy address definido para restringir endereços IP/CIDR ou nomes DNS aceitos. Essa camada complementa autenticação/criptografia e reduz superfície de ataque. Em ambientes críticos, não trate o nome do Proxy como mecanismo de identidade suficiente.

Desconexão da central não precisa interromper a coleta local

O Proxy mantém os dados coletados localmente e os envia ao Server quando a comunicação retorna. Isso é uma das principais vantagens em links remotos instáveis: o monitoramento preserva continuidade histórica mesmo durante perda temporária da conexão entre Proxy e Server, dentro dos limites de retenção configurados.

Defina quanto tempo de desconexão o Proxy deve suportar

ProxyOfflineBuffer determina por quantas horas dados devem ser mantidos quando não há conectividade com o Server. O default é 1 hora e o intervalo suportado chega a centenas de horas. O valor deve refletir pior cenário de indisponibilidade, volume de coleta e capacidade de armazenamento.

Dados também podem permanecer localmente após sincronização

ProxyLocalBuffer mantém dados por um período mesmo depois de enviados ao Server. Isso pode servir a necessidades específicas, porém aumenta uso de armazenamento. Não confunda buffer offline com retenção local pós-envio: são problemas diferentes.

Zabbix 7.4 oferece modos disk, memory e hybrid

ProxyBufferMode define como history, discovery e autoregistration são armazenados. Disk utiliza o banco; memory usa memória compartilhada e perde dados no shutdown; hybrid normalmente usa memória e migra para o banco quando o limite/idade é atingido, retornando depois ao modo de memória. A escolha altera I/O, risco de perda e comportamento de recuperação.

Hybrid reduz I/O sem abandonar a proteção do banco

Em modo hybrid, o buffer opera em memória enquanto houver capacidade e os registros forem recentes. Quando memória se esgota ou o dado mais antigo supera o limite, os registros são descarregados para o banco até normalização. Esse comportamento pode reduzir I/O constante mantendo uma rota para persistência quando a memória deixa de ser suficiente.

Velocidade maior vem com uma troca explícita

Em memory mode, dados ficam em memória e registros antigos podem ser descartados se o buffer encher. O conteúdo também é descartado no shutdown. É uma escolha válida apenas quando essa perda potencial é aceitável e o desenho da operação está consciente da troca entre I/O e durabilidade.

Active Proxy busca configuração; Passive recebe do Server

Active Proxy consulta periodicamente o Server conforme ProxyConfigFrequency. No modo passivo, esse parâmetro não se aplica da mesma forma porque o Server conduz o fluxo. Entender esse comportamento ajuda a diagnosticar atrasos entre alteração no frontend e efetivação no Proxy.

Envio ao Server também possui cadência própria

O Proxy possui parâmetros de envio dos dados coletados ao Server. Em ambientes com enlaces restritos, frequência, backlog e volume precisam ser considerados em conjunto. Reduzir chamadas não elimina bytes; pode apenas concentrar tráfego em lotes maiores.

Proxy possui pollers, preprocessing e caches próprios

O Proxy não é apenas um relay. Ele executa coleta e parte do processamento local. SNMP pollers, agent pollers, HTTP agent pollers, preprocessing manager/workers, caches e history syncers podem se tornar gargalos. Dimensionar somente CPU total sem observar processos internos pode esconder saturações específicas.

Proxy é particularmente valioso próximo de grandes domínios SNMP

Em sites com muitos switches, roteadores, OLTs e sensores, colocar o Proxy próximo aos dispositivos reduz latência de consultas e atravessamentos WAN. Bulk/walk, discovery e dependent items continuam importantes para reduzir o volume de requests; Proxy não justifica coleta ineficiente.

Relógio inconsistente destrói interpretação temporal

Server, Proxy e hosts precisam de sincronização confiável de tempo. Diferenças de relógio dificultam correlação, duração de eventos e ordenação de dados. NTP/chrony é parte da infraestrutura de monitoramento, não detalhe cosmético.

Proxy não conhece períodos de maintenance

A documentação oficial ressalta que o Proxy não está ciente dos períodos de manutenção. Isso possui implicações para cálculo de filas e diagnóstico. Ao analisar queue durante maintenance, considere que a percepção do Proxy e do Server sobre atrasos pode não corresponder ao que o operador espera intuitivamente.

Distribuição automática e alta disponibilidade

Proxy groups agrupam proxies para load balancing e high availability. Hosts configurados para serem monitorados pelo grupo podem ser redistribuídos automaticamente. Se um Proxy fica offline, seus hosts podem migrar para outros proxies elegíveis; se há desequilíbrio de hosts, o Server também pode redistribuí-los.

HA só funciona quando versões e estado permitem

Para redistribuição dentro de proxy group, proxies precisam atender aos requisitos de versão e compatibilidade com o Server, e o grupo precisa estar online. Hosts também precisam estar associados ao proxy group, não fixados a um Proxy individual. Isso deve ser validado antes de assumir que failover acontecerá.

Disponibilidade do grupo possui um limiar operacional

Proxy group possui configuração de quantidade mínima de proxies online. O estado do grupo pode ser Unknown, Online, Degrading ou Offline conforme comunicação dos proxies e o limiar definido. Um grupo com poucos proxies disponíveis pode continuar funcional, mas já sinalizar degradação antes de perder capacidade de redistribuição.

Failover precisa equilibrar sensibilidade e estabilidade

O período de failover define quanto tempo o sistema espera antes de considerar Proxy indisponível para fins do grupo. Curto demais pode causar redistribuição por oscilações momentâneas; longo demais aumenta janela de coleta afetada. A escolha deve considerar estabilidade da rede, criticidade e tempo de recuperação desejado.

Balancear quantidade de hosts não significa balancear trabalho perfeitamente

Redistribuição automática considera hosts, mas dois hosts podem ter cargas completamente diferentes: um roteador com milhares de itens e uma VM com dezenas de itens não custam o mesmo. Observe performance real por Proxy e não presuma equilíbrio apenas porque a contagem de hosts é semelhante.

Failover de Proxy muda onde o host é coletado

Quando hosts pertencem a proxy group, o Server pode atribuí-los dinamicamente a proxies disponíveis. Isso exige que todos os proxies elegíveis tenham conectividade, credenciais indiretas e alcance de rede suficiente para coletar aqueles hosts. HA lógica sem conectividade física comum não funciona.

Proxy group não deve ignorar topologia de rede

Não agrupe proxies apenas porque são tecnicamente equivalentes. Se Proxy de São Paulo não tem rota para equipamentos do Rio, ele não pode assumir os hosts do Rio durante failover. Grupos precisam refletir domínio real de alcance e segurança.

O Proxy pode reduzir conexões através do backbone

Em vez de centenas de dispositivos conversando com a central, cada site pode concentrar a coleta num Proxy e manter um conjunto menor de fluxos entre site e Server. Isso simplifica firewall, reduz round trips de protocolos sensíveis à latência e organiza responsabilidade por região.

Administração permanece centralizada

Proxies são cadastrados em Administration → Proxies e proxy groups em Administration → Proxy groups. Hosts podem ser atribuídos a Proxy ou proxy group conforme o modelo. A equipe não precisa administrar inventário e templates localmente em cada site.

O coletor também precisa ser um alvo

CPU, memória, armazenamento, banco local, backlog, disponibilidade até o Server, queue, processos ocupados e volume de coleta devem ser monitorados. Se o Proxy falha silenciosamente, dezenas ou centenas de hosts podem parecer indisponíveis ou simplesmente parar de atualizar.

Ferramentas de runtime ajudam no diagnóstico

O Proxy possui runtime controls como config_cache_reload, diaginfo, history_cache_clear e snmp_cache_reload. Eles permitem recarregar cache, coletar diagnóstico e limpar estado SNMP sem reiniciar indiscriminadamente o daemon. Em troubleshooting de produção, isso reduz impacto.

Colete evidência antes de aumentar processos

diaginfo pode gerar estatísticas sobre history cache, preprocessing e locks no log do Proxy. Antes de aumentar pollers ou caches, obtenha evidência do gargalo. Tunings arbitrários podem desperdiçar memória e apenas deslocar o problema.

SNMPv3 possui estado que pode precisar ser limpo

snmp_cache_reload limpa propriedades do cache SNMP, como engine time, boots, engine ID e credenciais. Isso pode ajudar em troubleshooting após mudanças de SNMPv3 ou substituição de equipamento, sem exigir restart completo do Proxy.

SQLite é simples; simplicidade não significa capacidade infinita

SQLite reduz administração e cria o banco automaticamente, tornando-o conveniente para pequenos proxies. Em ambientes com alto NVPS, buffer grande ou muitos checks, avalie MySQL/PostgreSQL e armazenamento adequado. O banco do Proxy também precisa de I/O previsível durante backlog e replay.

Quando o link volta, o backlog precisa caber no caminho

Após horas offline, o Proxy pode precisar enviar um grande backlog enquanto continua coletando valores novos. Dimensione CPU, banco e link para a recuperação, não apenas para estado normal. Um enlace que suporta 20 kbit/s em steady state pode sofrer quando precisa transmitir horas de histórico rapidamente.

Dimensione pelo volume, não pelo número de hosts

Para estimar um Proxy, considere values per second, tipos de check, latência, SNMP tables, preprocessing, payloads HTTP, LLD e duração máxima de buffer offline. Contagem de hosts é apenas uma aproximação grosseira.

Distribuição deve reduzir domínio de falha

Um único Proxy para todos os POPs apenas desloca o ponto único de falha. Dividir coleta por domínios independentes reduz blast radius. Proxy groups podem acrescentar HA dentro de um domínio onde múltiplos proxies realmente conseguem alcançar os mesmos alvos.

Proxy distribuído não significa Zabbix fragmentado

Templates, hosts, triggers, Services, dashboards, Actions e histórico final continuam sob governança central. O objetivo é distribuir execução da coleta, não criar ilhas administrativas. Essa distinção preserva consistência e permite automação global.

Server central, coleta próxima do alvo

                         ZABBIX SERVER
                              │
           ┌──────────────────┼──────────────────┐
           │                  │                  │
           ▼                  ▼                  ▼
      PROXY / RJ         PROXY / SP         PROXY / MG
           │                  │                  │
     ┌─────┼─────┐      ┌─────┼─────┐      ┌─────┼─────┐
     │     │     │      │     │     │      │     │     │
    OLT   RTR    SW     OLT   RTR    SW     OLT   RTR    SW

Configuração:
Server → Proxy

Coleta:
Proxy → dispositivos locais

Dados:
Proxy → buffer local → Server

Tabela de decisão

Disk, memory ou hybrid?

Parâmetros que merecem atenção

# Exemplo conceitual — revise conforme seu ambiente

Hostname=proxy-rj-pop01
Server=zabbix-central.exemplo.local

# 0 = active / 1 = passive
ProxyMode=0

# banco do Proxy
DBName=zabbix_proxy

# retenção durante perda do Server
ProxyOfflineBuffer=24

# opção atual de buffer
ProxyBufferMode=hybrid

# memória para buffer, se aplicável
ProxyMemoryBufferSize=256M

# idade máxima antes de migrar para disk em hybrid
ProxyMemoryBufferAge=300

Quanto dado um site acumula durante isolamento?

Exemplo conceitual:

20.000 valores/segundo
× 3.600 segundos
= 72.000.000 valores por hora

offline por 4 horas:
≈ 288.000.000 valores

Isso NÃO é tamanho direto em bytes do banco.
Serve para mostrar a ordem de grandeza que buffer,
I/O e posterior sincronização terão de suportar.

Dois proxies, um domínio de coleta

PROXY GROUP: RJ-ACCESS

       ┌───────────────┐
       │ ZABBIX SERVER │
       └───────┬───────┘
               │
      ┌────────┴────────┐
      │                 │
      ▼                 ▼
 PROXY-RJ-01       PROXY-RJ-02
      │                 │
      └────────┬────────┘
               │
       hosts do proxy group

Se PROXY-RJ-01 falha:
→ hosts elegíveis podem migrar para PROXY-RJ-02

Requisito real:
PROXY-RJ-02 precisa alcançar os mesmos hosts.

Agrupe por alcance real, não só por proximidade administrativa

O que realmente pesa no Proxy

O Proxy deve declarar quando está ficando cego

Host parou de atualizar: siga o caminho

Diagnóstico sem reinício desnecessário

# Exemplos de runtime control
zabbix_proxy -R config_cache_reload

zabbix_proxy -R diaginfo
zabbix_proxy -R diaginfo=historycache
zabbix_proxy -R diaginfo=preprocessing

zabbix_proxy -R snmp_cache_reload

Erros comuns em monitoramento distribuído

Implantar Proxy em um POP remoto

Testar proxy group antes de chamar de alta disponibilidade

Qual arquitetura escolher?

Antes de mover hosts para Proxy

Base factual

Conteúdo desenvolvido a partir da documentação oficial Zabbix 7.4 sobre Proxy, distributed monitoring, configuração do zabbix_proxy, active/passive mode, ProxyOfflineBuffer, ProxyLocalBuffer, ProxyBufferMode, memory/hybrid buffer, runtime control, Proxy Groups, load balancing e proxy high availability. Os modelos de capacity, arquitetura geográfica, fault domains, laboratórios, matrizes de decisão e recomendações operacionais são síntese editorial própria.

Linha Zabbix 7.4

Proxy groups fornecem redistribuição automática, balanceamento e alta disponibilidade entre proxies compatíveis. Cada Proxy deve usar banco próprio e nunca compartilhar o banco do Server.