VPS para Grafana e Prometheus: guia completo

Resposta direta

Uma VPS para Grafana e Prometheus deve ser dimensionada a partir de três variáveis: quantidade de targets monitorados, intervalo de coleta e tempo de retenção das métricas. Para um ambiente pequeno, com até 10 servidores ou aplicações e coleta a cada 15 segundos, uma VPS com 2 vCPUs, 4 GB de RAM e 80 GB de SSD já costuma ser um ponto de partida confortável. Quando entram Loki para logs, Alertmanager, exporters adicionais e retenção acima de 30 dias, faz mais sentido partir para 4 vCPUs, 8 GB de RAM e 160 GB ou mais de disco rápido. O Prometheus grava muitas séries temporais, então CPU ajuda nas consultas, mas disco e cardinalidade costumam definir a estabilidade do ambiente.

Resumo rápido

• Para laboratório ou uso individual, comece com 2 vCPUs, 4 GB de RAM e 80 GB SSD, mantendo retenção entre 7 e 15 dias.
• Para produção pequena, use 4 vCPUs, 8 GB de RAM e 160 GB SSD ou NVMe, principalmente se houver dashboards pesados e Alertmanager.
• O maior risco em Prometheus não é apenas volume de métricas, mas cardinalidade alta, como labels com user_id, request_id ou session_id.
• Logs mudam bastante o cálculo. Loki pode ser econômico, mas ainda exige disco, compressão, política de retenção e limites por tenant ou serviço.
• O intervalo de scrape mais comum é 15 segundos, mas aplicações menos críticas podem usar 30 ou 60 segundos para reduzir carga.
• Use Docker Compose para simplificar o deploy, mas mantenha volumes persistentes fora do diretório temporário e com backup regular.
• Exponha Grafana atrás de HTTPS, restrinja Prometheus e exporters por firewall e evite deixar métricas públicas na internet.
• Se a stack também hospedar aplicações, leia o guia de VPS para Docker antes de misturar observabilidade e workloads de produção.

Na prática, a melhor VPS para Grafana e Prometheus não é a que tem mais RAM no papel, e sim a que sustenta escrita constante em disco, consultas previsíveis e recuperação rápida em caso de falha. Uma stack pequena pode rodar muito bem em um único servidor. Já um ambiente com Kubernetes, múltiplos clusters, logs de aplicação e retenção longa precisa ser tratado como plataforma de dados operacional. Nesse caso, separar Prometheus, Grafana, Loki e banco de dashboards pode evitar gargalos difíceis de diagnosticar.

Por que hospedar Grafana e Prometheus em uma VPS

Hospedar Grafana e Prometheus em uma VPS faz sentido quando você quer controle total sobre retenção, plugins, exporters, alertas e custo operacional. Em uma solução gerenciada, boa parte disso vem pronta, mas você paga pela conveniência e aceita limites de ingestão, retenção ou consulta. Em uma VPS, o time define a política de scrape, o tempo de armazenamento, os dashboards, o Alertmanager e a integração com serviços como Telegram, Slack, e-mail ou webhook interno.

Prometheus é simples de começar, mas fica sério rápido. Ele coleta métricas por pull, grava séries temporais em disco local e responde consultas PromQL usadas pelo Grafana. Isso funciona muito bem para monitorar servidores Linux com node_exporter, containers com cAdvisor, aplicações web com métricas HTTP e bancos como PostgreSQL ou MySQL. Um exemplo comum é uma VPS de observabilidade monitorando 6 servidores, 20 containers e 3 bancos de dados, com coleta a cada 15 segundos. Não é um cenário enorme, mas já produz tráfego e gravação constantes.

A VPS também combina bem com equipes que precisam auditar o próprio ambiente. Você pode configurar regras de alerta para CPU acima de 85 por cento por 10 minutos, disco acima de 80 por cento, erro HTTP 5xx acima de 2 por cento ou fila de jobs crescendo por mais de 5 minutos. Esses alertas não dependem de painel de hospedagem, e sim de métricas expostas pela aplicação e pelos exporters.

O ponto de atenção é isolamento. Se a mesma VPS roda aplicação, banco e observabilidade, uma falha de disco ou CPU pode derrubar tudo ao mesmo tempo. Para laboratório, isso é aceitável. Para produção, a stack de monitoramento precisa sobreviver quando a aplicação está em crise. Quem usa clusters deve comparar essa abordagem com o guia de VPS para Kubernetes, porque monitorar pods, nodes e ingress controllers gera cardinalidade maior do que monitorar apenas servidores tradicionais.

