Implantar o Zabbix em um VPS (2026): Docker, PostgreSQL, Agent 2, HTTPS, alertas e backups

O Zabbix não é apenas um painel para "ver curvas de CPU". Suas principais capacidades incluem:

• Coletar dados via Agent 2, SNMP, IPMI, JMX, HTTP, bancos de dados e APIs de nuvem;
• Criar em lote items, triggers, gráficos e regras de descoberta por meio de templates oficiais;
• Disparar alertas quando o disco está acabando, um serviço para, um certificado está prestes a expirar ou a taxa de erros de uma interface aumenta;
• Enviar notificações por e-mail, Webhook, SMS ou scripts personalizados;
• Usar grupos de hosts, grupos de usuários e funções para controlar quais recursos cada equipe pode ver;
• Escalar para vários data centers, redes internas e redes de alta latência com nós proxy.

Se você monitora apenas de 2 a 5 máquinas e quer concluir a instalação em dez minutos, o tutorial de monitoramento leve de servidores com Beszel consome menos recursos; se você só se importa se um site está online, pode escolher o Uptime Kuma. Quando precisa de PromQL, correlação de logs e visualização altamente flexível, leia a solução de monitoramento Prometheus + Grafana. Quando precisa de muitos templates prontos, triggers unificados, gestão de ativos e permissões granulares, o fluxo de trabalho integrado do Zabbix é mais adequado.

Este artigo usa quatro componentes principais:

浏览器 -> Caddy :443 -> Zabbix Web :8080
                              |
                              +-> PostgreSQL

受监控主机 Agent 2 -> Zabbix Server :10051（主动检查）
Zabbix Server -> 受监控主机 Agent 2 :10050（被动检查）

O frontend web, o Zabbix Server e o PostgreSQL rodam como contêineres no VPS de monitoramento; os hosts monitorados instalam o Agent 2 diretamente. O banco de dados não é mapeado para a internet pública, a porta do contêiner web é vinculada apenas ao endereço de loopback e o Caddy fornece o domínio e o HTTPS.

O Zabbix informa oficialmente que a capacidade do banco de dados depende principalmente do número de valores processados por segundo, do período de retenção de dados de histórico, do período de retenção de dados de tendência e do número de eventos. Não é possível estimar apenas pelo "número de hosts". Abaixo estão valores iniciais conservadores para um ambiente VPS pequeno, não uma garantia oficial de capacidade:

Embora 1GB ou 2GB de RAM possam iniciar, PostgreSQL, Server, Web e Docker na mesma máquina deixam muito pouca margem. Quando o próprio sistema de monitoramento para por OOM, ele fica em silêncio justamente quando você mais precisa dos alertas. Ambientes de produção também devem colocar os backups em outra máquina ou em armazenamento de objetos, e não apenas no mesmo disco do VPS de monitoramento.

Prepare um domínio, por exemplo zabbix.example.com, e adicione um registro A apontando para o IP público do VPS. Se você não tiver IPv6 correto e funcional, não adicione um registro AAAA incorreto.

Todos os componentes do Zabbix devem manter a hora precisa. A página de requisitos oficiais destaca especialmente a sincronização de horário, porque o desvio do relógio causa anomalias nos timestamps dos dados, na avaliação de triggers e nos gráficos. No Ubuntu 24.04 você pode verificar:

timedatectl status
systemctl status systemd-timesyncd --no-pager

Abra as portas padrão de acordo com o modo de coleta real:

Nas verificações ativas, o Agent 2 se conecta ativamente ao 10051/TCP do Server, o que é adequado para hosts atrás de NAT, com IP que muda com frequência ou quando você não quer expor 10050 ao exterior. Nas verificações passivas, o Server se conecta ao 10050/TCP do Agent 2; a configuração é intuitiva, mas exige que o Server consiga acessar o Agent diretamente. Os dois modos podem coexistir; em última análise, depende dos tipos de item no template.

Se uma porta já está escutando mas as conexões externas continuam falhando, siga o guia de solução de problemas de portas, firewall e grupos de segurança para verificar ao mesmo tempo o grupo de segurança da nuvem, o UFW, o mapeamento de portas do Docker e o endereço de escuta.

Primeiro atualize o sistema e instale Git, Make, OpenSSL e Caddy. Recomenda-se instalar o Docker a partir do repositório oficial do Docker para Ubuntu; se a máquina já estiver executando Docker, não execute novamente scripts que alterem a configuração do repositório.

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y git make openssl ca-certificates curl caddy
docker --version
docker compose version

