Grafana Loki ou Elasticsearch : quatre fois moins d’espace

Dans l’essai de Platform Monkey, un même corpus synthétique de 300 000 lignes, soit 40,9 Mo de texte brut, occupe 10,1 Mo dans Grafana Loki — environ quatre fois moins que les lignes d’origine — et 52,6 Mo dans Elasticsearch logsdb ; deux configurations Elasticsearch logsdb_columnar occupent 7,9 et 32,4 Mo selon le mapping du message, tandis qu’une recherche de phrase prend 280 ms avec Loki et 35 ms avec Elasticsearch logsdb. Ces résultats décrivent des configurations précises sur un seul nœud, pas une économie garantie pour tout déploiement.

Pour des journaux généralement consultés par service et par période, Loki tire parti de son index réduit et de ses lignes compressées. Si les enquêtes exigent souvent une recherche textuelle libre dans des messages anciens ou des filtres sur de nombreux champs, Elasticsearch peut justifier davantage d’espace : l’index construit à l’ingestion évite une partie du parcours des lignes à la lecture.

Ce que les mesures de disque permettent de comparer

Le corpus de l’essai imite des journaux Kubernetes et contient des messages répétitifs. Les auteurs ont utilisé Loki avec un index TSDB et un stockage objet simulé sur le système de fichiers, face à des configurations Elasticsearch sur le même hôte. Ils ont relevé la place de Loki sur disque avec l’outil système du et celle d’Elasticsearch avec son API de statistiques d’index : les données ingérées sont identiques, mais les instruments de mesure diffèrent.

La comparaison porte sur le stockage des données dans cet essai, sans répliques ni architecture distribuée. Elle ne chiffre ni les ressources de calcul nécessaires pour servir des recherches simultanées, ni les requêtes facturées par un service de stockage objet. La répétition des messages et le faible nombre de flux favorisent également la compression ; des journaux contenant davantage de valeurs uniques peuvent modifier le rapport entre les tailles.

Pourquoi l’index réduit déplace le coût vers la recherche

La documentation d’architecture de Loki distingue un index qui localise les journaux par ensemble de labels et des chunks qui contiennent les lignes d’un flux sur une période donnée. Ces éléments peuvent résider dans un stockage objet. Loki évite ainsi de construire un index de recherche pour les mots de chaque message ; une requête sélectionne d’abord les flux et la période, puis examine les lignes des chunks retenus.

Elasticsearch conserve une autre capacité de recherche en indexant les champs définis par le mapping. Ses data streams pour données continues donnent un nom commun à plusieurs indices sous-jacents ; une politique de cycle de vie peut déplacer les indices anciens vers un matériel moins coûteux ou les supprimer. L’espace occupé dépend donc aussi des champs indexés, du mode de stockage, des répliques et de la façon dont les données vieillissent.

Le coût n’arrive pas au même moment. Loki écrit des lignes compactes et fournit rapidement une sélection par labels, mais une recherche peu ciblée doit lire davantage de chunks. Elasticsearch consacre de l’espace à des structures qui rendent certaines recherches plus directes. Une taille de disque seule ne décrit ni la latence d’une enquête ni la charge qu’elle impose au système.

Quelle architecture selon la requête ?

Les temps de recherche de l’essai illustrent l’avantage d’un champ textuel indexé pour retrouver une expression, sans constituer une prévision de latence. La fenêtre temporelle, les flux sélectionnés, le cache et les requêtes concurrentes changent la quantité de données à parcourir. Les opérations comparées méritent aussi d’être distinguées : le filtre de ligne de Loki cherche une chaîne dans les messages, tandis que la recherche de phrase d’Elasticsearch travaille sur un champ analysé.

Service connu, période courte : un label de service et une plage horaire restreignent les flux à lire. Loki exploite alors directement la sélection prévue par son index, ce qui correspond à son compromis de stockage.
Expression dans une longue période : si le service d’origine est inconnu, Loki doit examiner davantage de lignes. Un champ message indexé pour le texte intégral donne à Elasticsearch un avantage pour ce type d’enquête fréquente.
Filtres sur plusieurs champs : Elasticsearch est adapté aux investigations qui croisent régulièrement message, identifiant, statut et autres attributs, à condition que leurs mappings servent effectivement les requêtes attendues. Dans Loki, ces valeurs peuvent rester recherchables sans devenir des labels indexés, mais le filtrage intervient après la sélection des flux.
Archives rarement interrogées : conserver des chunks compacts peut être intéressant lorsque l’attente d’une recherche étendue reste acceptable. Si les mêmes archives alimentent chaque jour des enquêtes interactives, le calcul et les lectures nécessaires reprennent du poids dans le choix.

Cette matrice sépare deux dépenses que le volume ingéré confond facilement : garder les journaux et répondre aux questions posées sur eux. À durée de rétention égale, une économie sur les octets conservés peut s’accompagner d’un travail de lecture plus important lorsque la requête arrive tard et couvre de nombreux flux.

La cardinalité peut effacer l’avantage de Loki

Les recommandations de Grafana sur les labels privilégient les valeurs peu nombreuses qui décrivent la provenance des journaux et orientent les valeurs très variables vers les métadonnées structurées. Chaque combinaison de labels crée un flux distinct. Transformer un identifiant de requête ou d’instance éphémère en label multiplie les flux, agrandit l’index et produit de petits chunks moins efficaces à compresser.

Cette discipline a une conséquence pour les enquêtes. Un service ou un environnement stable peut servir de point d’entrée efficace ; un identifiant unique conservé hors de l’index reste accessible, mais sa recherche dépend de la période et des flux que l’on peut délimiter. Si l’investigation commence habituellement par cet identifiant sans indication de service, l’espace consacré à l’indexation d’un champ dans Elasticsearch peut avoir une valeur opérationnelle réelle.

Le mode columnar change la comparaison

Elastic présente les modes columnar introduits avec Elasticsearch 9.5.0 comme une préversion technique : leurs champs ne sont généralement plus indexés par défaut, tandis qu’un champ explicitement déclaré en text conserve un index pour la recherche textuelle. Ce statut et ce choix de mapping comptent autant que le résultat de stockage. Le profil columnar le plus compact de l’essai traitait le message comme une valeur keyword ; le profil permettant la recherche de phrase sur ce champ occupait davantage d’espace.

Il serait donc trompeur d’opposer la plus petite taille columnar à une configuration Loki tout en supposant les mêmes possibilités de recherche. La question utile est de savoir quels champs doivent répondre rapidement à des requêtes textuelles, et quels champs servent surtout à filtrer ou agréger. Elasticsearch permet de répartir ce coût par mapping ; Loki le répartit principalement entre labels indexés et lecture des lignes.

Ce que change une rétention longue

Une longue conservation amplifie l’intérêt de lignes compactes lorsque les recherches restent ciblées. Elle amplifie aussi le coût d’une recherche large qui parcourt des périodes anciennes. Côté Elasticsearch, les data streams et leurs politiques de cycle de vie permettent de traiter différemment les indices récents et anciens ; la taille mesurée pour un indice local ne se transforme donc pas directement en facture pour toute la rétention.

Le choix se précise selon l’usage : Loki convient particulièrement à des flux dont les labels restent maîtrisés et que l’on interroge par provenance et par date. Elasticsearch répond mieux à des enquêtes textuelles transversales et répétées, si les champs nécessaires sont indexés. Le mode columnar ajoute une possibilité de réduire l’espace dans Elasticsearch, avec une décision explicite sur les champs dont on veut préserver la recherche de phrases.