Dimensionamento de CPU, RAM, disco e rede

O dimensionamento começa pela quantidade de séries temporais ativas. Uma série é a combinação de uma métrica com seus labels. A métrica http_requests_total pode virar milhares de séries se tiver labels como method, route, status, instance, pod e namespace. Se alguém adiciona user_id como label, o número explode. Esse tipo de erro transforma uma VPS confortável em um servidor com escrita pesada, consultas lentas e disco enchendo sem aviso.

Para um ambiente pequeno, pense em 10 a 30 mil séries ativas, scrape a cada 15 ou 30 segundos e retenção de 15 dias. Uma VPS com 2 vCPUs e 4 GB de RAM tende a ser suficiente, desde que o Grafana não execute dashboards com muitas consultas simultâneas. Para produção pequena ou média, calcule 100 a 300 mil séries ativas, múltiplos exporters e 30 dias de retenção. Nesse caso, 4 vCPUs, 8 GB de RAM e 160 GB de SSD ou NVMe são mais realistas. Ambientes acima disso pedem separação de serviços ou soluções de longo prazo, como Thanos, Mimir ou VictoriaMetrics, dependendo do desenho técnico.

CPU pesa mais em consultas PromQL e regras de gravação. Dashboards com rate em janelas longas, agregações por muitos labels e painéis atualizando a cada 5 segundos podem consumir bastante. RAM ajuda no cache e na execução de queries, mas não substitui um modelo de métricas bem desenhado. Disco é ainda mais sensível. Prometheus faz escrita contínua e compactação em blocos, então discos lentos aumentam latência interna e podem atrasar a ingestão.

Um exemplo prático: 20 servidores com node_exporter, 40 containers com cAdvisor e 10 aplicações expondo métricas customizadas podem ficar entre 150 mil e 400 mil séries, dependendo dos labels. Com scrape de 15 segundos, 30 dias de retenção e dashboards usados por 5 pessoas, eu não começaria abaixo de 4 vCPUs, 8 GB de RAM e 200 GB de disco. Se houver Loki no mesmo servidor, suba para 300 GB ou reduza retenção. Para entender melhor o impacto de cada recurso, o guia sobre como escolher CPU, RAM e NVMe ajuda a separar gargalo de processamento, memória e armazenamento.

Arquitetura recomendada para observabilidade em VPS

A arquitetura mais simples usa Grafana, Prometheus, Alertmanager e node_exporter. O Prometheus coleta métricas, o Grafana mostra dashboards, o Alertmanager envia notificações e o node_exporter expõe métricas do próprio Linux. Em uma VPS única, esses serviços podem rodar com Docker Compose, cada um com volume persistente. Uma estrutura comum é manter os arquivos em /opt/observability, com subdiretórios prometheus, grafana, alertmanager e exporters. Assim, backups e atualizações ficam mais previsíveis.

Para aplicações em containers, adicione cAdvisor ou métricas nativas do runtime. Para Nginx, use nginx-prometheus-exporter. Para PostgreSQL, postgres_exporter. Para Redis, redis_exporter. O segredo é não instalar exporter sem critério. Cada novo alvo aumenta séries, escrita e consultas. Um setup enxuto para uma API em produção pode ter node_exporter na VPS da aplicação, exporter do banco, métricas HTTP da própria API e blackbox_exporter para testar endpoints públicos. Isso já cobre CPU, memória, disco, latência, disponibilidade e erros.

Quando logs entram no projeto, Loki costuma ser o par natural do Grafana. Ele indexa labels e armazena linhas de log comprimidas, com custo menor do que soluções que indexam texto completo. Mesmo assim, logs podem crescer mais rápido do que métricas. Um serviço que grava 200 linhas por segundo, com média de 500 bytes por linha, gera cerca de 8,6 GB por dia antes de compressão. Com 14 dias de retenção, isso já pode pressionar uma VPS pequena se o mesmo disco hospeda Prometheus.

