Arquitetura

O Zabbix é formado por componentes que exercem funções diferentes. Em uma instalação simples, vários deles podem estar no mesmo servidor. Em ambientes distribuídos, as funções podem ser separadas para melhorar a organização, a capacidade de coleta e a operação.

O Zabbix Server concentra a lógica central da plataforma. Ele recebe e processa dados, avalia condições de monitoramento, participa da geração de eventos e mantém a comunicação com o banco de dados.

O Proxy permite distribuir a coleta em uma arquitetura centralizada. Ele pode ficar próximo dos equipamentos monitorados e encaminhar os dados ao Zabbix Server, sendo útil em ambientes com filiais, unidades ou múltiplos PoPs.

O Zabbix Agent é utilizado quando a coleta precisa acontecer diretamente no host. Ele é especialmente útil em servidores Linux e Windows para obter métricas do sistema operacional e de seus recursos.

O frontend é a interface usada para administrar o ambiente, cadastrar hosts, associar templates, consultar problemas e histórico, acompanhar dashboards e revisar a configuração do monitoramento.

O banco de dados é um componente crítico porque guarda informações de configuração e os dados necessários para histórico e tendências. O dimensionamento deve acompanhar o volume de coleta e a retenção adotada.

Configuração, coleta e persistência percorrem caminhos diferentes

FRONTEND
   │ configuração
   ▼
DATABASE
   ▲
   │ configuração / history / events
   ▼
ZABBIX SERVER
   │
   ├──► AGENT / SNMP / HTTP / JMX / IPMI
   │
   ├──► PROXY ──► dispositivos remotos
   │
   └──► ACTIONS / MEDIA / WEBHOOKS

O Server é o processo central;
o banco é a persistência;
o frontend é a interface;
o Proxy distribui coleta;
o Agent expõe dados do host.

Nem toda telemetria é coletada do mesmo modo

O Zabbix suporta polling e trapping. Checks passivos são iniciados pelo Server/Proxy; active Agent checks são iniciados pelo agente; trapper/sender envia valores ao Zabbix; SNMP traps chegam de forma assíncrona. Misturar modelos sem entender quem inicia a conexão costuma gerar erros de firewall e diagnóstico.

O Server é uma coleção de workers especializados

Pollers, preprocessors, history syncers, trappers, discoverers, alerters e outros processos executam estágios diferentes. Em performance, a pergunta correta não é apenas “CPU do Server está alta?”, mas “qual estágio está ocupado e por quê?”.

HA do Server não elimina todos os pontos únicos de falha

O Zabbix possui HA nativo do Server com um nó ativo e nós standby, mas todos dependem do banco compartilhado. Banco, frontend, DNS, storage e canais de alerta precisam de estratégias próprias quando a disponibilidade da plataforma é crítica.

Cada seta do diagrama é uma relação de confiança

Distribuição só é útil quando reduz blast radius

Colocar Server, banco e frontend na mesma VM simplifica laboratório, mas concentra falha. Em produção, separe componentes conforme RPO/RTO e criticidade. Proxies ajudam a manter coleta regional durante falhas de WAN e reduzem dependência de conectividade constante.

Base factual

Conteúdo revisado com base na documentação oficial Zabbix 7.4 sobre Zabbix overview, Server, Agent, Agent 2, Proxy, Server HA, fluxo de dados e instalação. Os diagramas, failure domains, fronteiras de confiança e recomendações de desenho são síntese editorial própria.

Linha Zabbix 7.4

A arquitetura atual deve considerar Server HA, proxy groups, frontend separado quando necessário e o banco como persistência crítica independente do HA nativo do Server.