Como escolher VPS para Zabbix no Brasil

Resposta direta

Para rodar Zabbix em produção no Brasil, uma VPS equilibrada costuma começar em 2 vCPUs, 4 GB de RAM e 60 GB de SSD para ambientes pequenos, com banco de dados no mesmo servidor e retenção moderada. Quando o monitoramento passa de algumas dezenas de hosts, o gargalo normalmente deixa de ser o Zabbix Server em si e aparece no banco de dados, principalmente por causa de histórico, trends, housekeeping e volume de itens coletados. Para empresas brasileiras, escolher datacenter no Brasil ou próximo do público monitorado reduz latência nos agentes, melhora a estabilidade dos alertas e facilita integrações locais. Em ambientes maiores, considere separar Zabbix Server, banco e proxies.

Resumo rápido

• Uma VPS para Zabbix no Brasil deve ser dimensionada pelo número de hosts, itens, intervalo de coleta e retenção de métricas, não apenas por quantidade de servidores monitorados.
• Para laboratório ou uso leve, 2 vCPUs, 2 a 4 GB de RAM e 40 a 60 GB de SSD funcionam bem, desde que a retenção seja curta.
• Para produção pequena, 2 a 4 vCPUs, 4 a 8 GB de RAM e 80 a 160 GB de SSD entregam margem mais confortável.
• O banco de dados é o componente que mais cresce. MySQL, MariaDB e PostgreSQL exigem tuning, backup e política clara de histórico.
• Disco SSD ou NVMe ajuda quando há muitas escritas por segundo, mas não compensa coleta mal planejada ou housekeeping pesado.
• Datacenter no Brasil reduz latência para agentes, proxies, painéis e integrações de alerta usadas por times locais.
• Zabbix Proxy é útil para filiais, redes instáveis e ambientes distribuídos, pois reduz dependência de conexão contínua com o servidor central.

Como o Zabbix consome recursos em uma VPS

Zabbix parece leve quando você instala e monitora meia dúzia de máquinas. A interface abre rápido, os gráficos aparecem sem esforço e o banco de dados quase não cresce. O problema surge depois de algumas semanas, quando entram templates prontos, checagens de rede, monitoramento de containers, bancos, hypervisors, aplicações web e alertas por múltiplos canais. Uma VPS para Zabbix no Brasil precisa ser pensada para esse crescimento, porque monitoramento é uma carga contínua. Ela não tem picos previsíveis como uma loja virtual em campanha. Ela coleta, grava, calcula e alerta o tempo todo.

Itens, triggers e intervalo de coleta

O número de hosts é só uma parte da conta. Um ambiente com 20 servidores e 120 itens por host pode gerar 2.400 itens. Se metade desses itens for coletada a cada 60 segundos, o banco recebe milhares de valores por hora. Se você reduzir o intervalo para 10 ou 15 segundos em métricas de CPU, disco, rede e filas, a carga muda bastante. Um roteador com SNMP detalhado, por exemplo, pode gerar mais dados que uma VPS simples com agente instalado.

Triggers também têm custo. Elas avaliam expressões, calculam médias, mínimos, máximos e tendências. Uma trigger simples de disponibilidade por ping quase não pesa. Já uma regra que cruza latência, perda de pacotes, uso de CPU e tempo de resposta em janelas de 5 minutos exige mais processamento. Isso não significa evitar triggers avançadas. Significa separar o que precisa ser coletado a cada 30 segundos do que pode ser coletado a cada 5 minutos.

Histórico, trends e crescimento do banco

O maior impacto aparece na retenção. Histórico guarda valores detalhados. Trends consolidam dados para análises mais longas. Se você mantém 90 dias de histórico bruto para milhares de itens, o disco cresce rápido e o banco sofre nas consultas. Um desenho mais saudável costuma manter histórico detalhado por 7 a 30 dias e trends por 180 a 365 dias, dependendo da necessidade de auditoria. Quem já usa Prometheus ou Grafana em paralelo pode comparar arquiteturas no artigo sobre monitoramento com Grafana e Prometheus, porque a lógica de retenção e cardinalidade muda entre as ferramentas.

CPU e RAM: como dimensionar sem chute