Em produção, a separação ideal depende do risco. Um time pequeno pode usar uma VPS dedicada para observabilidade e monitorar todo o resto a partir dela. Um ambiente maior pode separar métricas e logs em servidores diferentes. Para múltiplos clientes, ambientes SaaS ou clusters Kubernetes, também faz sentido separar por ambiente, como produção, staging e infraestrutura. Isso evita que um pico de logs em staging prejudique alertas de produção.

Retenção de métricas, logs e capacidade de armazenamento

Retenção é uma decisão técnica e financeira. Guardar tudo por 90 dias parece ótimo até a primeira consulta lenta ou o primeiro alerta de disco em 92 por cento. Para Prometheus local em VPS, retenções entre 15 e 30 dias costumam funcionar bem em ambientes pequenos e médios. O histórico longo pode ser enviado para armazenamento remoto ou uma solução específica de long-term storage. Assim, a VPS continua rápida para incidentes recentes, que são os mais consultados no dia a dia.

O cálculo exato depende de séries, intervalo de scrape e compressão. Uma estimativa conservadora é observar o crescimento real durante 24 horas e multiplicar pela retenção desejada, adicionando folga de 30 a 50 por cento para compactação, picos e atualizações. Se o diretório de dados do Prometheus cresce 4 GB por dia, uma retenção de 30 dias pede ao menos 120 GB apenas para métricas. Com folga, reserve 180 GB. Some Grafana, sistema operacional, logs locais e backups temporários. O resultado raramente cabe em um disco de 80 GB.

Prometheus permite limitar retenção por tempo e por tamanho. Em uma VPS, usar os dois é prudente. Um exemplo seguro é configurar retenção de 30 dias e limite de 140 GB em um disco de 200 GB, deixando espaço para o sistema e para operações de manutenção. Se o limite por tamanho for atingido, blocos antigos são removidos. Isso evita indisponibilidade por disco cheio, um dos problemas mais comuns em stacks de observabilidade autogerenciadas.

Logs pedem outra disciplina. No Loki, labels devem ser poucos e estáveis, como app, environment, host e level. Não use request_id, path completo ou usuário como label. Guarde esses dados dentro da linha de log. Também crie políticas diferentes: logs debug por 3 dias, logs info por 7 ou 14 dias, logs error por 30 dias. Para auditoria pesada, a VPS pode não ser o melhor destino final. Nesse caso, envie logs críticos para armazenamento externo e use o Loki local para troubleshooting rápido.

Deploy prático com Docker, systemd e volumes persistentes

Docker Compose é a forma mais direta de subir Grafana, Prometheus, Alertmanager e Loki em uma VPS. Ele facilita atualização de imagens, rede interna entre serviços e montagem de volumes. Um arranjo simples usa uma rede chamada observability, expõe apenas o Grafana na porta 3000 atrás de proxy HTTPS e mantém Prometheus, Alertmanager e Loki acessíveis apenas pela rede interna ou por VPN. O Prometheus não precisa ficar aberto para a internet. Exporters em outras máquinas podem ser protegidos por firewall, túnel privado ou rede overlay.

A estrutura dos arquivos importa. Coloque prometheus.yml, alertmanager.yml e datasources do Grafana em um repositório privado. Na VPS, mantenha volumes em /var/lib/prometheus, /var/lib/grafana e /var/lib/loki, ou em outro ponto montado com disco dedicado. Evite armazenar dados em caminhos que possam ser apagados por limpeza automática. Permissões também contam. Grafana costuma rodar com usuário interno específico, então volume com dono errado causa erro de inicialização. Prometheus precisa gravar blocos continuamente, logo qualquer problema de permissão aparece rápido nos logs.

Um fluxo de deploy saudável tem três etapas. Primeiro, validar configuração com promtool check config antes de reiniciar o Prometheus. Segundo, subir alterações com docker compose up -d e verificar docker compose ps. Terceiro, abrir o painel de targets e confirmar se não há endpoints em down. Para Grafana, exporte dashboards importantes em JSON ou use provisioning por arquivos. Isso evita perder painéis se o volume for corrompido ou se alguém apagar um dashboard por engano.

Systemd ainda tem papel útil. Mesmo com Docker Compose, você pode criar uma unidade systemd para iniciar a stack após reboot. Também pode usar timers para backup diário de configurações e verificação de espaço em disco. Em uma VPS pequena, configure logs do Docker com rotação, por exemplo limite de 50 MB por arquivo e 3 arquivos por container. Sem rotação, o próprio Docker pode consumir dezenas de gigabytes com logs de containers, competindo com Prometheus e Loki.

