Retenção longa em VPS para VictoriaMetrics

Resposta direta

Uma VPS para VictoriaMetrics pode ser uma boa escolha quando o objetivo é guardar métricas por longo prazo sem operar um cluster complexo. Para produção pequena ou média, comece pensando em 2 a 4 vCPUs, 4 a 8 GB de RAM e disco SSD ou NVMe a partir de 80 GB, ajustando pela taxa de ingestão, retenção desejada e cardinalidade das séries. O ponto crítico quase nunca é apenas CPU. Disco, IOPS, compressão, volume de labels e política de retenção decidem se o ambiente vai continuar estável após 90, 180 ou 365 dias. Prometheus pode continuar coletando métricas localmente e enviar dados por remote write para o VictoriaMetrics, enquanto Grafana consulta a base histórica para dashboards e análises.

Resumo rápido

• VictoriaMetrics é indicado para armazenar métricas por meses ou anos com boa compressão e consulta eficiente.
• Para produção básica, uma VPS com 2 vCPUs, 4 GB de RAM e 80 GB de SSD pode atender cargas pequenas, desde que a cardinalidade seja controlada.
• Para retenção longa, NVMe ajuda principalmente em compactação, consultas pesadas, escrita contínua e recuperação após reinício.
• Prometheus pode atuar como coletor e buffer curto, enviando dados para VictoriaMetrics via remote write.
• Grafana se conecta ao VictoriaMetrics usando compatibilidade com API do Prometheus, o que simplifica dashboards existentes.
• A política de retenção precisa ser calculada com base em amostras por segundo, compressão real e crescimento esperado.
• Backups, snapshots e testes de restauração são obrigatórios quando as métricas servem para auditoria, SLO ou investigação de incidentes.

Por que VictoriaMetrics faz sentido para métricas de longo prazo

VictoriaMetrics ganhou espaço em stacks de observabilidade porque resolve um problema comum: manter histórico de métricas sem multiplicar a complexidade operacional. Prometheus é excelente para coleta, alertas e consultas recentes, mas seu modelo local costuma ficar mais sensível quando a retenção cresce muito ou quando vários ambientes enviam métricas para o mesmo ponto de consulta. Em muitos times, a solução prática é deixar Prometheus com retenção curta, por exemplo 7 a 15 dias, e mandar uma cópia das amostras para VictoriaMetrics por remote write.

Esse desenho funciona bem em VPS ou Cloud Server quando o volume é previsível. Imagine uma empresa com 30 aplicações, 12 bancos PostgreSQL, 20 nós Linux e alguns exporters de Nginx, Redis e filas. Se cada alvo expõe milhares de séries e o scrape roda a cada 15 segundos, o crescimento diário pode parecer pequeno no começo, mas se acumula rápido. A diferença entre guardar 30 dias e 365 dias muda completamente o dimensionamento do disco.

Onde ela entra no stack de observabilidade

VictoriaMetrics costuma ficar entre a coleta e a visualização. Prometheus coleta os targets, aplica regras de alerta e envia dados para o VictoriaMetrics. Grafana consulta o VictoriaMetrics para dashboards de longo prazo, comparações semanais, sazonalidade, capacidade e análise pós-incidente. Se você já leu nosso conteúdo sobre monitoramento com Grafana e Prometheus, a lógica aqui é ampliar o horizonte histórico sem abandonar ferramentas conhecidas.

VPS tradicional, Cloud Server e instância cloud

Uma VPS tradicional normalmente roda em um servidor físico virtualizado, com recursos fixos e upgrade nem sempre imediato. Um Cloud Server tende a oferecer provisionamento mais flexível, troca de plano mais simples e recursos de rede e armazenamento com integração ao painel do provedor. Uma cloud instance em AWS, Google Cloud, Azure, DigitalOcean, Vultr ou Linode segue lógica parecida, mas com ecossistema próprio de volumes, snapshots e billing. Para VictoriaMetrics single-node, todas as opções podem funcionar. A diferença está em previsibilidade de disco, latência, facilidade de expansão e custo operacional.

Como dimensionar CPU, RAM e disco para retenção longa

O dimensionamento de uma VPS para VictoriaMetrics começa por uma pergunta bem prática: quantas amostras por segundo entram no banco? Um ambiente pequeno pode gerar 2 mil a 10 mil samples por segundo. Um ambiente médio, com muitos containers, exporters detalhados e labels por namespace, pode passar de 50 mil samples por segundo. A partir daí, você estima retenção, margem de crescimento e padrão de consulta. Uma consulta simples de CPU por host é barata. Um dashboard com 20 painéis, agregações por pod, aplicação, status code e zona pode pressionar CPU e disco ao mesmo tempo.

