VictoriaMetrics: Alternativa Leve ao Prometheus para PME

O VictoriaMetrics é uma base de dados de séries temporais compatível com PromQL que consome até 7x menos RAM que o Prometheus. Funciona como single-binary, suporta remote_write, armazenamento de longo prazo e modo cluster — ideal para PME que precisam de monitorização escalável sem investir em infra-estrutura pesada.

Neste artigo:

• 1. Introdução ao VictoriaMetrics
• 2. Instalação Single-Node
• 3. Configurar Scraping
• 4. Remote Write do Prometheus
• 5. Cluster Mode para Escala
• 6. Integração com Grafana
• 7. Erros Comuns e Lista de Verificação

1. Introdução ao VictoriaMetrics

O VictoriaMetrics é um sistema de monitorização e armazenamento de séries temporais de código aberto, desenvolvido em Go, que oferece compatibilidade total com o ecossistema Prometheus. A principal vantagem sobre o Prometheus é a eficiência: consome 7x menos RAM e até 1,7x menos espaço em disco, graças à compressão de dados optimizada.

Para uma PME com 20-50 servidores, o Prometheus pode precisar de 4 GB de RAM só para reter 30 dias de métricas. O VictoriaMetrics faz o mesmo com menos de 600 MB. Isto reduz custos de infra-estrutura e permite retenção mais longa — 90 dias ou mais — sem hardware adicional.

Principais características:

• Single-binary — um ficheiro executável, sem dependências externas
• Compatível com PromQL — queries do Grafana funcionam sem alterações
• Suporta remote_write do Prometheus nativamente
• Armazenamento de longo prazo sem necessidade de Thanos ou Cortex
• Modo cluster horizontal com 3 componentes: vmselect, vminsert, vmstorage
• Compressão eficiente — até 0,5 bytes por ponto de métrica
• Suporte para métricas com alta cardinalidade sem degradação de desempenho

Documentação oficial em docs.victoriametrics.com e código-fonte no GitHub.

2. Instalação Single-Node

O modo single-node é a forma mais simples de começar. Um único contentor Docker expõe a API na porta 8428 e armazena dados localmente. Basta definir o período de retenção e o caminho de armazenamento.

# Instalar VictoriaMetrics single-node
docker run -d \
  --name victoriametrics \
  -v /vmdata:/storage \
  -p 8428:8428 \
  victoriametrics/victoriametrics \
  -retentionPeriod=90d \
  -storageDataPath=/storage

Após iniciar, o VictoriaMetrics fica disponível em http://localhost:8428. Verificar o estado com:

curl http://localhost:8428/health
# Resposta esperada: OK

Parâmetros importantes do single-node:

3. Configurar Scraping

O VictoriaMetrics pode recolher métricas directamente via vmagent, um agente leve que substitui o Prometheus para scraping. O vmagent suporta a mesma configuração de scrape_configs do Prometheus.

# vmagent.yml — configurar scraping de alvos
scrape_configs:
  - job_name: "node_exporter"
    static_configs:
      - targets: ["node1:9100", "node2:9100", "node3:9100"]
    scrape_interval: 15s

  - job_name: "docker"
    static_configs:
      - targets: ["docker-host:9323"]
    scrape_interval: 30s

# Iniciar vmagent
docker run -d \
  --name vmagent \
  -v ./vmagent.yml:/etc/vmagent.yml \
  -p 8429:8429 \
  victoriametrics/vmagent \
  -promscrape.config=/etc/vmagent.yml \
  -remoteWrite.url=http://victoriametrics:8428/api/v1/write

O vmagent envia as métricas recolhidas para o VictoriaMetrics via remoteWrite.url. Suporta múltiplos destinos, relabeling e filtragem — exactamente como o Prometheus, mas com menor consumo de recursos.

4. Remote Write do Prometheus

Se já tem Prometheus a correr, não precisa de o substituir imediatamente. Basta adicionar remote_write para enviar métricas ao VictoriaMetrics. Este funciona como infra-estrutura de armazenamento de longo prazo, enquanto o Prometheus mantém as métricas recentes locais.