Segurança, backups e operação em produção

Uma VPS de observabilidade enxerga muito sobre o seu ambiente. Dashboards podem revelar nomes de serviços, rotas internas, volume de tráfego, erros, hosts, versões e comportamento de usuários. Por isso, o primeiro passo é reduzir superfície exposta. O Grafana deve usar HTTPS, senha forte, autenticação em dois fatores quando disponível e usuários com permissões por pasta ou organização. Prometheus, Alertmanager, Loki e exporters não devem ficar públicos. Se precisarem aceitar tráfego externo, restrinja por IP, VPN ou autenticação reversa no proxy.

Firewall básico já reduz muito risco. Abra 22 apenas para IPs administrativos ou use porta SSH protegida com chave, sem senha. Abra 80 e 443 para o proxy. A porta 3000 do Grafana pode ficar fechada externamente se o Nginx ou Caddy fizer proxy local. Portas de exporters, como 9100 do node_exporter, devem aceitar apenas o IP da VPS de monitoramento. Em ambientes com várias VPS, uma rede privada do provedor ajuda, mas a disponibilidade e o comportamento dessa rede precisam ser confirmados em cada plataforma.

Backups não são iguais para todos os componentes. Configurações são pequenas e devem ir para Git privado. Dados do Grafana, como banco SQLite, plugins e dashboards não provisionados, precisam de backup diário. Dados do Prometheus são maiores e mudam o tempo todo. Fazer backup bruto do diretório ativo pode gerar inconsistência se não houver snapshot de filesystem ou parada controlada. Para muitos times, a melhor estratégia é manter retenção curta local, versionar regras e dashboards, e aceitar que métricas antigas podem ser reconstruídas apenas parcialmente.

Ainda assim, snapshots da VPS são úteis antes de atualizações. Eles não substituem backup testado, mas ajudam em rollback rápido. Como preço, frequência e disponibilidade de snapshots variam por provedor e região, qualquer decisão deve ser validada no site oficial antes da publicação de um comparativo. Também monitore a própria stack. Crie alertas para PrometheusTargetMissing, disco acima de 80 por cento, aumento repentino de séries ativas, falha de compactação, fila de notificações no Alertmanager e erro 5xx no Grafana. A observabilidade também precisa ser observada.

Tabela comparativa de perfis de VPS para observabilidade

A tabela abaixo usa perfis técnicos, não preços. Ela serve como referência inicial para dimensionar uma VPS ou Cloud Server antes de escolher provedor. Os valores não substituem teste de carga, porque cardinalidade, intervalo de scrape, quantidade de dashboards e volume de logs mudam muito entre ambientes. Mesmo assim, esses perfis ajudam a evitar dois erros comuns: começar pequeno demais e culpar o Grafana por lentidão que vem do Prometheus, ou comprar uma VPS grande sem corrigir labels ruins.

Perfil técnico	Uso típico	Recursos recomendados	Retenção sugerida	Componentes na VPS	Atenção principal
Laboratório e dev solo	1 a 5 servidores, poucos containers, dashboards pessoais	2 vCPUs, 4 GB RAM, 80 GB SSD	7 a 15 dias	Grafana, Prometheus, node_exporter, Alertmanager opcional	Não misturar logs verbosos com métricas em disco pequeno
Produção pequena	5 a 20 servidores, APIs, banco, alertas reais	4 vCPUs, 8 GB RAM, 160 a 240 GB SSD ou NVMe	15 a 30 dias	Grafana, Prometheus, Alertmanager, exporters, Loki leve	Controlar cardinalidade e limitar retenção por tamanho
Time com logs centralizados	20 a 50 hosts ou muitos containers, troubleshooting frequente	4 a 8 vCPUs, 16 GB RAM, 300 a 500 GB SSD ou NVMe	Métricas 30 dias, logs 7 a 14 dias	Grafana, Prometheus, Alertmanager, Loki, Promtail ou Alloy	Separar logs debug e criar limites por aplicação
Ambiente crítico	Múltiplos clusters, SaaS, alertas 24x7, auditoria operacional	Separar serviços em 2 ou mais VPS, 8 vCPUs e 16 GB RAM por nó principal	Local 15 a 30 dias, histórico longo fora da VPS	Prometheus por ambiente, Grafana dedicado, storage remoto	Alta disponibilidade, backup testado e long-term storage