Para um laboratório ou projeto interno, 2 vCPUs, 4 GB de RAM e 80 GB de SSD costumam ser suficientes para testar retenção de 30 a 90 dias com baixa cardinalidade. Em produção pequena, uma base mais segura é 4 vCPUs, 8 GB de RAM e 160 a 250 GB de SSD ou NVMe. Para retenção anual, múltiplos ambientes e dashboards acessados por várias pessoas, pense em 4 a 8 vCPUs, 16 GB de RAM e 500 GB ou mais, com monitoramento do próprio VictoriaMetrics desde o primeiro dia.

Estimando ingestão diária

Uma conta simples ajuda. Se você coleta 10 mil samples por segundo, são 864 milhões de amostras por dia. O tamanho em disco depende da compressão, da cardinalidade e do padrão das métricas. Em vez de confiar em um número mágico, rode um piloto por 7 dias e extrapole. Se a base cresceu 12 GB em uma semana, 180 dias podem exigir algo próximo de 309 GB antes de margem, snapshots e crescimento. Com margem de 30%, isso sobe para aproximadamente 400 GB.

Quando NVMe muda o resultado

NVMe não transforma uma configuração ruim em boa, mas ajuda em pontos específicos. Consultas de longo intervalo, merges internos, compactação, reinício após queda e escrita contínua se beneficiam de baixa latência de disco. Em servidores com SSD SATA compartilhado e IOPS limitadas, é comum ver dashboards lentos quando alguém consulta 180 dias por serviço. Em NVMe, o gargalo pode migrar para CPU ou cardinalidade. Por isso, disco rápido deve vir junto de retenção bem definida, labels controladas e alertas de uso de storage.

Retenção, cardinalidade e custos invisíveis

Retenção longa não é só uma configuração do tipo 365d. Ela é uma decisão de produto, operação e custo. Guardar tudo por um ano parece confortável, mas talvez sua equipe só precise de alta granularidade nos últimos 30 dias e dados agregados depois disso. VictoriaMetrics oferece recursos para retenção e downsampling em versões e arquiteturas específicas, mas mesmo no uso single-node a disciplina de métricas continua central. Se você coleta métricas com labels dinâmicas demais, como user_id, request_id, session_id ou path completo com parâmetros, a quantidade de séries explode.

Cardinalidade alta é uma das maiores causas de aumento de custo em bancos de séries temporais. Um exporter pode parecer inocente, até que um label por cliente, endpoint ou container efêmero crie milhões de séries. O efeito aparece no disco, na RAM, na velocidade de consulta e no tempo de compactação. Para longo prazo, o ideal é revisar métricas antes de enviar tudo para armazenamento histórico. Métricas de negócio podem ser agregadas. Métricas de debug podem ficar só no Prometheus local por poucos dias.

Exemplos de retenção por ambiente

Um ambiente de desenvolvimento pode manter 15 a 30 dias, com scrape a cada 30 segundos. Staging pode guardar 30 a 60 dias, suficiente para comparar builds e investigar regressões. Produção costuma pedir 180 a 400 dias quando há SLO, sazonalidade, cobrança por uso ou auditoria técnica. Um e-commerce, por exemplo, pode querer comparar Black Friday, campanhas de mídia e picos de checkout. Uma API B2B pode precisar provar disponibilidade mensal para clientes.

Sinais de cardinalidade fora de controle

Alguns sinais aparecem cedo. O disco cresce mais rápido que o tráfego. Consultas por labels específicos ficam lentas. O número de séries ativas sobe depois de deploys. Dashboards de Kubernetes ficam pesados após recriação de pods. Nesses casos, reduza labels antes de aumentar a VPS. Aumentar RAM e NVMe compra tempo, mas não corrige métrica mal modelada. A mesma lógica vale para logs. Se o time também centraliza logs, o artigo sobre Loki em VPS para logs centralizados ajuda a separar o que deve ser métrica, log e evento.

Integração com Prometheus, Grafana e alertas

A integração mais comum usa Prometheus como coletor e VictoriaMetrics como armazenamento remoto. No Prometheus, a configuração de remote write aponta para o endpoint do VictoriaMetrics, normalmente algo como http://victoriametrics:8428/api/v1/write em uma rede interna Docker ou http://IP-privado:8428/api/v1/write em servidores separados. Em produção, prefira rede privada, firewall restritivo e autenticação via proxy reverso quando houver exposição entre máquinas. Não exponha o endpoint de escrita publicamente sem controle, porque qualquer origem poderia tentar enviar dados.