# Configurar remote_write no Prometheus
# prometheus.yml:
remote_write:
  - url: http://victoriametrics:8428/api/v1/write

Esta configuração permite uma migração gradual: o Prometheus continua a fazer scraping e alertas localmente, enquanto o VictoriaMetrics armazena o histórico completo. Posteriormente, pode substituir o Prometheus pelo vmagent e manter apenas o VictoriaMetrics.

Para saber mais sobre o ecossistema de telemetria, consulte o artigo sobre o Grafana Alloy: Pipeline de Telemetria Unificado para PME.

5. Cluster Mode para Escala

Quando o single-node não chega — mais de 1 milhão de métricas por segundo ou retenção superior a um ano — o VictoriaMetrics oferece modo cluster com 3 componentes independentes:

• vmstorage — armazena séries temporais (não expõe API pública)
• vminsert — recebe dados via remote_write e distribui pelos vmstorage
• vmselect — executa queries PromQL e agrega resultados dos vmstorage

# Cluster mode (3 nós)
docker run -d --name vmselect -p 8481:8481 victoriametrics/vmselect --selectNode=vmselect:8481
docker run -d --name vminsert -p 8480:8480 victoriametrics/vminsert --insertNode=vminsert:8480
docker run -d --name vmstorage -v /vmdata:/storage victoriametrics/vmstorage -retentionPeriod=90d

O modo cluster permite adicionar nós vmstorage para aumentar capacidade horizontalmente. O vminsert e vmselect podem ser replicados para alta disponibilidade. Para uma PME típica, o single-node é suficiente — o cluster só se justifica com mais de 100 servidores monitorizados ou retenção superior a 12 meses.

6. Integração com Grafana

A integração com Grafana é directa — o VictoriaMetrics fala PromQL, por isso basta adicionar uma fonte de dados do tipo Prometheus apontando para o endpoint do VictoriaMetrics.

# Grafana datasource
# URL: http://IP_DO_SERVIDOR:8428
# Type: Prometheus
# Nota: usar "victoriametrics" como hostname apenas se o Grafana
# estiver na mesma rede Docker do VictoriaMetrics

No Grafana, ir a Configuration > Data Sources > Add data source, seleccionar Prometheus e definir o URL http://victoriametrics:8428. Todos os painéis existentes do Prometheus funcionam sem alterações — queries, variáveis e alertas incluídos.

Para configurar alertas, o VictoriaMetrics inclui o vmalert, que avalia regras Alertmanager-compatible e envia notificações. Pode reutilizar as mesmas regras de alerta do Prometheus sem modificações. Para uma abordagem mais ampla à monitorização, veja o artigo sobre monitoring com Prometheus e Grafana no Linux e o Dia 20 do Curso de Redes sobre SNMP, Zabbix e PRTG.

7. Erros Comuns e Lista de Verificação

Erros frequentes na implementação do VictoriaMetrics:

• Esquecer o -retentionPeriod — sem este parâmetro, os dados são apagados após 1 mês. Definir explicitamente conforme as necessidades de retenção.
• Não montar volume persistente — sem -v /vmdata:/storage, os dados perdem-se ao reiniciar o contentor.
• URL errada no remote_write — o endpoint correcto é /api/v1/write (não /api/v1/import).
• Misturar single-node com cluster — não apontar vmagent de cluster para endpoint de single-node; usam portas diferentes (8428 vs 8480/8481).
• Não configurar -memory.allowedBytes — sem limite, o VictoriaMetrics pode consumir mais RAM do que o esperado em sistemas com muita RAM disponível.

Lista de verificação para implementação:

Artigos Relacionados:

• Curso Linux Dia 25: Monitorização com Prometheus e Grafana
• Grafana Alloy: Pipeline de Telemetria Unificado para PME
• Curso Redes Dia 20: Monitorização de Rede — SNMP, Zabbix e PRTG