Passo a passo: da arquitetura à implementação prática
Em ambientes onde o monitoramento sustenta SLA, operações 24×7 e times de NOC e SOC, o Zabbix Server não pode ser um ponto único de falha.
Desde a versão 6.0, o Zabbix possui HA nativo para o Server, sem necessidade de cluster externo, sem scripts adicionais e sem soluções improvisadas.
Mas atenção: simples de configurar não significa simples de projetar corretamente.
Este guia percorre desde os fundamentos da arquitetura até a implementação prática da alta disponibilidade em ambiente de produção.
Entendendo a Arquitetura de alta disponibilidade (HA) do Zabbix
Modelo adotado: Active / Passive
O cluster HA do Zabbix funciona no modelo:
- 1 nó Active
- 1 ou mais nós Standby
- Todos compartilhando o mesmo banco de dados
Importante: apenas um nó processa métricas, triggers e eventos por vez.
Esse comportamento evita:
- Processamento duplicado
- Corrupção de dados
- Conflito de escrita no banco
Estados possíveis de um nó
Cada nó pode estar em um dos seguintes estados:
Active – Processa todos os dados, triggers e eventos
Standby – Monitora o nó ativo e aguarda possível promoção
Unavailable – Não está atualizando heartbeat
Stopped – Serviço parado
Esses estados são armazenados no banco de dados, na tabela “nodes”, e sincronizados periodicamente (heartbeat a cada 5 segundos).
Como o Failover realmente funciona
Heartbeat
Cada nó atualiza seu timestamp no banco de dados a cada 5 segundos.
Os nós standby monitoram continuamente o timestamp do nó ativo.
Failover delay
Se o nó ativo parar de atualizar seu heartbeat, o failover ocorre após:
failover_delay + 5 segundos
O valor padrão pode ser ajustado dinamicamente em runtime com o comando:
zabbix_server -R ha_set_failover_delay=1m
Intervalo permitido:
- Mínimo: 10 segundos
- Máximo: 15 minutos
Estratégia prática recomendada:
- Ambientes extremamente críticos: 30 segundos a 1 minuto
- Ambientes sujeitos a jitter ou instabilidade de rede: 2 a 3 minutos
Definir um delay muito agressivo pode gerar promoção indevida por flapping de rede.
Checklist completo de implementação
Pré-requisitos
- Banco de dados único e compartilhado entre todos os nós
- Baixa latência entre os servidores do cluster
- Sincronização de horário obrigatória (NTP configurado e validado)
- Mesma versão exata do Zabbix em todos os nós
Passo 1 – Configuração do banco de dados
Todos os nós devem apontar para o mesmo banco:
DBHost=db-server
DBName=zabbix
DBUser=zabbix
DBPassword=******
Atenção: alta disponibilidade (HA) do Zabbix não é alta disponibilidade (HA) de banco.
É obrigatório implementar alta disponibilidade no banco de dados com soluções como:
- PostgreSQL com streaming replication
- Patroni
- Percona XtraDB Cluster
- Ou solução equivalente
Sem alta disponibilidade (HA) no banco, o cluster inteiro se torna indisponível.
Passo 2 – Configuração de cada nó Zabbix Server
No arquivo zabbix_server.conf, configure os parâmetros de alta disponibilidade (HA).
Exemplo:
Nó 1
HANodeName=zbx-node-01
NodeAddress=10.0.0.11:10051
Nó 2
HANodeName=zbx-node-02
NodeAddress=10.0.0.12:10051
Regras fundamentais:
- HANodeName deve ser único em cada nó
- NodeAddress deve ser alcançável por proxies e frontend
- Todos os nós devem compartilhar o mesmo banco
Após configurar, reinicie os serviços:
systemctl restart zabbix-server
Passo 3 – Frontend
No arquivo zabbix.conf.php, não é necessário fixar manualmente o endereço do servidor ativo.
O frontend consulta automaticamente a tabela “nodes” no banco de dados e identifica qual nó está em estado active.
Essa lógica elimina a necessidade de VIP específico para o frontend.
Configuração de Proxies e Agents em ambiente de Alta Disponibilidade (HA)
Proxies
Proxy Passivo
No arquivo de configuração:
Server=10.0.0.11,10.0.0.12
Proxy Ativo
No arquivo de configuração:
Server=10.0.0.11;10.0.0.12
Importante:
Vírgula é usada para conexões passivas.
Ponto e vírgula é usado para conexões ativas.
Confundir isso compromete o failover.
Agents
Agent Passivo:
Server=10.0.0.11,10.0.0.12
Agent Ativo:
ServerActive=10.0.0.11;10.0.0.12
Boa prática recomendada: utilizar DNS interno ou VIP em vez de IP fixo, sempre que possível.
Comandos operacionais do cluster
Monitorar status do cluster:
zabbix_server -R ha_status
Remover nó do cluster:
zabbix_server -R ha_remove_node=zbx-node-02
Alterar failover delay:
zabbix_server -R ha_set_failover_delay=2m
Esses comandos são executados em runtime e não exigem reinicialização do serviço.
Dicas e boas práticas
Teste o failover em ambiente de testes
Simule falha abrupta com:
kill -9 <pid>
ou desligando a máquina virtual.
Observe:
- O standby assume após o tempo definido em failover_delay
- Logs registram a promoção do novo nó ativo
- Proxies e agents reconectam automaticamente
Nunca implante alta disponibilidade (HA) em produção sem validar failover real.
Sincronização de horário
Se o NTP falhar, o cluster pode apresentar comportamento imprevisível, inclusive promoções indevidas.
Não misture versões
Executar versões diferentes do Zabbix dentro do mesmo cluster pode causar comportamento indefinido e inconsistências no banco.
Armadilhas comuns
- Banco de dados sem alta disponibilidade (HA): todo o cluster cai
- Failover delay muito baixo: promoção desnecessária por jitter
- Latência alta entre nós: pode gerar estado unavailable falso
- Frontend fixado manualmente a um único IP de servidor: quebra a lógica dinâmica
Conclusão
A alta disponibilidade (HA) nativo do Zabbix é:
- Simples
- Elegante
- Eficiente
- Seguro
Ele elimina o ponto único de falha do Server de maneira limpa, sem transformar sua arquitetura em um conjunto complexo de clusters difíceis de manter.
Monitoramento é a base da operação. Se ele falhar, você perde visibilidade exatamente quando mais precisa.
Implementar alta disponibilidade (HA) corretamente não é luxo, é requisito estratégico para qualquer ambiente que dependa de disponibilidade real.
Sobre a Target Solutions
A Target Solutions é especializada em AIOps, infraestrutura de TI e redes, atuando na interseção entre operação real, automação e inteligência aplicada. Com mais de 15 anos de experiência técnica, combinamos inovação em tecnologias de código aberto com inteligência artificial aplicada às operações de TI e Telecom, transformando ambientes complexos em operações mais eficientes, previsíveis e escaláveis.
Como Zabbix Certified Partner, contamos com profissionais certificados (Expert, Professional e Specialist), com ampla experiência na implantação, evolução, sustentação N2/N3 e otimização de ambientes Zabbix corporativos de grande porte. Nossa atuação abrange desde arquiteturas distribuídas com proxies regionais até ambientes com milhares de ativos monitorados, incluindo integrações com sistemas ITSM e ferramentas de observabilidade.
Ao longo de dezenas de projetos de implantação, modernização e suporte especializado em Zabbix, acumulamos não apenas domínio técnico da plataforma, mas também uma compreensão profunda dos desafios reais da gestão de incidentes: excesso de alarmes, dificuldade de priorização, análise manual e operações reativas.
É justamente nesse ponto que a proposta de valor do Argus, nossa plataforma de AIOps, se conecta de forma complementar ao Zabbix. Enquanto o Zabbix oferece monitoramento robusto e confiável, o Argus atua sobre esse universo de eventos, consolidando múltiplas fontes, correlacionando alarmes e aplicando inteligência para transformar dados em contexto, prioridade e ação.
Assim, ajudamos as organizações a evoluírem da simples monitoração para uma gestão operacional orientada à inteligência, reduzindo ruído, acelerando diagnósticos e elevando o nível de maturidade das operações de TI.
Conheça o Argus (clique aqui), solicite uma demonstração e veja como transformar ruído em inteligência operacional.
Autor deste Artigo: Luciano Souza, Consultor Associado da Target Solutions.