Um exemplo mínimo de configuração é simples: em prometheus.yml, use remote_write com url apontando para o VictoriaMetrics. Mantenha scrape_interval em 15s ou 30s conforme criticidade. Para workloads de infraestrutura, 15s dá boa visibilidade. Para métricas de negócio ou ambientes pequenos, 30s reduz ingestão pela metade. Se você usa Docker Compose, coloque Prometheus, VictoriaMetrics e Grafana na mesma rede bridge, publique apenas Grafana atrás de HTTPS e mantenha portas internas fechadas para a internet.

Remote write na prática

Prometheus pode manter retenção local curta, como 7d, para consultas recentes e alertas. VictoriaMetrics recebe a cópia longa. Esse arranjo reduz impacto se o storage remoto ficar indisponível por curto período, mas não elimina a necessidade de monitorar fila de remote write. Acompanhe métricas como samples pending, retries, dropped samples e latência de envio. Se a VPS ficar sem I/O, Prometheus pode acumular fila e começar a descartar dados.

Grafana como camada de leitura

Grafana consulta VictoriaMetrics usando o data source Prometheus. Isso permite reaproveitar dashboards prontos, alertas visuais e consultas PromQL compatíveis. Para consultas longas, oriente o time a usar intervalos realistas. Um painel que abre 12 meses com resolução de 5 segundos pode ficar pesado sem necessidade. Ajuste min interval no Grafana, use recording rules quando fizer sentido e crie dashboards separados para operação diária, capacidade e auditoria. Quem também opera monitoramento tradicional pode comparar essa abordagem com Zabbix em VPS no Brasil, especialmente quando há SNMP, hosts legados e foco em infraestrutura clássica.

Comparação prática de perfis de VPS

A tabela abaixo não é uma promessa de capacidade universal. Ela serve como referência editorial para começar testes e conversas de dimensionamento. O comportamento real depende de samples por segundo, cardinalidade, compressão, retenção, tipo de disco, concorrência de consultas e limites do provedor. Antes de contratar ou migrar, rode um piloto com métricas reais por pelo menos 7 dias. Métricas artificiais raramente reproduzem labels de Kubernetes, exporters de aplicação e painéis usados por times de produto.

Perfil de uso	Configuração inicial	Retenção típica	Volume esperado	Observações técnicas
Laboratório e homelab	2 vCPUs, 4 GB RAM, 80 GB SSD	30 a 90 dias	Baixa ingestão, poucos targets	Bom para validar Prometheus, Grafana e alertas sem custo alto
Produção pequena	4 vCPUs, 8 GB RAM, 160 a 250 GB SSD ou NVMe	90 a 180 dias	APIs, bancos e 20 a 60 hosts	Exige controle de labels, firewall e backup testado
Produção com histórico anual	4 a 8 vCPUs, 16 GB RAM, 500 GB NVMe ou mais	180 a 400 dias	Vários ambientes e dashboards ativos	Precisa margem de disco, snapshots planejados e monitoramento da ingestão
Time com Kubernetes	8 vCPUs, 16 a 32 GB RAM, 1 TB NVMe	180 dias ou mais	Alta cardinalidade por pod e namespace	Revisar métricas de kube-state-metrics, cAdvisor e labels dinâmicas

Como interpretar os números

Se o seu ambiente tem poucos servidores, mas muitos exporters detalhados, não subestime o disco. Um único cluster Kubernetes pode gerar mais séries que dezenas de VMs tradicionais. Se o time consulta dashboards o dia inteiro, CPU e I/O importam mais do que em uma base usada apenas para auditoria mensal. Se há picos de deploy, autoscaling ou jobs efêmeros, a cardinalidade pode variar muito entre semanas.

Também existe diferença entre VPS, Cloud Server e provedores globais. DigitalOcean, Vultr, Linode, AWS Lightsail, Hetzner e Contabo oferecem perfis diferentes de disco, rede e regiões. LetsCloud pode fazer sentido quando o contexto pede presença próxima do público brasileiro ou operação em cloud nacional, mas recursos como NVMe, localidade, snapshots, backup automático e condições comerciais precisam ser confirmados por plano e região antes da publicação ou contratação. Dados de preço, bandwidth e disponibilidade mudam com frequência e devem passar por revisão humana.

