Victorialogs vs Loki: resultados de evaluación comparativa

L; SECAR — Tras realizar pruebas paralelas con una carga de trabajo de 500 GB/7 días, VictoriaLogs redujo las latencias de las consultas en 94%, redujo el almacenamiento en ≈ 40%, y usó menos del 50% de la CPU y la RAM que asignamos anteriormente a Loki. En este post se explica por qué cambiamos.

Antecedentes y requisitos

Truefoundry ayuda a los desarrolladores a ejecutar cargas de trabajo de aprendizaje automático multiusuario en Kubernetes.
Los desarrolladores necesitan:

• Búsqueda rápida y ad hoc
• Buena Ingestión tasa
• Rastreo vivo para depurar.
• Gastos operativos mínimos — se prefieren las implementaciones de un solo binario.
• Uso eficiente de los recursos operación en un 4 vCPU/16 GiB de RAM nodo
• Alto compresión proporción de registros almacenados
• Almacenamiento en bloque > Se prefiere S3, para reducir los gastos generales. + Latencia

Al principio, Loki nos sirvió bien, pero a medida que el volumen creció, vimos latencias de búsqueda de más de 30 s y una alta amplificación de E/S. Esto provocó una evaluación de VictoriaLogs.

¿Qué es Loki?

Loki es el sistema de agregación de registros de Grafana‑Labs que almacena los registros en fragmentos comprimidos acompañados de un índice creado a partir de etiquetas (pares clave-valor). Las consultas se expresan en LogQL y dependen en gran medida de los filtros de etiquetas seguidos del filtrado de líneas.

• Puntos fuertes: Estrecha integración con Grafana, índice económico, escalable horizontalmente.
• Limitaciones para nosotros: El índice de solo etiquetas significa costosas búsquedas de expresiones regulares de escaneo completo; E/S de alta compactación de fragmentos; sobrecarga de GC ante una ingestión alta.

¿Qué es VictoriaLogs?

Logos de Victoria es una base de datos de registro del equipo de VictoriaMetrics. Utiliza columnar Estilo LSM almacenamiento con índices por campo, búsqueda acelerada por SIMD y LogSQL similar a SQL sintaxis.

• Puntos fuertes: índice de texto completo en todos los tokens; binario único; consumo de memoria muy bajo; escaneos rápidos de caché en frío.
• Compensaciones: ecosistema más pequeño, menos integraciones integradas (canalizamos datos a través de Vector).

How Can You Prevent GenAI Costs From Spiraling at Scale?

Access Full 2026 Report

Metodología de referencia

Suite de consultas

1. Estadísticas — líneas totales de un filtro en las últimas 24 h.
2. Una aguja en un pajar — 3-4 líneas estáticas [REGISTRO ESTÁTICO ÚNICO] ID=abc123 XYZ en un espacio de nombres lleno de registros pesados durante 7 días.
3. Negativo — cadena que hace no existe (obliga a un análisis completo) durante 7 días.

🔍 Rendimiento de consultas

1. Consulta de estadísticas (recuento de registros durante 24 horas)

Propósito: Total de líneas de registro desde app="serviciofoundry-server»

2. Consulta Needle-in-Haystack (7 días, ~ 500 GB)

Propósito: Busque una línea de registro estática única en verdadera fundición espacio de nombres

3. App Restart Log Match (7 días) (consulta adicional para verificar el paso 2)

Propósito: Busca un patrón de reinicio conocido :3000 en un pequeño subconjunto de registros (dirigido a un único fragmento)
Se verificó que los conjuntos de resultados eran idénticos.

4. Coincidencia en el registro de inexistencia (7 días)

Propósito: busca un registro inexistente, lo que desencadena una búsqueda de datos completa
Se verificó que los conjuntos de resultados eran idénticos.

Con datos de procesamiento de 500 GB, Loki se comportó de manera extraña. Los recursos se agotaron y la respuesta a la consulta se detuvo.

Loki vs VictoriaLogs: resultados de un vistazo

Nuestra evaluación se centró en tres dimensiones que son importantes para los ingenieros de plataformas en el día a día:

1. ¿Qué tan rápido podemos obtener respuestas?
2. ¿Cuántos recursos cuesta esa velocidad?
3. ¿Qué tan estable es la experiencia bajo carga real?

Rendimiento de consultas

‍

¿Por qué la brecha? VictoriaLogs mantiene un índice por token, por lo que incluso los escaneos similares a los de las expresiones regulares son asistidos por índices. Loki, por el contrario, filtra línea por línea después de una consulta de etiqueta, lo que se convierte en un escaneo de fuerza bruta cuando el conjunto de etiquetas es amplio.

🌪️ · Rendimiento de ingestión

También hicimos pruebas de estrés para la ingestión con 120 réplicas de nuestros azotar generador.
Los resultados fueron reveladores:

Loki:

Loki alcanza un máximo de 3 a 4 vCPU, se acerca a su límite de 8 GiB y muestra una aceleración bajo la misma carga de trabajo

Logos de Victoria:

👉 Conclusión clave: VictoriaLogs entregado Velocidad de ingestión 3 veces mayor mientras consume 72% menos de CPU y 87% menos de memoria comparado con Loki.