Ao comparar provedores como DigitalOcean, Vultr, Linode Akamai, AWS Lightsail, Hetzner, Contabo, Hostinger, Locaweb ou LetsCloud, olhe menos para o nome comercial do plano e mais para quatro pontos: tipo de disco, política de backup, região disponível e limite de tráfego. LetsCloud pode entrar no radar quando a localização no Brasil, cobrança local ou baixa latência forem relevantes, mas recursos como NVMe, snapshots, backup automático e regiões específicas precisam ser confirmados por plano e localidade. Não publique decisão baseada em preço sem revisão humana, porque planos e promoções mudam com frequência.

Recomendações por perfil

Dev solo e laboratório

Para um desenvolvedor que quer aprender Grafana e Prometheus, monitorar uma VPS pessoal, alguns containers e talvez uma aplicação Node.js, Laravel ou Python, a recomendação é começar simples. Use 2 vCPUs, 4 GB de RAM e 80 GB SSD. Configure scrape a cada 30 segundos, retenção de 7 ou 15 dias e poucos exporters. Rode Grafana, Prometheus e node_exporter no mesmo Docker Compose. Se quiser testar Loki, limite logs a 3 ou 7 dias e evite coletar tudo em nível debug. Esse perfil funciona bem para aprender PromQL, criar alertas básicos e entender comportamento de CPU, memória, disco e HTTP sem gastar energia com arquitetura distribuída.

Time pequeno com produção real

Um time pequeno, com 5 a 20 servidores ou várias aplicações em containers, deve tratar observabilidade como serviço interno. Comece com uma VPS dedicada de 4 vCPUs, 8 GB de RAM e 160 a 240 GB de SSD ou NVMe. Use Prometheus com retenção de 30 dias ou limite por tamanho, Alertmanager com rotas de notificação separadas e Grafana com dashboards versionados. Para logs, adicione Loki com retenção mais curta, geralmente 7 a 14 dias. O objetivo é responder perguntas práticas: qual deploy aumentou erro 5xx, qual banco saturou conexões, qual servidor está com disco crescendo e qual fila está atrasada.

Produção crítica e múltiplos ambientes

Em produção crítica, uma VPS única pode virar ponto único de falha. Se a observabilidade precisa acionar plantão, registrar incidentes e ajudar em auditoria, separe funções. Use um Prometheus por ambiente ou cluster, um Grafana dedicado e, quando necessário, armazenamento remoto para retenção longa. Uma configuração inicial pode ter 2 VPS: uma para métricas e alertas com 8 vCPUs, 16 GB RAM e 300 GB de disco, outra para logs com disco maior e retenção menor. Também teste restauração. Backup que nunca foi restaurado é só esperança documentada. Nesse perfil, alta disponibilidade, rede privada, controle de acesso e runbooks importam tanto quanto CPU e RAM.

Agências e consultorias com vários clientes

Agências que monitoram sites, lojas WooCommerce, APIs e servidores de clientes precisam isolar dados e permissões. Uma única instalação de Grafana pode funcionar, desde que pastas, organizações e datasources sejam bem separados. Para Prometheus, muitas vezes é melhor ter instâncias por cliente ou por grupo de clientes, reduzindo risco de vazamento e cardinalidade cruzada. Use nomes padronizados de labels, como client, environment e service, mas sem colocar dados sensíveis. Uma VPS com 8 vCPUs, 16 GB RAM e 300 GB SSD pode atender bem no início, mas o crescimento deve ser acompanhado semanalmente por séries ativas, uso de disco e tempo médio das consultas.

SaaS em crescimento

Um SaaS em crescimento precisa observar experiência do usuário, não apenas servidor ligado. Além de CPU, memória e disco, monitore latência p95 e p99, taxa de erro por endpoint, duração de jobs, filas, conexões de banco, cache hit rate e eventos de deploy. Nesse cenário, Prometheus e Grafana em VPS ainda podem funcionar, mas exigem governança. Defina padrões para métricas antes que cada equipe crie labels próprios. Separe dashboards executivos de dashboards técnicos. Configure alertas com janelas e severidade, evitando acordar o time por ruído. Quando a retenção histórica virar insumo de produto ou auditoria, avalie armazenamento remoto e arquitetura além de uma única VPS.