VictoriaMetrics frente a Prometheus: métricas y límite
Guía técnica para decidir entre Prometheus y VictoriaMetrics v1.151.0: retención, consultas, alertas, permisos, backup y costo mensual en pymes.
El tablero se cae cuando una consulta de 90 días pelea con la retención real del servidor. Prometheus guarda series temporales y suele arrancar con 15 días por defecto; VictoriaMetrics v1.151.0 llegó el 31 de agosto con cambios de seguridad y alertas de apagado sucio. La decisión útil es qué métrica guardar, cuánto tiempo y quién puede leerla.
Dónde aparece la métrica que falta
El problema operativo aparece en soporte, facturación o infraestructura. Un gerente de cooperativa eléctrica con internet rural quiere comparar cortes, latencia y reclamos de tres meses; el equipo sólo tiene dos semanas de datos o una consulta tarda demasiado. El antagonista es una retención elegida por costumbre, anotada en un archivo de configuración y olvidada hasta el primer reclamo. Quince días pueden borrar una discusión comercial. La documentación de conceptos de VictoriaMetrics separa muestras, etiquetas, series y consultas. La guía de servidor único explica ingestión, almacenamiento local y endpoints compatibles con Prometheus. La encuesta 2025 de Stack Overflow muestra 45,52% de encuestados usando de una a cinco herramientas de software en su rol primario. En una pyme, esa mezcla suele dejar métricas repartidas entre routers, planillas, paneles y correos. Prometheus sigue siendo una base sólida para recolectar y consultar métricas con PromQL. VictoriaMetrics entra cuando el volumen, la retención o la eficiencia de lectura piden otra pieza. La comparación se vuelve concreta cuando el equipo mide cardinalidad, tamaño en disco, tiempo de consulta y forma de restaurar datos.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. Primero, cada servicio expone métricas: router, API, base, backup o gateway. Segundo, Prometheus o vmagent raspa esos endpoints y agrega etiquetas como sede, servicio y entorno. Tercero, los datos se guardan localmente o se escriben en VictoriaMetrics. Cuarto, las reglas de alerta consultan latencia, caída, espacio en disco y errores. Quinto, un tablero muestra vistas para operación y gerencia. Sexto, el backup conserva configuración, reglas, dashboards y datos según retención definida. La página de vmagent describe al componente que raspa métricas y puede hacer remote write. Prometheus documenta su lenguaje de consulta para seleccionar series por nombre, etiquetas y rango temporal. Si se usa Grafana, el permiso de lectura debe quedar separado por carpeta, organización o proxy; una persona de atención puede ver cortes por zona, mientras infraestructura administra reglas y destinos. El release v1.151.0 corrigió un caso de Basic Auth que podía omitirse en ciertas rutas con sufijos y agregó una métrica de apagado no limpio. También corrigió un bucle de CPU en un endpoint OpenTelemetry Firehose ante un registro malformado. Esos cambios importan en producción porque la métrica deja de ser sólo observación: pasa a ser evidencia de que el monitoreo sigue protegido. La decisión técnica también incluye escritura. vmagent puede enviar a VictoriaMetrics y mantener Prometheus para reglas locales; otra instalación puede dejar Prometheus como único recolector. La prueba separa ambos modelos con el mismo tablero y mide tiempo de consulta, disco usado y pérdida tolerada.
Qué se instala o configura primero
En un proyecto UMSA, el primer entregable sería un inventario de métricas: nombre, dueño, servicio, etiqueta permitida, retención, alerta y tablero. Después se levanta un piloto con cinco servicios reales: gateway de internet, base SQL, aplicación, backup y servidor. La prueba termina cuando un corte simulado dispara alerta, queda visible en el tablero y una restauración recupera reglas y dashboards. La pila mínima puede usar Prometheus, vmagent, VictoriaMetrics single-server, Grafana, backup diario y monitoreo del propio monitoreo. Para una cooperativa chica, servidor y almacenamiento pueden ubicarse entre USD 40 y USD 80 mensuales, entre $61.200 y $122.400 al dólar oficial vendedor de $1530. La implementación inicial, con scraping, reglas, tableros, roles y prueba de salida, puede ir de USD 1.300 a USD 2.300, entre $1.989.000 y $3.519.000. Ese rango no incluye compra de sensores, equipamiento de red ni mesa de ayuda externa.
Dónde se rompe y cómo probarlo
El primer riesgo es la cardinalidad sin control. La señal aparece cuando una etiqueta cambia con cada request o cliente y el disco crece sin relación con usuarios reales. La prueba carga métricas de ensayo, mide series por etiqueta y rechaza campos volátiles antes de producción. El segundo riesgo está en alertas que nadie atiende. La señal aparece cuando un aviso llega de madrugada y queda sin acuse. La prueba dispara caída, latencia alta y disco lleno; cada alerta debe tener destino, responsable y cierre escrito. El tercer riesgo es confundir retención con backup. La señal aparece cuando el tablero muestra histórico, pero nadie puede restaurar reglas o dashboards. La prueba borra un tablero de ensayo, restaura configuración y compara una consulta de 30 días con conteo esperado. La decisión queda en una tabla chica: Prometheus para empezar rápido, VictoriaMetrics cuando la retención, el volumen o la lectura lo justifican. La pregunta incómoda llega antes de comprar más disco: ¿qué métrica necesita sobrevivir al reclamo y quién firma que volvió?
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.