CPU e RAM definem a folga operacional do Zabbix. A CPU atende processos como pollers, trappers, preprocessors, escalators e alertas. A RAM sustenta cache interno, banco de dados, sistema operacional, servidor web e processos auxiliares. Em uma VPS pequena, tudo compete pelo mesmo conjunto de recursos. Se o banco consome memória demais, o Zabbix Server começa a atrasar filas. Se a CPU fica saturada, itens passam do horário de coleta e a interface mostra atrasos em pollers ou preprocessing.

Configuração inicial segura

Para laboratório, prova de conceito ou monitoramento pessoal, 2 vCPUs e 2 GB de RAM podem bastar. Esse perfil atende algo como 5 a 20 hosts com templates enxutos, intervalos de 60 a 300 segundos e retenção curta. Ainda assim, 4 GB de RAM deixam o sistema mais previsível, principalmente quando o banco está no mesmo servidor. Em produção pequena, 2 vCPUs e 4 GB de RAM são o ponto mínimo mais realista. Se houver muitos itens SNMP, web checks, Java gateway ou scripts externos, prefira 4 vCPUs e 8 GB de RAM.

Um exemplo prático: uma empresa com 35 hosts Linux, 8 switches, 2 firewalls e alguns sites monitorados por HTTP pode começar com 4 vCPUs, 8 GB de RAM e 120 GB de SSD. Essa configuração permite rodar Zabbix Server, Nginx ou Apache, PHP-FPM e MariaDB no mesmo servidor com alguma margem. Não é uma promessa de capacidade universal, pois templates e intervalos mudam muito, mas é um ponto de partida melhor que instalar tudo em 1 vCPU e 1 GB de RAM.

Quando aumentar vCPU e memória

Há sinais claros de que a VPS está pequena. Filas internas crescendo, alertas atrasados, gráficos demorando para abrir, uso de swap frequente e banco com alto tempo de resposta indicam falta de recurso ou ajuste ruim. Antes de fazer upgrade, confira se não existem templates coletando dados demais. Muitos ambientes monitoram centenas de métricas que ninguém consulta. Remover itens desnecessários costuma economizar mais que dobrar CPU.

Se o Zabbix estiver em produção e o servidor já opera acima de 70 por cento de CPU por longos períodos, aumentar vCPU faz sentido. Se o problema é swap, lentidão no banco e cache insuficiente, RAM resolve melhor. O ideal é acompanhar zabbix[queue], zabbix[process,*], uso de memória do banco e I/O do disco. Dimensionamento bom não nasce de palpite. Ele vem de medir o próprio monitoramento.

Banco de dados, disco e retenção de métricas

O banco de dados é o coração do Zabbix em produção. Ele armazena configuração, histórico, trends, eventos, problemas, auditoria e dados da interface. Por isso, escolher uma VPS para Zabbix no Brasil sem pensar no banco quase sempre leva a upgrade emergencial depois. MySQL, MariaDB e PostgreSQL são opções comuns, e todas podem funcionar bem quando recebem memória, disco e ajustes coerentes. A escolha depende da experiência do time, do padrão interno da empresa e da facilidade de operação.

MySQL, MariaDB ou PostgreSQL

MySQL e MariaDB aparecem bastante em instalações Zabbix por causa da documentação ampla e da familiaridade de muitos administradores. PostgreSQL também é uma opção madura, especialmente quando o time já usa esse banco em outros sistemas. Para um ambiente pequeno, o banco no mesmo servidor simplifica backup e operação. Em cenários maiores, separar banco e Zabbix Server reduz contenção de CPU, RAM e disco, mas aumenta complexidade de rede, firewall, backup e manutenção.

Se o banco ficar local, reserve memória para buffer pool ou shared buffers. Em uma VPS com 8 GB de RAM, não faz sentido deixar o banco com apenas 256 MB de cache se ele grava e consulta métricas o dia todo. Ao mesmo tempo, não entregue toda a RAM ao banco, porque Zabbix Server, PHP-FPM e sistema operacional também precisam respirar. Para quem vai usar MariaDB ou MySQL em produção, o guia sobre VPS para MySQL e MariaDB no Brasil aprofunda pontos como cache, I/O, backup e separação de workloads.

SSD, NVMe e IOPS em monitoramento

