Loki vs Elasticsearch : quelle solution de logs pour Kubernetes

Le choix Loki vs Elasticsearch logs Kubernetes représente une décision architecturale majeure pour les équipes opérant des clusters en production. Ces deux solutions dominent le marché de la centralisation des logs, mais avec des philosophies radicalement différentes. Selon le CNCF Annual Survey 2025, 82% des utilisateurs de conteneurs exécutent Kubernetes en production, rendant ce choix critique.

TL;DR : Loki excelle pour les environnements cloud-native avec des contraintes budgétaires (stockage objet, pas d'indexation full-text). Elasticsearch convient aux besoins d'analyse avancée et de recherche full-text sur gros volumes. Le choix dépend du ratio coût/fonctionnalités recherché.

Les compétences en observabilité sont couvertes dans la formation LFS458 Administration Kubernetes.

Pourquoi la centralisation des logs Kubernetes est critique

Un cluster Kubernetes génère des milliers de lignes de logs par minute. Sans centralisation, le debugging devient impossible.

Loki est une solution développée par Grafana Labs, conçue spécifiquement pour Kubernetes. Elle n'indexe que les métadonnées (labels) et stocke les logs bruts compressés.

Elasticsearch est un moteur de recherche distribué indexant l'intégralité du contenu. Combiné à Kibana et Filebeat/Fluentd, il forme la stack ELK/EFK.

À retenir : Le choix Loki vs Elasticsearch logs Kubernetes impacte directement vos coûts de stockage, votre temps de diagnostic, et les compétences requises de vos équipes.

Pour une vue d'ensemble de l'observabilité, consultez Comprendre l'observabilité Kubernetes : métriques, logs, traces.

Architecture technique : Loki vs Elasticsearch logs Kubernetes

Architecture Loki

Loki adopte une approche minimaliste optimisée pour le cloud.

# Installation Loki avec Helm
helm repo add grafana https://grafana.github.io/helm-charts
helm install loki grafana/loki-stack \
  --set promtail.enabled=true \
  --set grafana.enabled=true

Composants clés :

• Promtail : agent de collecte déployé en DaemonSet
• Loki : service de stockage et requêtage
• Grafana : interface de visualisation

Loki stocke les logs dans un stockage objet (S3, GCS, MinIO) avec compression gzip. Seuls les labels Kubernetes (namespace, pod, container) sont indexés.

Architecture Elasticsearch

Elasticsearch requiert une infrastructure plus conséquente.

# Déploiement ECK (Elastic Cloud on Kubernetes)
apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: logs-cluster
spec:
  version: 8.12.0
  nodeSets:
  - name: default
    count: 3
    config:
      node.store.allow_mmap: false
    volumeClaimTemplates:
    - metadata:
        name: elasticsearch-data
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 500Gi

Composants clés :

• Filebeat/Fluentd : collecteurs de logs
• Elasticsearch : stockage et indexation full-text
• Kibana : interface de visualisation et dashboards

À retenir : Elasticsearch indexe chaque mot de chaque log, permettant des recherches full-text mais consommant 10x plus de stockage.

L'architecture de monitoring Kubernetes en production détaille les patterns d'intégration.

Comparatif fonctionnel détaillé

Requêtage : LogQL vs KQL

Loki (LogQL) :

{namespace="production", app="api"} |= "error" | json | response_time > 500

Elasticsearch (KQL) :

kubernetes.namespace: "production" AND kubernetes.labels.app: "api" AND message: "error"

LogQL s'inspire de PromQL (Prometheus), facilitant l'adoption pour les équipes utilisant déjà la stack Grafana.

Pour le tracing distribué, comparez avec Jaeger vs Zipkin : comparatif du tracing distribué.

Analyse des coûts : ingénieur infrastructure Kubernetes certification CKA

Un administrateur système Kubernetes doit évaluer le TCO (Total Cost of Ownership) sur 3 ans.

Scénario : 100 Go de logs par jour

Économies Loki : 75% sur ce scénario type.

Attention : Elasticsearch justifie son coût pour les cas d'usage nécessitant :

• Recherche full-text complexe
• Analyse de sécurité (SIEM)
• Corrélation avancée multi-sources

À retenir : Pour un administrateur système Kubernetes préparant le CKA, Loki offre un ratio fonctionnalités/coût optimal pour les clusters standards.

L'aide-mémoire : commandes kubectl essentielles complète les compétences de debugging.

Cas d'usage recommandés

Choisir Loki si :

1. Budget contraint : startup ou équipe avec ressources limitées
2. Stack Grafana existante : Prometheus, Tempo, Grafana déjà déployés
3. Logs structurés : applications émettant du JSON avec labels cohérents
4. Cloud-native : infrastructure sur AWS, GCP ou Azure

# Configuration Promtail optimisée
scrape_configs:
- job_name: kubernetes-pods
  kubernetes_sd_configs:
  - role: pod
  pipeline_stages:
  - json:
      expressions:
        level: level
        msg: message
  - labels:
      level:

Choisir Elasticsearch si :

1. Recherche full-text : analyse de logs non structurés
2. Conformité : exigences réglementaires (PCI-DSS, HIPAA)
3. SIEM : intégration avec des outils de sécurité
4. Équipe expérimentée : administrateurs Elasticsearch disponibles

La formation LFS460 Sécurité Kubernetes couvre les aspects compliance.

Performance et scalabilité

Benchmarks d'ingestion

Elasticsearch offre des latences de requête inférieures mais Loki scale plus facilement grâce au stockage objet.

Configuration haute disponibilité Loki

# Loki scalable mode
loki:
  auth_enabled: false
  server:
    http_listen_port: 3100
  distributor:
    ring:
      kvstore:
        store: memberlist
  ingester:
    lifecycler:
      ring:
        replication_factor: 3
  storage_config:
    boltdb_shipper:
      active_index_directory: /loki/index
      cache_location: /loki/cache
      shared_store: s3
    aws:
      s3: s3://eu-west-1/loki-logs

À retenir : Loki en mode scalable nécessite un stockage objet mais élimine la gestion des disques.

Pour comparer d'autres outils, consultez Prometheus vs Datadog : quel outil de monitoring choisir.

Migration entre solutions

D'Elasticsearch vers Loki

La migration implique de repenser le requêtage plutôt que de migrer les données historiques.

# Export des dashboards Kibana vers Grafana
# Outil communautaire : https://github.com/grafana/kibana-to-grafana

# Déploiement Loki parallèle
helm install loki grafana/loki-stack -n monitoring

Stratégie recommandée :

1. Déployer Loki en parallèle
2. Basculer les nouveaux logs vers Loki
3. Conserver Elasticsearch en lecture seule pour l'historique
4. Désactiver Elasticsearch après expiration de la rétention

De Loki vers Elasticsearch

Migration plus rare, mais justifiée pour des besoins de recherche avancée.

# Déploiement ECK
kubectl apply -f https://download.elastic.co/downloads/eck/2.11.0/crds.yaml
kubectl apply -f https://download.elastic.co/downloads/eck/2.11.0/operator.yaml

Consultez notre formation Kubernetes vs alternatives : comparatif pour d'autres comparaisons.

Intégration avec l'écosystème Kubernetes

Loki avec le stack LGTM

Loki s'intègre nativement avec :

• Grafana : visualisation unifiée
• Tempo : corrélation logs-traces
• Mimir : métriques (fork de Prometheus)

# Corrélation logs-traces dans Grafana
datasources:
- name: Loki
  type: loki
  url: http://loki:3100
  jsonData:
    derivedFields:
    - name: traceID
      matcherRegex: "traceID=(\\w+)"
      url: "$${__value.raw}"
      datasourceUid: tempo

Elasticsearch avec Elastic APM

Elasticsearch offre une intégration APM native pour la corrélation logs-métriques-traces.

La formation administrateur système LFS458 couvre ces architectures d'observabilité.

Checklist de décision Loki vs Elasticsearch

À retenir : Commencez par Loki pour les nouveaux projets, migrez vers Elasticsearch si les besoins analytiques le justifient.

Notre page Monitoring et dépannage Kubernetes regroupe toutes les ressources observabilité.

Maîtrisez la centralisation des logs Kubernetes

Le choix Loki vs Elasticsearch logs Kubernetes dépend de votre contexte.

Synthèse des recommandations :

• Startups et PME : Loki pour le ratio coût/efficacité
• Grandes entreprises : Elasticsearch pour les besoins analytiques avancés
• Hybride : Loki pour les logs applicatifs, Elasticsearch pour la sécurité

Prochaines étapes recommandées :

1. Auditez vos besoins en recherche et rétention
2. Testez les deux solutions sur un cluster de développement
3. Formez vos équipes sur la solution retenue

SFEIR accompagne les équipes dans la maîtrise de l'observabilité Kubernetes :

• LFS458 Administration Kubernetes : monitoring, logging et troubleshooting en production
• LFS460 Sécurité Kubernetes : audit logs et conformité
• Kubernetes, les fondamentaux : découverte des concepts d'observabilité

Contactez nos experts pour définir votre stratégie d'observabilité.