VictoriaMetrics frente a Prometheus: retención, copia y límite
Guía técnica para elegir almacenamiento de métricas: retención, scrape, permisos de consulta, backup y prueba de restauración con datos reales.
Quince días de métricas pueden costar poco; un año sin limpiar series puede llenar un disco y dejar ciega a una guardia. Prometheus y VictoriaMetrics resuelven el mismo dolor desde decisiones distintas de almacenamiento, retención y copia. Para una pyme, la pregunta práctica es cuánto historial necesita, quién consulta alertas y cómo se restaura. Esta guía compara componentes, costo y límite antes de mover datos reales. ## Dónde crece el costo de las métricas Prometheus documenta almacenamiento local con retención por tiempo o tamaño, y su configuración histórica usa 15 días como referencia frecuente para datos locales. Ese número ordena la conversación: si soporte solo mira incidentes de la semana, la retención corta sirve; si gerencia pide disponibilidad mensual, capacidad por temporada o SLA anual, el almacenamiento local empieza a pesar. La referencia externa viene de CNCF. En la encuesta anual 2025 publicada en 2026, Prometheus aparece con 77 % de uso en producción entre proyectos graduados relevados. La clínica de Godoy Cruz que mide turnos, impresoras y servidores no está copiando una rareza: está entrando en una práctica de infraestructura común. VictoriaMetrics publicó v1.153.0 el 28 de septiembre de 2026 con una advertencia sobre builds puros de Go que podían fallar al leer bloques válidos en ciertas plataformas. Ese aviso sirve como recordatorio operativo: la herramienta de métricas también necesita ventana de cambio, prueba de consulta y plan de reversa. El antagonista es la etiqueta de métrica sin dueño: una serie que nadie mira, se guarda cada 15 segundos y consume disco hasta que la alerta llega tarde.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. Primero, cada servidor, aplicación o router expone métricas por HTTP. Segundo, Prometheus o vmagent hace scrape y agrega etiquetas como servicio, entorno, sede y responsable. Tercero, Prometheus guarda muestras en su TSDB local o VictoriaMetrics las recibe en un storageDataPath propio. Cuarto, Grafana consulta y muestra paneles por rol: soporte, dirección o proveedor. Quinto, alertas revisan reglas y envían avisos con responsable. Sexto, backup y restauración recuperan configuración, datos de métricas y tableros. La documentación single-node de VictoriaMetrics describe un servidor único que recibe datos por protocolos compatibles y guarda series localmente. Prometheus, según su documentación de almacenamiento, escribe bloques locales y permite ajustar retención. En ambos casos, el dato vive en archivos de series temporales; las reglas y tableros viven en configuración aparte. La configuración de Prometheus define trabajos de scrape, etiquetas y targets. Una mala etiqueta multiplica series; un target sin dueño queda prendido meses. Para una pyme, el primer gobierno de métricas es escribir nombre de servicio, sede, responsable y período de retención antes de sumar exporters.
Qué se instala o configura primero
El primer entregable verificable es un tablero de diez métricas: disponibilidad HTTP, CPU, memoria, disco, cola de trabajos, latencia de base, errores por minuto, estado de backup, certificado TLS y último deploy. La pila inicial puede usar node_exporter, cAdvisor o exporters específicos, Prometheus o VictoriaMetrics, Grafana, Alertmanager o vmalert, y un repositorio de configuración con revisión. El costo mensual depende del historial. Un servidor chico para 30 a 80 targets y retención moderada puede ir de USD 35 a USD 90; con dólar oficial vendedor a ARS 1535, queda entre ARS 53.725 y ARS 138.150. El rango incluye servidor y almacenamiento externo básico, y deja afuera horas de parametrización, guardias y limpieza de métricas viejas. UMSA puede intervenir después de que el equipo define qué señales importan. La implementación útil arranca con inventario de targets, etiquetas permitidas, roles de lectura, tablero mínimo y prueba de salida. La comparación se resuelve con evidencia: Prometheus alcanza para retención corta y despliegue simple; VictoriaMetrics pesa mejor cuando el historial crece y se necesita copia incremental. La documentación de vmbackup explica backups desde snapshots y destinos como S3, GCS, Azure Blob, sistemas S3 compatibles o filesystem. La documentación de vmrestore exige restaurar desde un backup hacia un storageDataPath y detener VictoriaMetrics durante el restore. Ese detalle define la prueba: backup tomado, servidor parado, datos restaurados y consulta abierta.
Dónde se rompe y cómo probarlo
El primer riesgo aparece en etiquetas sin control. La señal es que una consulta simple devuelve miles de series por cliente, usuario o ruta dinámica. La prueba carga métricas de muestra y cuenta cardinalidad por etiqueta antes de habilitar producción. El segundo riesgo vive en retención. La señal es un disco que crece cada día sin pregunta de negocio asociada. La prueba calcula muestras por segundo, bytes por muestra, targets y días; luego fuerza una alerta al 70 % de uso de disco. El tercer riesgo aparece en permisos de consulta. La señal es que un proveedor ve métricas de otra sede o detalles de base que no necesita. La prueba crea carpetas y usuarios de Grafana, abre paneles con tres roles y revisa exportación de datos. El cuarto riesgo es restaurar configuración y perder métricas. La señal es un Grafana sano con series vacías. La prueba apaga un entorno de ensayo, restaura Prometheus o VictoriaMetrics, abre el tablero y compara una ventana de dos horas. La decisión queda escrita en una frase corta: medí menos series, guardá más evidencia útil y restaurá antes de prometer retención.
