VictoriaMetrics frente a Prometheus: retención, costo y salida
Prometheus y VictoriaMetrics resuelven métricas con decisiones distintas. Guía para elegir retención, alertas, respaldo y costo en pymes.
Un año de métricas puede costar más por disco mal medido que por licencia. Prometheus 3.12.0 figura como última versión al 28 de mayo de 2026, mientras Prometheus 3.5.3 aparece como LTS; VictoriaMetrics sostiene una línea LTS v1.136.x con correcciones publicadas el 5 de junio. Esta comparación explica cuándo alcanza Prometheus local, cuándo conviene VictoriaMetrics y qué prueba debe pedir gerencia antes de guardar alertas de producción.
Dónde aparece el costo de retención
La cifra que corrige la cuenta está en la documentación de almacenamiento de Prometheus: cuando se fija un límite por tamaño, el proyecto recomienda configurar la retención como máximo en 80 a 85% del disco asignado. Esa reserva existe porque los bloques vencidos se limpian en segundo plano y la base local puede quedarse sin espacio antes de borrar lo viejo. La página de descargas de Prometheus muestra dos ritmos que conviven: 3.12.0 como última versión y 3.5.3 como LTS. La guía de ciclo de releases agrega otra cifra: cada seis semanas empieza un ciclo menor. Para una pyme, el dato operativo es simple: si nadie revisa upgrades, retención y backup, el monitor también queda sin mantenimiento. VictoriaMetrics muestra otra lectura. Su changelog lista v1.136.11 liberada el 5 de junio de 2026 dentro de una rama LTS, y su guía rápida dice que la versión single-node conserva datos por un mes por defecto y cambia ese plazo con -retentionPeriod. El gráfico qué se ve bien hasta que hay que explicar por qué faltan datos de marzo es el obstáculo real. En una clínica privada de Godoy Cruz, una alarma de disco llena puede llegar al mismo grupo donde entra el aviso del ascensor. Si todo suena igual, nadie sabe qué sistema reclama primero.
Cómo funciona por dentro
El flujo tiene seis pasos. Primero, un exporter expone métricas de servidores, PostgreSQL, routers, aplicaciones o colas. Segundo, Prometheus o vmagent consulta esos endpoints con intervalos definidos. Tercero, la base de series guarda etiquetas, muestras y tiempo. Cuarto, reglas de alerta revisan consultas y disparan estados. Quinto, Alertmanager o vmalert entrega notificaciones a correo, chat o guardia. Sexto, backup y prueba de consulta verifican que una serie histórica vuelva. Prometheus recibe métricas por scrape y guarda una TSDB local. Entrega consultas PromQL, reglas, alertas y API. Si falla el nodo, se pierde la lectura hasta restaurar datos o levantar otro servidor; su documentación advierte que el almacenamiento local no está replicado ni distribuido. También ofrece interfaces de remote write y remote read para mandar o consultar datos en otros sistemas. VictoriaMetrics single-node recibe métricas Prometheus, remote write y otros formatos. Guarda series con retención definida, expone consultas compatibles con PromQL/MetricsQL y puede trabajar con vmagent para recolección y vmalert para reglas. Si falla, el dato queda en ese nodo salvo que exista backup, réplica de almacenamiento o versión cluster. El permiso también importa. Operaciones puede mirar tableros. Infraestructura edita targets y reglas. Desarrollo lee métricas de su aplicación. Un proveedor externo recibe acceso acotado a un dashboard o a una alerta, no a todos los labels. Nadie borra datos históricos sin ticket y sin saber qué reporte se queda sin comparación.
Qué se instala o configura primero
El primer entregable verificable es un tablero con cinco señales y una prueba de alerta: CPU, disco, memoria, latencia HTTP y estado de backup. Para Prometheus, la pila mínima incluye Prometheus 3.12 o una rama LTS, node_exporter, postgres_exporter, Alertmanager y Grafana. Para VictoriaMetrics, la prueba puede usar vmsingle, vmagent, vmalert y Grafana. El costo técnico inicial puede ubicarse entre USD 35 y USD 95 mensuales, unos ARS 51.240 a ARS 139.080 al dólar oficial vendedor de $1.464, sin contar horas de configuración, dominios ni guardia. Prometheus local suele alcanzar cuando la retención es corta, los targets son pocos y el equipo acepta restaurar desde backup. VictoriaMetrics conviene cuando se pide más retención en un solo nodo, menor presión de disco o remote write desde varios Prometheus. UMSA puede entrar después de definir los objetivos: qué servicio se mide, qué métrica dispara guardia, cuánto historial se conserva y cómo se exporta el dato si cambia la herramienta. La primera semana debe terminar con una alerta real probada y pocos tableros con dueño.
Dónde se rompe y cómo probarlo
El primer riesgo es medir todo con labels sin control. La señal aparece cuando una métrica crea miles de series por usuario, ruta o identificador. La prueba lista cardinalidad, borra labels inútiles en staging y compara uso de disco. El segundo riesgo es prometer un año de retención sin disco. La señal aparece cuando el crecimiento diario supera la cuenta inicial. La prueba mide ingestión durante siete días, calcula tamaño mensual y fija retención con margen. El tercer riesgo es alertar sin ruta de respuesta. La señal aparece cuando la guardia recibe “InstanceDown” y nadie sabe qué servicio cae. La prueba dispara una alerta controlada, revisa mensaje, responsable, runbook y cierre. El cuarto riesgo es no tener salida. La señal aparece cuando una migración exige datos históricos y solo hay capturas de pantalla. La prueba exporta una consulta, restaura backup o reenvía remote write a otro destino durante un día. La decisión queda escrita en una frase verificable: cuántos días se guardan, quién recibe la alerta y qué comando prueba que el dato vuelve.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.