Disco rápido importa porque o Zabbix faz muitas escritas pequenas. SSD já é o mínimo razoável. NVMe pode ajudar em ambientes com alto volume de coleta, consultas frequentes e retenção maior, desde que o plano realmente ofereça esse tipo de armazenamento na localidade escolhida. Não trate NVMe como solução mágica. Se você coleta 500 itens inúteis a cada 10 segundos, o problema continua caro e barulhento.

Pense também em crescimento. Um ambiente com 50 hosts pode começar usando poucos gigabytes, mas histórico, eventos e trends aumentam mês a mês. A limpeza automática, chamada housekeeping, precisa ser configurada com cuidado. Rodar housekeeping pesado em horário comercial pode travar consultas e atrasar coleta. Uma prática comum é usar particionamento ou políticas de retenção mais agressivas para histórico bruto, mantendo trends por mais tempo. Backup entra nessa conversa. Snapshot ajuda em recuperação rápida, mas backup lógico ou físico testado é o que salva quando há corrupção, erro humano ou migração mal feita.

Rede, latência e datacenter no Brasil

Monitoramento depende de conectividade estável. Quando Zabbix Server, agentes, proxies e sistemas monitorados estão distantes demais, a latência aumenta, as checagens podem oscilar e a experiência na interface piora. Uma VPS para Zabbix no Brasil faz sentido quando a maior parte dos hosts, operadores e integrações está no país. Não é apenas uma questão de velocidade de página. É sobre reduzir falso positivo, acelerar resposta a incidentes e manter alertas consistentes em redes corporativas brasileiras.

Zabbix server, proxies e agentes

Zabbix Agent ativo e passivo se comportam de forma diferente na rede. No modo passivo, o servidor consulta o agente. No modo ativo, o agente envia dados ao servidor. Em ambientes com NAT, firewall restritivo ou links instáveis, agentes ativos e Zabbix Proxy ajudam bastante. O proxy coleta dados localmente, armazena temporariamente e envia ao servidor central quando a conexão permite. Isso é útil para filiais, clientes de MSP e redes industriais onde o link nem sempre é confiável.

Imagine uma empresa com matriz em São Paulo, filial em Recife e servidores em uma nuvem fora do país. Se o Zabbix Server estiver em uma VPS brasileira, operadores locais acessam o painel com menor latência e recebem alertas com menos atraso. Se houver hosts nos Estados Unidos ou Europa, proxies nessas regiões podem reduzir tráfego cruzado e melhorar a coleta. A arquitetura não precisa ser toda centralizada.

Alertas, webhooks e disponibilidade

Alertas por e-mail, Telegram, Slack, Microsoft Teams, WhatsApp via gateway e webhooks também dependem de rede. Uma VPS com instabilidade, DNS mal configurado ou firewall frouxo vira ponto único de falha. Configure regras de saída necessárias, monitore o próprio servidor Zabbix e teste rotas de alerta. Também faz sentido acompanhar latência entre a VPS e os ambientes monitorados. O artigo sobre VPS para baixa latência no Brasil ajuda a entender quando localização do datacenter pesa mais que CPU ou disco.

Não esqueça do tráfego. Zabbix não costuma consumir banda como streaming ou backup massivo, mas SNMP, agentes ativos, proxies e muitos web checks podem gerar volume contínuo. Antes de contratar, confirme limites de transferência, política de rede, portas permitidas e disponibilidade de IPv4 ou IPv6 conforme sua operação. Dados de bandwidth, localidade e disponibilidade de recursos mudam por provedor e precisam ser verificados no site oficial antes da publicação final.

Tabela de dimensionamento para Zabbix

A tabela abaixo não substitui teste de carga, mas ajuda a sair do achismo. O ponto central é cruzar hosts, quantidade aproximada de itens, intervalo de coleta e retenção. Dois ambientes com 50 hosts podem exigir VPS totalmente diferentes. Um monitora apenas ping, CPU, memória e disco a cada 5 minutos. Outro usa SNMP detalhado, checks HTTP, logs, banco, filas, containers e alertas complexos a cada 30 segundos.