VictoriaLogs se mantiene cómodamente por debajo de sus límites de 4 vCPU y 8 GiB incluso durante las ráfagas de ingestión

2 · Huella de recursos (retención de 7 días)

Loki

Memoria utilizada: uso constante de 6 a 7 GB de RAM
Pico de CPU: 3 vCPU

‍

Logos de Victoria

Memoria utilizada: 800 MB - 900 MB
Uso máximo de CPU: 1.1 vCPU

3 · Carga en el mundo real (2 minutos de funcionamiento de Locust con 10 usuarios y 2 Rampup)

Las consultas eran similares, con límites aleatorios y rangos de tiempo aleatorios, para garantizar ráfagas de caché.

Registros Victoria

Loki

📌 A pesar del manejo RPS un 36% más alto, VictoriaLogs mostró latencias de p 95% y de cola más bajas, lo que demuestra que su modelo de indexación se mantiene bajo presión con 3,6x Más rápido Hasta 99% de archivo

‍Esta prueba reforzó nuestra decisión: VictoriaLogs no solo es más rápida en teoría, sino que se adapta mejor bajo presión a cargas de trabajo similares a las de producción.

TL; DR de los números

• 70—94% más rápida a través de patrones de búsqueda comunes.
• ≈ 40% más pequeño en un disco con la misma ventana de retención.
• La mitad del cómputo, liberando una vCPU completa y entre 1 y 2 GiB de RAM en nuestros nodos más pequeños.

En resumen: para un caso de uso con mucho registro y centrado en las búsquedas, VictoriaLogs nos permite responder a las preguntas en segundos en lugar de minutos y, al mismo tiempo, reducir los costos de infraestructura.

Hallazgos clave

1. El índice de texto completo es importante — El índice por token de VictoriaLogs elimina el filtrado de líneas por fuerza bruta.
2. Diseño de almacenamiento — columnar + LSM reduce considerablemente el tamaño del disco y las búsquedas de disco.
3. Eficiencia de memoria — liberamos aproximadamente 2 GiB de RAM por nodo, lo que permitió una programación más densa.
4. Simplicidad operativa — ambos son binarios simples, pero se necesitan VictoriaLogs cero afinación personalizada para alcanzar estos números.

Conclusión

Para los perfiles de carga de trabajo con una gran cantidad de búsquedas de texto ad hoc, VictoriaLogs proporcionó orden de magnitud consultas más rápidas y ahorro de costes de material. Loki sigue siendo una opción excelente cuando predominan la estrecha integración de Grafana y las consultas que dan prioridad a las etiquetas, pero VictoriaLogs es ahora nuestra opción predeterminada para clústeres centrados en desarrolladores con un alto nivel de consumo.

Referencias

• Documentación de Loki
• Documentación de VictoriaLogs
• Documentación de Promtail
• Documentación vectorial
• Documentación sobre aleaciones
• Configurador Grafana Alloy

Preguntas frecuentes

¿Cuál es la diferencia clave entre Victorialogs y Loki?

La diferencia clave entre victorialogs y loki es la indexación avanzada por token y el almacenamiento en columnas de Victorialogs. Esto permite un rendimiento de consultas mucho más rápido y un uso de recursos significativamente menor en comparación con la indexación de solo etiquetas de Loki, que a menudo resulta en búsquedas de escaneo completo más lentas y en una mayor sobrecarga operativa para la administración de registros.

¿VictoriaLogs es más rápido que Loki?

Sí, en nuestra rigurosa evaluación comparativa, VictoriaLogs demostró una velocidad superior en comparación con Loki. En las comparaciones entre Victorialogs y Loki, VictoriaLogs redujo las latencias de las consultas en un 94% y logró tiempos de búsqueda 12 veces más rápidos para consultas complejas. También ofrecía un rendimiento de ingestión 3 veces mayor, lo que lo hacía considerablemente más eficiente.

¿Cuál es el puerto predeterminado para VictoriaLogs?

Al evaluar victorialogs frente a loki, es útil conocer los detalles de configuración. Por lo general, VictoriaLogs usa el puerto 8428 para su API HTTP predeterminada y para raspar los puntos finales. Este puerto permite el acceso a la base de datos de registro y la interacción con ella. Si bien nuestro blog se centra en el rendimiento, comprender los aspectos básicos de la implementación, como el puerto predeterminado, es crucial para la configuración del sistema.

¿Cuáles son los resultados comparativos de VictoriaLogs frente a Loki?

En los puntos de referencia que comparan victorialogs con loki, VictoriaLogs ofreció un rendimiento superior. Logró una reducción del 94% en las latencias de las consultas, redujo el uso del almacenamiento en aproximadamente un 40% y consumió menos del 50% de la CPU y la RAM asignadas. VictoriaLogs también mostró un rendimiento de ingestión 3 veces mayor, lo que la hizo altamente eficiente.

¿Qué es mejor: VictoriaLogs o Loki?

En nuestro punto de referencia de victorialogs contra loki, VictoriaLogs demostró ser superior. Redujo la latencia de las consultas en un 94%, redujo el almacenamiento en un 40% y utilizó más de un 50% menos de CPU/RAM. La empresa estadounidense TrueFoundry eligió VictoriaLogs por su rendimiento y eficiencia mejorados en la gestión de las cargas de trabajo de aprendizaje automático.