A documentação oficial de contêineres do Zabbix 7.4 exige Docker Compose 2.24.0 ou superior:

docker compose version --short

Se a saída for inferior a 2.24.0, atualize primeiro o plugin do Docker Compose. Implantações em produção também devem entender verificações de integridade, rotação de logs, limites de recursos e rollback; você pode ler primeiro a lista de verificação de configuração de produção do Docker Compose.

O repositório oficial zabbix/zabbix-docker contém tanto combinações MySQL/MariaDB quanto PostgreSQL. Este artigo faz checkout explícito do branch 7.4 e usa compose_pgsql.yaml:

sudo git clone --depth 1 --branch 7.4 \
  https://github.com/zabbix/zabbix-docker.git /opt/zabbix-docker
sudo chown -R "$USER":"$USER" /opt/zabbix-docker
cd /opt/zabbix-docker
git branch --show-current
docker compose version

O branch esperado é 7.4. O .env padrão do repositório usa imagens Zabbix 7.4 da série Alpine e PostgreSQL 17 Alpine; a página oficial de requisitos do Zabbix 7.4 suporta PostgreSQL 15–18.

Não use diretamente a senha de banco de dados de exemplo do repositório. O env_vars/.POSTGRES_PASSWORD do repositório oficial é o valor de exemplo zabbix, que deve ser substituído antes da primeira inicialização:

cd /opt/zabbix-docker
umask 077
openssl rand -base64 36 | tr -d '\n' > env_vars/.POSTGRES_PASSWORD
printf '\n' >> env_vars/.POSTGRES_PASSWORD
chmod 600 env_vars/.POSTGRES_PASSWORD

Não copie senhas reais para tutoriais, tickets ou commits do Git. O Compose fornece o usuário e a senha do PostgreSQL aos contêineres Server, Web e de banco de dados por meio de secrets baseados em arquivos.

O Compose oficial publica a porta Web por padrão. Para evitar que 8080 e 8443 contornem o Caddy e fiquem expostos diretamente, crie um arquivo de substituição local que restrinja as duas portas ao endereço de loopback:

services:
  zabbix-web-nginx-pgsql:
    ports:
      - name: web-http
        target: 8080
        published: "8080"
        host_ip: 127.0.0.1
        protocol: tcp
      - name: web-https
        target: 8443
        published: "8443"
        host_ip: 127.0.0.1
        protocol: tcp

Salve como /opt/zabbix-docker/compose.local.yaml e primeiro renderize a configuração para verificar a sintaxe e as portas finais:

cd /opt/zabbix-docker
docker compose -f compose_pgsql.yaml -f compose.local.yaml config > /tmp/zabbix-compose-rendered.yaml
grep -nE 'host_ip|published|target' /tmp/zabbix-compose-rendered.yaml

Confirme que o host_ip do Web é 127.0.0.1 e então inicie o conjunto mínimo de componentes:

docker compose -f compose_pgsql.yaml -f compose.local.yaml pull
docker compose -f compose_pgsql.yaml -f compose.local.yaml up -d
docker compose -f compose_pgsql.yaml -f compose.local.yaml ps

A primeira inicialização precisa inicializar o esquema do PostgreSQL, e o tempo depende do disco do VPS e da velocidade de download das imagens. Não julgue que houve falha só porque o contêiner de inicialização saiu; server-db-init deve terminar após concluir normalmente. Concentre-se em verificar se PostgreSQL, Zabbix Server e Nginx Web estão em execução ou saudáveis:

docker compose -f compose_pgsql.yaml -f compose.local.yaml logs --tail=100 postgres-server
docker compose -f compose_pgsql.yaml -f compose.local.yaml logs --tail=100 zabbix-server
docker compose -f compose_pgsql.yaml -f compose.local.yaml logs --tail=100 zabbix-web-nginx-pgsql
curl -I http://127.0.0.1:8080/
ss -lntp | grep -E ':8080|:8443|:10051'

8080 e 8443 devem aparecer apenas em 127.0.0.1; se 10051 escuta externamente depende de você precisar que Agents externos se conectem ativamente. Mesmo que seja necessário publicar 10051, restrinja a origem no grupo de segurança da nuvem e no firewall do host.

Crie /etc/caddy/Caddyfile:

zabbix.example.com {
    encode zstd gzip
    reverse_proxy 127.0.0.1:8080

    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Content-Type-Options "nosniff"
        Referrer-Policy "strict-origin-when-cross-origin"
    }
}

Substitua o domínio de exemplo pelo domínio real, verifique e recarregue:

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy
sudo systemctl status caddy --no-pager
curl -I https://zabbix.example.com/

O Caddy solicita e renova certificados automaticamente, mas somente se o domínio resolver corretamente, o 80/443 público conseguir chegar ao VPS e não houver registro AAAA incorreto. Para mais informações sobre vários domínios, cabeçalhos de proxy reverso e solução de problemas de certificados, consulte o tutorial de HTTPS automático com Caddy.

A conta inicial indicada no início rápido oficial do Zabbix é:

用户名：Admin
密码：zabbix

Altere a senha de Admin imediatamente após o primeiro login. Não trate o HTTPS do Caddy como uma estratégia completa de segurança do backend; você também deve:

1. Criar uma conta independente para cada administrador, sem compartilhar Admin;
2. Atribuir funções, grupos de usuários e permissões de grupos de hosts conforme as responsabilidades;
3. Ativar uma política de senhas fortes e configurar MFA quando as condições permitirem;
4. Quando o gerenciamento público não for necessário, restringir o frontend via WireGuard/Tailscale ou IP fixo;
5. Registrar as alterações separadamente no sistema, no firewall e no Zabbix;
6. Fazer a própria plataforma de monitoramento ser verificada externamente, para evitar que "o sistema de monitoramento morreu mas ninguém sabe".

O frontend do Zabbix pausa por 30 segundos após cinco logins consecutivos com falha, mas isso não é motivo para substituir as restrições de acesso do proxy reverso, o MFA e as senhas fortes.

As operações a seguir são realizadas em um VPS Ubuntu 24.04 monitorado. Use o repositório oficial de software do Zabbix 7.4; não instale o Agent a partir de scripts desconhecidos:

cd /tmp
wget https://repo.zabbix.com/zabbix/7.4/release/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_7.4+ubuntu24.04_all.deb
sudo dpkg -i zabbix-release_latest_7.4+ubuntu24.04_all.deb
sudo apt update
sudo apt install -y zabbix-agent2
zabbix_agent2 -V

Primeiro decida se vai usar verificações ativas ou passivas.

ServerActive=zabbix.example.com:10051
Hostname=web-01.example.com

Server=监控VPS的固定公网IP
ListenPort=10050
Hostname=web-01.example.com

sudo ufw allow from 监控VPS的固定公网IP to any port 10050 proto tcp
sudo ufw status numbered

sudo zabbix_agent2 -t system.cpu.load
sudo systemctl enable --now zabbix-agent2
sudo systemctl status zabbix-agent2 --no-pager
sudo journalctl -u zabbix-agent2 -n 100 --no-pager

O HTTPS protege apenas o link do navegador até o frontend web e não criptografa automaticamente a comunicação entre Agent e Server. Os componentes do Zabbix suportam três métodos de conexão: sem criptografia, certificado e PSK. Para VPS de pequena escala, gere um PSK independente para cada host:

sudo install -d -m 750 -o root -g zabbix /etc/zabbix/keys
sudo sh -c 'openssl rand -hex 32 > /etc/zabbix/keys/web-01.psk'
sudo chown root:zabbix /etc/zabbix/keys/web-01.psk
sudo chmod 640 /etc/zabbix/keys/web-01.psk

Para verificações ativas, adicione:

TLSConnect=psk
TLSPSKIdentity=web-01-psk
TLSPSKFile=/etc/zabbix/keys/web-01.psk

Se também usar verificações passivas, adicione:

TLSAccept=psk

Depois reinicie o Agent:

sudo systemctl restart zabbix-agent2
sudo journalctl -u zabbix-agent2 -n 50 --no-pager

Na aba Encryption do host no frontend do Zabbix, selecione o mesmo modo de conexão e informe exatamente a mesma identidade PSK e chave. Não envie chaves para chats em grupo nem permita que vários hosts compartilhem a mesma. A documentação oficial indica que TLSConnect do Agent 2 é usado para conexões de saída das verificações ativas, e TLSAccept para conexões de entrada das verificações passivas; quando os modos das duas pontas não coincidem, não há fallback automático para outro método de criptografia.