Operação segura: backup, snapshots e upgrades

Métricas parecem menos críticas que banco transacional até o primeiro incidente sério. Quando um time precisa reconstruir a linha do tempo de uma queda, comparar latência entre versões ou provar SLO mensal, perder histórico vira problema real. Por isso, uma VPS para VictoriaMetrics deve ser tratada como componente de produção. Use firewall, acesso SSH por chave, usuário sem login direto de root quando possível, atualizações controladas e monitoramento do próprio serviço. O endpoint de escrita deve ficar protegido. O endpoint de leitura também merece cuidado se dashboards carregam nomes de clientes, hosts internos ou métricas sensíveis.

Backups precisam considerar tamanho e consistência. Snapshots do provedor são práticos, mas podem não bastar se forem feitos sem planejamento, em horários de escrita intensa ou sem teste de restauração. Quando o provedor oferece snapshots, confirme janela, custo, retenção e impacto. Quando há backup externo, valide tempo de upload e download. Uma base de 800 GB pode levar horas para restaurar, mesmo em rede boa. Em produção, documente o RTO aceitável, por exemplo 4 horas, e o RPO, por exemplo perda máxima de 30 minutos ou 24 horas.

Backups não substituem retenção

Retenção define por quanto tempo os dados ficam consultáveis. Backup define como recuperar o serviço após falha, exclusão ou corrupção. São coisas diferentes. Não adianta manter 365 dias de retenção se o único snapshot fica no mesmo provedor, na mesma conta, sem teste de restore. Também não adianta ter backup diário se a política de retenção apaga dados necessários para análises trimestrais. Combine as duas decisões no desenho operacional.

Plano de crescimento sem migração traumática

Comece medindo. Monitore uso de disco, taxa de ingestão, séries ativas, duração de consultas e latência de escrita. Defina alertas em 70%, 80% e 90% de uso de storage. Se o crescimento for previsível, planeje upgrade antes do alerta crítico. Em Cloud Server, aumentar disco pode ser simples, mas reduzir depois nem sempre é. Em VPS tradicional, migração pode exigir rsync, janela de manutenção e troca de DNS interno. Para bases grandes, teste o procedimento em ambiente paralelo antes do dia da migração.

Recomendações por perfil

Dev solo

Para um dev solo, freelancer ou homelab sério, o melhor caminho é começar pequeno e observável. Uma VPS com 2 vCPUs, 4 GB de RAM e 80 GB de SSD permite rodar VictoriaMetrics single-node, Prometheus e Grafana no mesmo servidor, desde que o volume seja baixo e os dashboards não sejam usados por muita gente ao mesmo tempo. Use Docker Compose, mantenha Prometheus com retenção local curta e envie dados por remote write. Defina retenção de 30 a 90 dias, porque isso já dá histórico suficiente para aprender padrões de tráfego, comparar deploys e investigar quedas simples. Não exponha portas internas. Publique apenas Grafana com HTTPS e senha forte.

Time de produto

Um time de produto com várias APIs, banco, filas e alguns serviços em Kubernetes precisa pensar em estabilidade antes de economia extrema. A base inicial recomendada fica em 4 vCPUs, 8 GB de RAM e 160 a 250 GB de SSD ou NVMe. Se houver dashboards compartilhados com engenharia, suporte e negócio, reserve CPU para consultas concorrentes. Use labels padronizadas, como service, environment, region e team, mas evite labels com valores infinitos. Retenção de 90 a 180 dias costuma equilibrar custo e utilidade. Nessa fase, vale separar Grafana e VictoriaMetrics se os dashboards ficarem pesados ou se o time precisar de janelas de manutenção diferentes.

Produção com retenção longa

Para produção com histórico anual, auditoria, SLO ou sazonalidade, trate VictoriaMetrics como parte central da plataforma. Comece em 4 a 8 vCPUs, 16 GB de RAM e 500 GB de NVMe, ajustando depois de medir ingestão real. Se o ambiente tiver Kubernetes com muitos pods, considere 1 TB ou mais e revise métricas de kube-state-metrics e cAdvisor antes de aumentar o plano. Retenção de 180 a 400 dias precisa de alertas de crescimento, snapshots testados, documentação de restauração e política clara de acesso. Quando consultas analíticas ficarem frequentes, avalie separar coleta, leitura e armazenamento ou migrar para arquitetura cluster, em vez de apenas empilhar recursos na mesma VPS.