Victorialogs contre Loki - Résultats de l'analyse comparative

TL ; SEC — Après des tests côte à côte sur une charge de travail de 500 Go/7 jours, VictoriaLogs a réduit les latences des requêtes en 94 %, espace de stockage réduit de ≈ 40 %, et a utilisé < 50 % du processeur et de la RAM que nous avions précédemment alloués à Loki. Ce post explique pourquoi nous avons échangé.

Contexte et exigences

Truefoundry aide les développeurs à exécuter des charges de travail ML mutualisées sur Kubernetes.
Les développeurs ont besoin de :

• Recherche rapide et ad hoc
• Bien Ingestion taux
• Live Tailing pour le débogage.
• Frais d'exploitation minimaux — les déploiements à binaire unique sont préférés.
• Utilisation efficace des ressources opération sur un 4 processeurs virtuels/16 Go de RAM nœud
• Haut compression ratio sur les journaux stockés
• Stockage par blocs > S3 de préférence, pour réduire les frais généraux. + Latence

Loki nous a bien servis au début, mais à mesure que le volume augmentait, nous avons constaté des latences de recherche supérieures à 30 s et une amplification d'E/S élevée. Cela a déclenché une évaluation de VictoriaLogs.

Qu'est-ce que Loki ?

Loki est le système d'agrégation de journaux de Grafana‑Labs qui stocke les journaux dans des blocs compressés accompagnés d'un index construit à partir de étiquettes (paires clé-valeur). Les requêtes sont exprimées en LogQL et s'appuient largement sur des filtres d'étiquettes suivis d'un filtrage en ligne.

• Points forts : intégration étroite de Grafana, indice bon marché, évolutif horizontalement.
• Limites pour nous : Un index basé sur des étiquettes uniquement signifie des recherches régulières coûteuses à analyse complète ; des E/S à compactage de morceaux élevé ; une surcharge Go GC en cas d'ingestion élevée.

Qu'est-ce que VictoriaLogs ?

Logs de Victoria est une base de données de journaux créée par l'équipe VictoriaMetrics. Il utilise des colonnes Style LSM stockage avec index par champ, recherche accélérée par SIMD et LogSQL de type SQL syntaxe.

• Points forts : index en texte intégral sur tous les jetons ; binaire unique ; très faible empreinte mémoire ; analyses rapides du cache à froid.
• Compromis : écosystème plus petit, moins d'intégrations intégrées (nous acheminons les données via Vecteur).

How Can You Prevent GenAI Costs From Spiraling at Scale?

Access Full 2026 Report

Méthodologie de référence

Suite de requêtes

1. Statistiques — nombre total de lignes pour un filtre au cours des dernières 24 heures.
2. Une aiguille dans une botte de foin — 3-4 lignes statiques [JOURNAL STATIQUE UNIQUE] ID=ABC123 XYZ dans un espace de noms rempli de journaux lourds pendant 7 jours.
3. Négatif — chaîne qui fait pas exister (force le scan complet) pendant 7 jours.

🔍 Performances des requêtes

1. Requête de statistiques (nombre de journaux sur 24 heures)

Finalité: Nombre total de lignes de journal provenant de app="servicefoundry-server »

2. Requête Needle-in-Haystack (7 jours, ~500 Go)

Finalité: recherchez une ligne de journal statique unique dans véritable fonderie espace de noms