Acesse Data collection → Hosts → Create host:

1. Defina Host name como web-01.example.com, correspondendo exatamente ao Hostname do Agent 2;
2. Adicione um grupo de hosts como Linux servers;
3. No modo ativo, você pode criar uma interface Agent, mas não depende de o Server se conectar diretamente a ela; no modo passivo, informe o IP acessível do host e 10050;
4. Vincule os templates Linux Agent/Agent active correspondentes incluídos no Zabbix 7.4;
5. Informe a configuração PSK deste host em Encryption;
6. Após salvar, observe Availability, Latest data e os logs do Agent.

Não vincule todos os templates de uma vez no início. Quanto mais templates e menor o intervalo de coleta, mais rápido crescem o número de novos valores por segundo e o banco de dados. Primeiro cubra CPU, memória, disco, rede, processos e status de serviços, e depois adicione monitoramento de Nginx, PostgreSQL, Docker ou aplicações personalizadas conforme o negócio.

Verificações recomendadas primeiro:

• Se Latest data mostra métricas de CPU, memória e sistemas de arquivos;
• Se o nome do host corresponde exatamente;
• Se as verificações ativas conseguem se conectar a 10051;
• Se o Server consegue se conectar ao 10050 do Agent nas verificações passivas;
• Se Monitoring → Problems mostra items unsupported;
• Se os horários do sistema do Server e do Agent 2 são consistentes.

A documentação oficial atual do Zabbix suporta tipos de mídia Email, SMS, scripts personalizados e Webhook. Para realmente receber notificações, três condições devem ser atendidas ao mesmo tempo: um tipo de mídia funcional, Media na conta do usuário e uma Action que corresponda ao evento.

O History do Zabbix armazena valores brutos de alta granularidade, enquanto o Trends armazena dados agregados por hora. Manter todo o History por um ano geralmente é desnecessário e aumentará significativamente o tamanho do PostgreSQL, o tempo de backup e o risco nas atualizações.

Ambientes pequenos podem começar com a seguinte política e depois ajustá-la conforme as necessidades de conformidade e solução de problemas:

Acesse Administration → Housekeeping para verificar o housekeeping interno. A documentação oficial indica que ele exclui dados expirados ou removidos para evitar o crescimento ilimitado do banco de dados e a degradação de desempenho. Não reduza de repente o período de retenção de um ano para um dia esperando que o banco de dados diminua imediatamente; exclusões em massa geram carga no banco de dados, e a recuperação de espaço também depende dos mecanismos de manutenção do PostgreSQL.

Registre semanalmente o tamanho dos contêineres, do banco de dados e do diretório de dados:

cd /opt/zabbix-docker
docker compose -f compose_pgsql.yaml -f compose.local.yaml ps
docker system df
sudo du -sh /opt/zabbix-docker/zbx_env
df -h /

Ao mesmo tempo, monitore dentro do Zabbix o espaço em disco, as filas, os processos e as métricas de desempenho internas do próprio "VPS de monitoramento".

Um backup válido inclui pelo menos:

• Um backup lógico do banco de dados PostgreSQL;
• /opt/zabbix-docker/.env, env_vars, arquivos de substituição e scripts personalizados/certificados em zbx_env;
• /etc/caddy/Caddyfile;
• A configuração /etc/zabbix e o PSK do lado do Agent;
• Um documento de recuperação que indique claramente a versão, a ordem de recuperação e as dependências de DNS/firewall.

Criar um backup do banco de dados:

cd /opt/zabbix-docker
sudo install -d -m 700 /var/backups/zabbix
docker compose -f compose_pgsql.yaml -f compose.local.yaml \
  exec -T postgres-server pg_dump -U zabbix -d zabbix -Fc \
  > /var/backups/zabbix/zabbix-$(date +%F-%H%M).dump
ls -lh /var/backups/zabbix/

Os arquivos de configuração podem ser arquivados separadamente, mas contêm senhas de banco de dados e PSKs, portanto o meio de backup deve ser criptografado e as permissões restritas:

sudo tar -C / -czf /var/backups/zabbix/zabbix-config-$(date +%F-%H%M).tar.gz \
  opt/zabbix-docker/.env \
  opt/zabbix-docker/env_vars \
  opt/zabbix-docker/compose.local.yaml \
  etc/caddy/Caddyfile
