Entendendo as portas do Zabbix na prática
O Zabbix usa duas portas padrões no seu funcionamento básico. O servidor e os proxies rodam na porta 10050/tcp, enquanto os agentes instalados nos hosts monitorados escutam na 10051/tcp. Parece simples, mas é onde muita gente trava quando vai configurar Monitoramento Zabbix pela primeira vez em produção. A comunicação segue um modelo em que o agente faz o papel passivo: ele fica esperando o servidor chamar. O servidor inicia a conexão de 10050 para 10051. Isso significa que, se você tiver um firewall entre eles, precisa liberar o tráfego nesse sentido, e não o contrário. Muitos configuram a regra invertida e passam horas debugando o porquê do agente não responde.
Qual é a porta padrão do zabbix?
A porta padrão do zabbix para o serviço do servidor e proxy é a 10050/tcp, e a do agente é a 10051/tcp. Ambas são fixas por padrão na instalação, mas podem ser alteradas nos arquivos de configuração sem drama. No agente, fica em zabbix_agentd.conf com a diretiva ListenPort. No servidor, a configuração é feita em zabbix_server.conf com a opção StartAgents, que define quantos processos filhos serão criados para atender nas portas configuradas. Tem uma coisa que poucos documentam bem: a porta 10051 não é obrigatória. Se você usar o método de ativação do agente (Active Agent), o agente se conecta ao servidor de forma ativa e não precisa ter a porta 10051 aberta no host monitorado. Nesse cenário, a única porta que importa é a 10050 do servidor. Eu passei por isso num cliente onde a política de segurança da empresa proibia qualquer porta nova de entrada em servidores de produção. Configurei todos os itens como ativos, liberei apenas o egresso dos agentes para a porta 10050 do Zabbix, e eliminei a necessidade de abrir a 10051 em quase trinta hosts.
Outro ponto que causa confusão é a diferença entre o que a documentação chama de "porta padrão" e o que realmente roda. Quando se instala o Zabbix pelo pacote oficial da distribuição, como no Ubuntu ou CentOS, o serviço já vem configurado para usar essas portas. Mas se você estiver usando uma instalação customizada, ou um container, pode encontrar o Zabbix rodando em portas diferentes. Sempre confira com o comando netstat -tlnp ou ss -tlnp para ver o que está realmente escutando antes de abrir regras de firewall.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Configuração prática e problemas comuns
Para alterar a porta do agente, edite o arquivo de configuração localizado geralmente em /etc/zabbix/zabbix_agentd.conf e ajuste a linha ListenPort. Para o servidor, use o arquivo /etc/zabbix/zabbix_server.conf. Após mudar, reinicie o serviço com systemctl restart zabbix-agent ou zabbix-server, dependendo do caso. Nada complicado, mas é fácil esquecer de reiniciar e ficar achando que a mudança não funcionou. O Item Zabbix Agent só funciona se o agente estiver respondendo na porta configurada. Se você mudar a porta e não atualizar o hostname ou a interface no frontend do Zabbix, os checks vão falhar silenciosamente. O log do agente em /var/log/zabbix/zabbix_agentd.log mostra os acessos rejeitados se o servidor tentar conectar na porta errada. Já o log do servidor em /var/log/zabbix/zabbix_server.log registra quando o agente não responde ou quando a conexão é recusada.
Um problema real que encontrei foi com um agente que parecia funcionando porque a porta 10051 estava respondendo a um telnet, mas os dados não chegavam ao servidor. O problema era que o parâmetro EnableRemoteCommands estava como 0 no arquivo de configuração, mas o verdadeiro culpado era o firewall interno do próprio host, mais especificamente o SELinux no modo enforcing. O SELinux bloqueava conexões de rede vindas do processo zabbix_agentd que não estavam nas portas permitidas pelo contexto. A solução foi aplicar o comando semanage port -a -t zabbix_port_t -p tcp 10051 e depois ajustar o contexto do arquivo de log para zabbix_log_t. Sem isso, o agente respondia no telnet mas nunca enviava os dados para o servidor. Outra coisa que vale saber: o Zabbix Proxy trabalha na mesma porta 10050 do servidor. Ele recebe dados dos agentes na 10051 e repassa para o servidor na 10050. Se você tiver múltiplos proxies em uma topologia grande, cada um precisa ter acesso à porta 10050 do servidor central. Em redes com muitas sub-redes, isso pode significar muitas regras de firewall espalhadas, e é comum alguém esquecer de liberar um dos proxies.
Limitações e alternativas
O modelo de porta fixa tem desvantagens reais. Em ambientes com muitos hosts, abrir 10051 em cada máquina não escala bem do ponto de vista de segurança. Cada porta aberta é um vetor potencial de ataque. Por isso, o modo ativo é preferível em cenários grandes ou restritos. Além disso, se o Zabbix estiver atrás de um balanceador de carga ou NAT, a porta 10050 precisa estar mapeada corretamente, e o agente ativo precisa saber o IP real do servidor, não o VIP do balanceador. Se a sua situação envolve milhares de hosts distribuídos geograficamente, considere usar o Zabbix Proxy em cada localidade. Isso concentra o tráfego e reduz drasticamente o número de conexões diretas que o servidor central precisa gerenciar. O proxy resolve boa parte dos problemas de latência e de abertura de portas em redes remotas.
Resumindo de forma direta: use 10050 para servidor e proxy, 10051 para agente em modo passivo. Se puder, migre para modo ativo e esqueça a porta 10051. Verifique sempre o que está realmente rodando com ss ou netstat. Cheque os logs antes de supor que é firewall. E tome cuidado com SELinux, que é mais comum do que as pessoas imaginam em ambientes RHEL-based.