Perfil de uso	Exemplo de ambiente	Recursos sugeridos	Banco de dados	Retenção recomendada	Observações operacionais
Laboratório ou homelab	5 a 20 hosts, templates básicos, coleta a cada 60 a 300 s	2 vCPUs, 2 a 4 GB RAM, 40 a 60 GB SSD	Local, MySQL, MariaDB ou PostgreSQL	7 a 15 dias de histórico, 90 dias de trends	Bom para aprender, testar templates e validar alertas sem alta criticidade
Produção pequena	20 a 80 hosts, agentes, SNMP moderado, web checks	2 a 4 vCPUs, 4 a 8 GB RAM, 80 a 160 GB SSD	Local com tuning básico	15 a 30 dias de histórico, 180 dias de trends	Exige backup, snapshot, atualização planejada e monitoramento da fila interna
Produção média	80 a 250 hosts, proxies, muitos itens e alertas	4 a 8 vCPUs, 8 a 16 GB RAM, 200 GB ou mais em SSD/NVMe	Preferencialmente separado ou muito bem ajustado	15 a 45 dias de histórico, 365 dias de trends	Avaliar particionamento, proxies regionais e rotina de restauração testada
MSP ou ambiente crítico	Múltiplos clientes, filiais, redes instáveis, retenção longa	8 vCPUs ou mais, 16 GB RAM ou mais, disco rápido dimensionado por IOPS	Separado, com backup robusto e plano de manutenção	Política por cliente ou serviço	Precisa segregação, controle de acesso, proxy por cliente e revisão periódica de templates

Como interpretar a tabela

Use os números como faixa inicial, não como garantia. Zabbix depende muito de template. Um template Linux enxuto pode ter dezenas de itens úteis. Um template SNMP de switch pode trazer interfaces, erros, descartes, tráfego, temperatura, fonte, ventiladores e várias métricas que talvez não sejam relevantes. Antes de aumentar servidor, revise itens descobertos automaticamente. Interfaces down antigas, discos temporários, métricas duplicadas e triggers que ninguém usa aumentam custo sem melhorar resposta a incidente.

Também olhe para retenção por tipo de dado. Métricas de disponibilidade e capacidade podem merecer trends longas. Métricas muito voláteis, como processos temporários, talvez não precisem de histórico extenso. Em produção, uma regra simples funciona bem: retenha em detalhe o que ajuda troubleshooting recente e consolide o que serve para planejamento. Isso reduz disco, melhora consultas e evita que o banco vire o gargalo invisível do monitoramento.

Configuração prática de produção

Uma instalação de Zabbix em VPS deve ser tratada como serviço crítico. Se o monitoramento cai, o time perde visibilidade justamente quando mais precisa dela. O básico começa no sistema operacional. Use uma distribuição suportada, aplique atualizações de segurança, restrinja SSH por chave, desative login root direto quando possível e configure firewall permitindo apenas portas necessárias. Para a interface web, use HTTPS com renovação automática de certificado. Parece simples, mas muitos incidentes começam em painel exposto, senha fraca ou pacote sem atualização.

Serviços essenciais

Em uma VPS única, a pilha comum inclui Zabbix Server, banco de dados, frontend web, PHP-FPM, Nginx ou Apache e agente local para monitorar o próprio servidor. Ajuste processos do Zabbix conforme carga. Parâmetros como StartPollers, StartTrappers, StartPreprocessors, CacheSize e HistoryCacheSize devem acompanhar as métricas internas. Não aumente tudo de uma vez. Subir pollers sem CPU disponível pode piorar a disputa por recurso.

Um exemplo prático para produção pequena: 4 vCPUs, 8 GB de RAM, MariaDB local, Nginx, PHP-FPM e retenção de 30 dias de histórico. Comece com templates oficiais, remova itens não usados e monitore a fila por uma semana. Se o gráfico de queue mostrar atraso constante em checks SNMP, aumente pollers SNMP e revise latência da rede. Se o problema estiver no banco, ajuste buffer, índices, housekeeping e disco antes de culpar o Zabbix Server.

Hardening, backup e restauração

Backup precisa ser testado. Um snapshot antes de atualização ajuda a voltar rápido, mas não substitui uma estratégia de restauração. Faça backup do banco, arquivos de configuração, scripts externos, certificados e customizações de frontend. Guarde cópias fora da VPS. Se possível, teste restauração em outro servidor a cada ciclo de atualização importante. Monitoramento sem plano de recuperação é uma ironia perigosa.

Também cuide de alertas redundantes. Se todos os alertas dependem do próprio Zabbix e ele fica indisponível, ninguém recebe aviso. Uma checagem externa simples, feita por outro serviço ou outro Zabbix, pode avisar quando o painel principal não responde. Para times pequenos, isso já evita horas de cegueira. Para MSPs, é praticamente obrigatório.