sudo chmod 600 /var/backups/zabbix/*

Em seguida, sincronize o backup para outra máquina ou armazenamento de objetos e restaure-o periodicamente em um ambiente isolado. Apenas ver que um arquivo de backup existe não significa que ele possa ser restaurado. Para um processo completo de simulação com bancos de dados, Docker Volumes, restic e rclone, consulte simulação de backup e recuperação em VPS.

Ao testar a recuperação, primeiro implante a mesma versão principal do Zabbix e um PostgreSQL vazio, e depois importe:

cat /path/to/zabbix.dump | docker compose \
  -f compose_pgsql.yaml -f compose.local.yaml \
  exec -T postgres-server pg_restore -U zabbix -d zabbix --clean --if-exists

Este comando limpará os objetos que já existem no banco de dados de destino; ele só pode ser executado em um banco de dados de teste de recuperação confirmado como descartável ou em um processo explícito de recuperação de desastres, e não deve ser executado de forma casual contra um banco de dados de produção ainda em serviço.

O Compose oficial do 7.4 usa por padrão a tag latest do mesmo branch, portanto pull pode baixar uma nova imagem de patch 7.4. Antes de atualizar, você deve ler as notas de atualização e fazer backup do banco de dados, da configuração e dos arquivos. O Zabbix Server pode executar automaticamente uma atualização do banco de dados na inicialização; se a atualização do banco de dados falhar, o serviço não iniciará normalmente.

Processo recomendado:

1. Registrar o ID da imagem atual, a versão do Zabbix e o commit do Git;
2. Concluir backups do banco de dados e da configuração em outra máquina;
3. Verificar a atualização em um ambiente de teste;
4. Agendar uma janela de manutenção e interromper as gravações;
5. Atualizar os arquivos Compose do branch 7.4 e renderizar o diff;
6. Baixar as imagens e reconstruir;
7. Observar continuamente os logs do Server e do PostgreSQL;
8. Verificar login, Latest data, Problems, notificações e conexões dos Agents.

Verificar o status atual:

cd /opt/zabbix-docker
git rev-parse --short HEAD
docker compose -f compose_pgsql.yaml -f compose.local.yaml images
docker compose -f compose_pgsql.yaml -f compose.local.yaml exec -T zabbix-server zabbix_server -V

Não troque de branch às cegas entre versões principais e depois execute up -d diretamente, nem dependa de snapshots da nuvem quando não há backup do banco de dados. O rollback do banco de dados e o rollback da imagem do contêiner devem andar juntos; não há garantia de que um Server antigo consiga ler um novo esquema de banco de dados já atualizado.

• Zabbix Server, Web e PostgreSQL funcionam normalmente, e o contêiner de inicialização conclui normalmente;
• O 8080/8443 do Web está vinculado apenas a 127.0.0.1;
• O HTTPS do domínio é válido e o HTTP redireciona automaticamente para HTTPS;
• A senha padrão de Admin/zabbix foi alterada;
• Os administradores usam contas independentes, privilégio mínimo e MFA;
• Os modos ativo/passivo do Agent correspondem à direção do firewall;
• O PSK está configurado por host, não é reutilizado e não foi enviado ao Git;
• O Latest data é atualizado continuamente e os relógios dos hosts estão sincronizados;
• Tanto o Problem quanto o Recovery do e-mail ou Webhook foram realmente testados;
• Os períodos de retenção de History, Trends, Events e Audit foram planejados;
• O PostgreSQL e a configuração estão com backup em outra máquina e uma simulação de recuperação foi concluída;
• A verificação externa de disponibilidade consegue detectar que o próprio Zabbix está offline.

• Documentação atual e requisitos de instalação do Zabbix 7.4
• Instruções oficiais de instalação de contêineres do Zabbix
• Branch 7.4 do repositório oficial de Docker Compose do Zabbix
• Parâmetros de configuração do Zabbix Agent 2
• Documentação de criptografia dos componentes do Zabbix
• Documentação de login e senha padrão do Zabbix
• Tipos de mídia e notificações do Zabbix
• Zabbix Housekeeping

O valor do Zabbix não está em "quantos gráficos ele consegue desenhar", mas em transformar coleta, limites, notificações, permissões e verificação de recuperação em um processo operacional continuamente sustentável. Comece com poucas métricas principais, execute uma vez um alerta e uma recuperação reais, e depois amplie os templates gradualmente; isso é mais confiável do que importar dezenas de milhares de items no primeiro dia.