3. App Restart Log Match (7 jours) (requête supplémentaire pour vérifier l'étape 2)

Finalité: Recherche d'un modèle de redémarrage connu : 3 000 dans un petit sous-ensemble de journaux (ciblant un seul fragment)
L'identité des ensembles de résultats a été vérifiée.

4. Correspondance du journal d'inexistence (7 jours)

Finalité: recherche d'un journal inexistant, déclenchant une recherche complète des données
L'identité des ensembles de résultats a été vérifiée.

Sur 500 Go de données de traitement, Loki s'est comporté étrangement. Les ressources ont été bloquées et la réponse à la requête s'est arrêtée.

Loki contre VictoriaLogs : les résultats en un coup d'œil

Notre évaluation s'est concentrée sur trois dimensions qui sont importantes au quotidien pour les ingénieurs de plateformes :

1. En combien de temps pouvons-nous obtenir des réponses ?
2. Combien de ressources coûte cette vitesse ?
3. Dans quelle mesure l'expérience est-elle stable en cas de charge réelle ?

Performance des requêtes

‍

Pourquoi cet écart ? VictoriaLogs gère un index par jeton, de sorte que même les scans de type regex sont assistés par indexation. Loki, en revanche, filtre ligne par ligne après une requête d'étiquette, qui se transforme en un scan par force brute lorsque le jeu d'étiquettes est large.

🌪️ · Performance d'ingestion

Nous avons également testé l'ingestion sous contrainte avec 120 répliques de notre fougette générateur.
Les résultats ont été révélateurs :

Loki:

Loki passe à 3 à 4 processeurs virtuels, approche de sa limite de 8 Go et montre des signes de ralentissement pour la même charge de travail

Logs Victoria :

👉 Principaux plats à emporter: VictoriaLogs livré Vitesse d'ingestion 3 fois plus élevée tout en consommant 72 % de processeur en moins et 87 % de mémoire en moins comparé à Loki.

VictoriaLogs reste confortablement en dessous de ses limites de 4 vCPU/8 GiB, même en cas de rafale d'ingestion

2 · Empreinte des ressources (conservation pendant 7 jours)

Loki

Mémoire utilisée : utilisation constante de 6 à 7 Go de RAM
Puissance maximale du processeur : 3 vCPU

‍

Logs de Victoria

Mémoire utilisée : 800 Mo - 900 Mo
Utilisation maximale du processeur : 1.1 vCPU

3 · Real‑World Load (course Locust de 2 minutes avec 10 utilisateurs et 2 rampes)

Les requêtes étaient similaires, avec des limites aléatoires et une plage de temps aléatoire, pour garantir des rafales de cache.

Victoria Logs

Loki

📌 Malgré la manipulation RPS 36 % plus élevé, VictoriaLogs a enregistré un p inférieur de 95 % et des latences inférieures, ce qui prouve que son modèle d'indexation résiste à la pression avec 3,6 fois plus rapide Fichier Pp 99%

‍Ce test a renforcé notre décision : VictoriaLogs n'est pas seulement plus rapide en théorie, il s'adapte mieux au stress des charges de travail similaires à celles liées à la production.

TL ; DR des chiffres

• 70 à 94 % plus rapide selon les modèles de recherche courants.
• ≈ 40 % plus petit sur disque avec la même fenêtre de rétention.
• La moitié du calcul, libérant ainsi un processeur virtuel complet et environ 1 à 2 Go de RAM sur nos plus petits nœuds.

Conclusion : pour un cas d'utilisation centré sur la recherche et riche en journaux, VictoriaLogs nous permet de répondre aux questions en quelques secondes au lieu de quelques minutes tout en réduisant les coûts d'infrastructure.

Principales conclusions

1. L'index en texte intégral est important — L'index par jeton de VictoriaLogs élimine le filtrage des lignes par force brute.
2. Disposition du rangement — columnar + LSM réduit considérablement la taille du disque et les recherches sur le disque.
3. Efficacité de la mémoire — nous avons libéré environ 2 Go de RAM par nœud, ce qui a permis une planification plus dense.
4. Simplicité opérationnelle — les deux sont à binaire unique, mais VictoriaLogs est nécessaire zéro réglage personnalisé pour atteindre ces chiffres.

Conclusion

Pour les profils de charge de travail nécessitant une recherche de texte ad hoc, VictoriaLogs a fourni ordre de grandeur des requêtes plus rapides et des économies de coûts matériels. Loki reste un excellent choix lorsque l'intégration étroite de Grafana et les requêtes privilégiant les étiquettes dominent, mais VictoriaLogs est désormais notre solution par défaut pour les clusters centrés sur les développeurs à forte ingestion.

Références

• Documentation sur Loki
• Documentation sur VictoriaLogs
• Documentation sur Promotail
• Documentation vectorielle
• Documentation sur les alliages
• Configurateur en alliage Grafana

Questions fréquemment posées

Quelle est la principale différence entre Victorialogs et Loki ?

La principale différence entre Victorialogs et Loki réside dans l'indexation avancée par jeton et le stockage en colonnes de VictoriaLogs. Cela permet des performances de requête beaucoup plus rapides et une utilisation des ressources nettement inférieure par rapport à l'indexation basée sur les étiquettes de Loki, ce qui entraîne souvent un ralentissement des recherches complètes et une augmentation des frais opérationnels liés à la gestion des journaux.

VictoriaLogs est-il plus rapide que Loki ?

Oui, lors de notre analyse comparative rigoureuse, VictoriaLogs a démontré une vitesse supérieure à celle de Loki. Pour les comparaisons entre Victorialogs et Loki, VictoriaLogs a réduit les latences des requêtes de 94 % et a obtenu des temps de recherche 12 fois plus rapides pour les requêtes complexes. Il a également obtenu des performances d'ingestion 3 fois plus élevées, ce qui le rend nettement plus efficace.

Quel est le port par défaut pour VictoriaLogs ?

Lorsque vous évaluez Victorialogs par rapport à Loki, il est utile de connaître les détails de configuration. VictoriaLogs utilise généralement le port 8428 pour son API HTTP par défaut et ses points de terminaison de scraping. Ce port permet d'accéder à la base de données des journaux et d'interagir avec celle-ci. Bien que notre blog soit axé sur les performances, il est essentiel de comprendre les principes de base du déploiement, tels que le port par défaut, pour la configuration du système.

Quels sont les résultats de référence entre VictoriaLogs et Loki ?

Dans les benchmarks comparant Victorialogs à Loki, VictoriaLogs a enregistré des performances supérieures. Il a permis de réduire de 94 % les latences des requêtes, de réduire l'utilisation du stockage d'environ 40 % et de consommer moins de 50 % du processeur et de la RAM alloués. VictoriaLogs a également présenté un débit d'ingestion 3 fois plus élevé, ce qui le rend très efficace.

Quel est le meilleur : VictoriaLogs ou Loki ?

Lors de notre comparaison entre Victorialogs et Loki, VictoriaLogs s'est révélé supérieur. Il a réduit les latences des requêtes de 94 %, réduit le stockage de 40 % et a utilisé plus de 50 % de CPU/RAM en moins. TrueFoundry aux États-Unis a choisi VictoriaLogs pour ses performances et son efficacité accrues en matière de gestion des charges de travail de machine learning.