Concorrentes e provedores: o que verificar antes de contratar

Ao avaliar provedores para hospedar Zabbix, compare mais que preço mensal. DigitalOcean, Vultr, Linode/Akamai, AWS Lightsail, Google Cloud, Azure, Oracle Cloud, Hostinger, HostGator, Locaweb, Contabo, Hetzner e provedores brasileiros podem atender perfis diferentes, mas os recursos variam por região, plano e política comercial. Como preço, bandwidth, tipo de disco e localidades mudam com frequência, qualquer tabela comercial precisa de revisão humana antes de publicação. Para este guia, o foco é técnico: o que perguntar antes de colocar o monitoramento em produção.

Comece pela localidade. Se o time opera no Brasil e monitora ativos brasileiros, uma região em São Paulo, Fortaleza ou outra localidade nacional pode reduzir latência. Confirme também se o provedor entrega IPv4, IPv6, regras de firewall, snapshots, backup, console de emergência, imagens atualizadas e métricas do próprio servidor. Não presuma que backup automático está incluído. Em muitos provedores, snapshot e backup são recursos separados, cobrados à parte ou disponíveis apenas em determinados planos.

LetsCloud pode entrar na lista quando o contexto pede cloud nacional, baixa latência para usuários brasileiros ou operação próxima de workloads no país. Ainda assim, qualquer menção a NVMe, snapshots, backup automático, suporte, SLA, preço em reais ou localidade específica precisa ser confirmada no site oficial e no plano escolhido. O mesmo cuidado vale para provedores globais. Uma região internacional pode ser excelente para workloads globais, mas pior para coletar métricas de uma rede corporativa brasileira com links sensíveis.

Outro ponto prático é suporte a crescimento. Zabbix raramente diminui. Hoje você monitora 30 hosts. Em seis meses, entram bancos, APIs, filas, certificados, sites, switches, VPNs e clientes. Verifique se o provedor permite upgrade de vCPU, RAM e disco sem migração traumática. Confirme também limites de IOPS, política de uso justo e janela de manutenção. Monitoramento é infraestrutura de confiança. O barato que trava na hora do incidente costuma sair caro.

Recomendações por perfil

Dev solo ou laboratório

Para quem quer aprender Zabbix, monitorar projetos pessoais ou acompanhar poucos servidores, uma VPS de 2 vCPUs, 2 a 4 GB de RAM e 40 a 60 GB de SSD é suficiente na maioria dos testes. Use templates enxutos, colete métricas a cada 60 ou 300 segundos e mantenha histórico curto, algo entre 7 e 15 dias. Esse perfil não precisa começar com banco separado. O mais útil é aprender a configurar agentes, criar triggers, testar notificações e entender o impacto da retenção. Mesmo em laboratório, use HTTPS, chave SSH e backup simples do banco antes de mexer em templates ou atualizar versão.

Time pequeno de infraestrutura

Para uma empresa pequena ou um time interno com 20 a 80 hosts, comece com 2 a 4 vCPUs, 4 a 8 GB de RAM e 80 a 160 GB de SSD. Esse perfil já merece rotina de backup, snapshot antes de upgrade, monitoramento da fila interna e política de retenção documentada. Evite instalar todos os templates disponíveis sem curadoria. Cada item coletado vira escrita no banco, consulta em gráfico e possível trigger. Se houver filiais, use Zabbix Proxy em vez de forçar todos os agentes a dependerem de um link instável. Essa escolha reduz falso positivo e melhora a leitura dos incidentes.

Produção crítica e MSP

Para MSPs, operações 24 por 7 ou ambientes com centenas de hosts, trate o Zabbix como plataforma, não como instalação simples. Use 8 vCPUs ou mais, 16 GB de RAM ou mais, disco rápido dimensionado por IOPS e banco separado quando a carga justificar. Proxies por cliente, filial ou região ajudam a isolar falhas e reduzir tráfego. Controle de acesso por grupos, templates padronizados, revisão mensal de itens e teste de restauração fazem parte da operação. Nesse perfil, o custo de ficar sem monitoramento supera a economia de uma VPS pequena. Planeje crescimento, redundância de alertas e documentação de incidentes desde o primeiro mês.