VictoriaMetrics frente a Prometheus: retención y costo
Guía técnica para decidir retención de métricas con VictoriaMetrics: ingreso de datos, permisos, alertas, backup probado y prueba de salida.
Una métrica guardada 18 meses vale poco si nadie puede decir quién cambió la alerta que la usa. En pymes con servidores propios, Prometheus suele empezar simple y queda corto cuando la retención crece, los discos rotan y gerencia pide históricos. VictoriaMetrics 1.144.0, publicado el 25 de mayo, recibe métricas Prometheus y guarda series temporales. Esta guía explica dato, permiso, costo y salida.
Dónde aparece el costo de retener métricas
El problema operativo aparece cuando una alerta del mes pasado ya desapareció o ocupa tanto disco que obliga a borrar histórico sin criterio. La cifra que corrige el hábito viene del release: VictoriaMetrics 1.144.0 fue publicado el 25 de mayo de 2026, lo qué permite fijar versión y fecha antes de cambiar la retención.
Una métrica sin responsable termina siendo una captura de pantalla.
El dato global conecta esta decisión chica con una práctica amplia. GitHub Octoverse 2025 informó más de 180 millones de desarrolladores y 630 millones de repositorios. Una clínica privada de Godoy Cruz mide menos sistemas, pero necesita el mismo orden: versión, permisos, historial y reconstrucción.
Qué decide VictoriaMetrics cuando entra al flujo
El antagonista es el servidor de monitoreo que crece por acumulación y nadie quiere apagar. En la sala técnica de una clínica, un patch panel con etiquetas de colores nuevas y cables viejos muestra el problema: los datos llegan, aunque el criterio de retención quedó escrito en una instalación inicial.
La documentación de Prometheus sobre almacenamiento explica el comportamiento local de series temporales y bloques. La configuración de scrape en Prometheus define qué se mide y cada cuánto. VictoriaMetrics single-server puede recibir datos por protocolos compatibles y fijar retención. Sus conceptos principales ordenan métricas, etiquetas y consultas.
La decisión técnica se vuelve operativa en tres lugares: disco, consulta y alerta. Disco define cuántos meses se guardan. Consulta define quién puede ver históricos. Alerta define quién recibe avisos y con qué umbral. Si esas tres decisiones quedan en archivos separados, el costo aparece cuando la gerencia pide comparar guardias, turnos o caídas.
Cómo funciona por dentro
El flujo mínimo tiene siete pasos. Primero, servidores, aplicaciones y equipos publican métricas por exporters. Segundo, Prometheus o vmagent leen endpoints con intervalos definidos. Tercero, VictoriaMetrics recibe series, etiquetas y marcas de tiempo. Cuarto, el almacenamiento guarda bloques con retención configurada. Quinto, Grafana consulta métricas por rol y tablero. Sexto, Alertmanager o vmalert evalúa reglas y envía avisos. Séptimo, el backup copia configuración, reglas, tableros y procedimiento de restauración.
VictoriaMetrics recibe muestras de series temporales y entrega consultas rápidas sobre históricos. Prometheus recibe targets y entrega scrapes, reglas y alertas. Grafana recibe consultas y entrega paneles para soporte, sistemas o dirección. PostgreSQL puede guardar auditoría de cambios de reglas, aprobadores y ventanas de mantenimiento. Si falla el colector, dejan de entrar métricas. Si falla el almacenamiento, se pierde histórico. Si falla la alerta, el incidente queda visible tarde.
El permiso debe separar escritura, edición de reglas y lectura. Sistemas administra exporters y retención. Soporte lee paneles operativos. Dirección ve disponibilidad y tiempos de respuesta. Un cambio de umbral exige autor, motivo y fecha, porque una alerta silenciada también es una decisión.
Qué se instala o configura primero
La pila inicial usa VictoriaMetrics 1.144.0, Prometheus o vmagent, Grafana, Alertmanager o vmalert, exporters, repositorio de configuración, PostgreSQL 18 para auditoría liviana, backup diario y restauración mensual. El piloto cuesta entre USD 700 y USD 2.100, entre ARS 1,00 y ARS 3,00 millones al dólar vendedor oficial de $1.430 informado por Bluelytics. Incluye diez targets, tres tableros, cinco alertas y prueba de salida.
El plazo va de una a tres semanas. UMSA suele pedir un entregable verificable: métrica de CPU, métrica de aplicación, regla de alerta, usuario lector, usuario editor, histórico de 30 días, exportación de tablero y restauración de configuración en otro equipo. El costo no incluye compra de hardware, limpieza de etiquetas heredadas ni guardia de incidentes.
La primera prueba apaga un servicio de prueba durante dos minutos. El colector debe registrar caída, alerta y recuperación. La segunda prueba cambia una etiqueta y revisa que el tablero no duplique series. La tercera prueba restaura reglas y tablero en otro host; la consulta debe devolver la misma ventana y el mismo umbral.
Dónde se rompe y cómo probarlo
Primer riesgo: cardinalidad alta por etiquetas sueltas. La señal aparece cuando una métrica crea miles de series por usuario, URL o ticket. La prueba lista series nuevas antes de habilitar un exporter. Segundo riesgo: retención elegida por espacio disponible y no por necesidad de negocio. La señal es un histórico cortado antes del cierre mensual. La prueba consulta una ventana definida por gerencia.
Tercer riesgo: alertas sin dueño. La señal aparece cuando un aviso llega a un canal general y nadie toma el caso. La prueba obliga a asignar responsable y horario. Cuarto riesgo: backup que copia paneles y pierde reglas. La señal es una restauración con gráficos visibles y alertas mudas. La prueba recupera configuración, reglas y consulta en otro host.
El monitoreo vale cuando alguien puede mostrar qué pasó, desde cuándo, con qué regla y quién recibió el aviso.