Como usar o VictoriaMetrics como alternativa escalável ao Prometheus

1. Introdução ao VictoriaMetrics e motivação para migração

O Prometheus consolidou-se como padrão de facto para monitorização de infraestruturas cloud-native, mas à medida que os ambientes crescem, surgem limitações significativas. A retenção de dados de longo prazo torna-se proibitiva em termos de memória, a alta cardinalidade de métricas pode causar picos de consumo de RAM e o modelo single-node do Prometheus carece de escalabilidade horizontal nativa.

O VictoriaMetrics surge como alternativa que mantém compatibilidade total com PromQL e oferece uma arquitetura significativamente mais eficiente. Construído em Go, utiliza estruturas de dados optimizadas que reduzem o uso de memória em até 10x comparado ao Prometheus, especialmente em cenários de alta cardinalidade. Suporta modo cluster nativo, permitindo escalar horizontalmente armazenamento e consultas. Casos de uso ideais incluem ambientes Kubernetes com milhares de pods, métricas de aplicações com muitos labels únicos e armazenamento de métricas por períodos superiores a 30 dias.

2. Instalação e configuração inicial do VictoriaMetrics

O VictoriaMetrics oferece dois modos de operação: single-node, adequado para ambientes com até 5 milhões de séries temporais ativas, e cluster, que escala horizontalmente para dezenas de milhões de séries.

Deploy com Docker Compose (modo single-node):

version: '3.8'
services:
  victoriametrics:
    image: victoriametrics/victoria-metrics:v1.102.0
    ports:
      - "8428:8428"
    volumes:
      - ./victoria-metrics-data:/storage
    command:
      - '-storageDataPath=/storage'
      - '-retentionPeriod=3'
      - '-httpListenAddr=:8428'

Para Kubernetes, utilize o Helm chart oficial:

helm repo add vm https://victoriametrics.github.io/helm-charts/
helm upgrade --install vm vm/victoria-metrics-single \
  --set server.retentionPeriod=3 \
  --set server.persistentVolume.size=50Gi

Configurações essenciais incluem -retentionPeriod (em meses), -storageDataPath (caminho para dados) e -memory.allowedPercent (percentual de RAM permitido).

3. Integração com exporters e scraping de métricas

O VictoriaMetrics pode substituir completamente o servidor Prometheus como alvo de scraping. Configure-o para coletar métricas de exporters padrão:

scrape_configs:
  - job_name: 'node_exporter'
    scrape_interval: 15s
    static_configs:
      - targets: ['localhost:9100']
  - job_name: 'kubernetes-pods'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_label_app]
        action: keep
        regex: my-app

Para ambientes que já utilizam Prometheus, configure o VictoriaMetrics como receptor remote write:

# No Prometheus
remote_write:
  - url: "http://victoria-metrics:8428/api/v1/write"
    queue_config:
      max_samples_per_send: 10000
      capacity: 50000

O VictoriaMetrics também suporta service discovery via Consul, file_sd_configs e DNS, tornando a transição transparente.

4. Consultas e visualização com VictoriaMetrics

O VictoriaMetrics oferece compatibilidade total com PromQL, além de funções estendidas como rollup_avg, rollup_max e histogram_share. Exemplos práticos:

# Query PromQL padrão - funcionamento idêntico ao Prometheus
rate(http_requests_total[5m])

# Função estendida - rollup para análise temporal
rollup_rate(http_requests_total[1h])

# Análise de cardinalidade via vmui
/api/v1/status/tsdb

Para integrar com Grafana, adicione um datasource do tipo "Prometheus" apontando para http://victoria-metrics:8428. A interface vmui integrada (http://localhost:8428/vmui) oferece exploração visual de métricas e análise de cardinalidade.

5. Estratégias de escalabilidade e alta disponibilidade

O modo cluster do VictoriaMetrics é composto por três componentes:

  • vmstorage: armazena dados em disco, escala horizontalmente adicionando nós
  • vminsert: recebe dados de escrita, faz hash por time series e distribui para vmstorage
  • vmselect: processa consultas, agrega resultados de múltiplos vmstorage

Arquitetura típica com HAProxy:

# vminsert (escrita)
frontend vminsert_frontend
    bind *:8480
    default_backend vminsert_backend

backend vminsert_backend
    balance uri
    server insert1 10.0.0.1:8480 check
    server insert2 10.0.0.2:8480 check

# vmselect (leitura)
frontend vmselect_frontend
    bind *:8481
    default_backend vmselect_backend

backend vmselect_backend
    balance first
    server select1 10.0.0.3:8481 check
    server select2 10.0.0.4:8481 check

Para replicação, configure -replicationFactor=2 e utilize armazenamento compartilhado (NFS, S3) para os dados do vmstorage.

6. Gerenciamento de cardinalidade e retenção de dados

A alta cardinalidade é o principal desafio em sistemas de métricas. O VictoriaMetrics expõe endpoints para diagnóstico:

# Listar séries com maior cardinalidade
curl http://localhost:8428/api/v1/status/tsdb | jq '.headStats'

# Filtrar labels problemáticos via relabeling
scrape_configs:
  - job_name: 'api'
    relabel_configs:
      - action: labeldrop
        regex: 'temporary_id|request_id'

Configure downsampling automático para reduzir armazenamento de dados antigos:

- '-downsampling.period=30d:5m,90d:1h'

Isso mantém dados brutos por 30 dias, médias de 5 minutos até 90 dias e médias de 1 hora após 90 dias.

7. Monitoramento e observabilidade da própria instância VictoriaMetrics

O VictoriaMetrics expõe métricas internas no endpoint /metrics. Configure alertas críticos:

# Alerta: muitas séries temporais
- alert: TooManyTimeSeries
  expr: vm_cache_entries{type="storage/timeSeries"} > 1000000
  for: 5m

# Alerta: uso elevado de disco
- alert: HighDiskUsage
  expr: vm_free_disk_space_bytes / vm_total_disk_space_bytes < 0.1
  for: 10m

Ative logs detalhados para debugging:

- '-loggerLevel=INFO'
- '-search.logSlowQueryDuration=5s'

8. Migração prática do Prometheus para VictoriaMetrics

A migração deve ser gradual para minimizar riscos:

  1. Dual-write: Configure o Prometheus para enviar dados simultaneamente ao VictoriaMetrics via remote write
  2. Validação: Compare consultas entre Prometheus e VictoriaMetrics usando a mesma janela temporal
  3. Migração histórica: Utilize o vmctl para transferir dados antigos:
vmctl prometheus \
  --prometheus-snapshot=/path/to/snapshot \
  --vm-addr=http://victoria-metrics:8428 \
  --vm-concurrency=4
  1. Checklist pós-migração:
  2. Verifique consultas críticas com PromQL
  3. Compare custos de armazenamento e memória
  4. Ajuste parâmetros de retenção e downsampling
  5. Monitore latência de queries

Após confirmar que o VictoriaMetrics atende aos requisitos, redirecione todo o tráfego e descomissione o Prometheus gradualmente.

Referências