Observabilidade para 1.200 servidores: VictoriaMetrics vs Prometheus
Em escala, a decisão não é sobre ferramenta favorita, e sim sobre cardinalidade, retenção e custo por métrica útil.
Problema real e contexto
Com mais de mil servidores, o volume de séries e a janela de retenção passaram a impactar performance e custo operacional.
Foi necessário revisar a arquitetura de coleta e armazenamento para manter consultas rápidas e alertas confiáveis.
Decisões técnicas
- Prometheus para scraping e regras locais de alerta.
- VictoriaMetrics para retenção longa e ingestão otimizada.
- Controle de cardinalidade por naming e labels obrigatórios.
- Dashboards com foco em SLO, não em vanity metrics.
Tip
Sem política de cardinalidade, qualquer stack de observabilidade degrada rapidamente.
Checklist final
- Definir budget de cardinalidade por domínio.
- Padronizar labels como env, service e tenant.
- Monitorar ingestão, query latency e uso de disco.
- Revisar periodicamente séries sem uso em dashboards/alertas.
Erros comuns
- Reter tudo por padrão sem critério de negócio.
- Criar labels de alta cardinalidade com IDs dinâmicos.
- Alertar em sinais ruidosos sem deduplicação.
Keywords
- VictoriaMetrics
- Prometheus
- metrics at scale
- remote write
Related reading
- Exporters Prometheus custom: Aruba, Meraki e Zabbix Observability Como padronizar métricas heterogêneas de rede e observabilidade para consultas consistentes.
- Docker → Kubernetes (K3s) em ambiente multi-tenant DevOps Checklist prático da migração para K3s: rollout, isolamento por tenant e trade-offs que evitaram incidentes.
- Alertas com deduplicação: GLPI + ServiceNow + Redis DevOps Estratégia para reduzir ruído operacional com idempotência, janelas de correlação e integração ITSM.