ELK Architecture : Shards, ILM et Query DSL expliqués simplement

Shards et Replicas : comprendre le système de distribution

Quand vous indexez un document dans Elasticsearch, il n'est pas stocké "en vrac" dans un seul fichier. Elasticsearch découpe chaque index en morceaux appelés shards (partitions). Chaque shard est en réalité une instance complète du moteur Apache Lucene, capable d'indexer et de rechercher des données de manière autonome.

Primary shards vs Replica shards

Elasticsearch distingue deux types de shards :

Comment les shards sont distribués

Elasticsearch répartit automatiquement les shards sur les nœuds disponibles du cluster. Une règle fondamentale : un replica ne réside jamais sur le même nœud que son primary shard. Si un nœud tombe, le replica sur un autre nœud prend le relais sans perte de données.

Ce qui se passe lors d'une recherche

Quand vous lancez une recherche, Elasticsearch envoie la requête à tous les shards de l'index (primaries et replicas). Chaque shard exécute la recherche localement, puis les résultats sont fusionnés et triés par le nœud coordinateur. C'est ce mécanisme de scatter-gather qui rend Elasticsearch si rapide : la recherche est parallélisée sur toutes les partitions.

Dimensionner ses shards : les règles pratiques

Un mauvais dimensionnement des shards est la cause numéro 1 de problèmes de performance en production. Trop de shards surchargent le cluster (overhead mémoire, ralentissement). Trop peu de shards empêchent la parallélisation.

Pour vérifier le nombre et l'état de vos shards, utilisez l'API _cat/shards :

GET _cat/shards?v

# Résultat :
# index             shard  prirep  state    docs   store  node
# logs-2026.02.22   0      p       STARTED  50000  45mb   node-1
# logs-2026.02.22   0      r       STARTED  50000  45mb   node-2

ILM : automatiser le cycle de vie des index

En production, les index de logs grossissent continuellement. Sans gestion automatisée, le cluster finit par manquer d'espace disque et les performances se dégradent. L'Index Lifecycle Management (ILM) résout ce problème en automatisant la gestion de vos index à travers 5 phases.

Les 5 phases du cycle de vie

Pourquoi ILM est indispensable en production

Sans ILM, vous devez gérer manuellement la rotation et la suppression de vos index. Avec un flux de logs continu, cela devient vite ingérable. ILM vérifie automatiquement (toutes les 10 minutes par défaut) si un index doit passer à la phase suivante, en fonction de critères que vous définissez : âge de l'index, taille des shards ou nombre de documents.

Configurer une politique ILM : exemple complet

Voici un exemple réaliste de politique ILM pour des logs applicatifs. L'objectif : conserver les logs récents sur du stockage rapide, les archiver après 7 jours, et les supprimer après 90 jours.

PUT _ilm/policy/logs-policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_primary_shard_size": "50gb",
            "max_age": "1d"
          }
        }
      },
      "warm": {
        "min_age": "7d",
        "actions": {
          "shrink": {
            "number_of_shards": 1
          },
          "forcemerge": {
            "max_num_segments": 1
          }
        }
      },
      "cold": {
        "min_age": "30d",
        "actions": {
          "allocate": {
            "number_of_replicas": 0
          }
        }
      },
      "delete": {
        "min_age": "90d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

Ce que fait cette politique :

• Hot : un nouvel index est créé (rollover) quand le shard dépasse 50 Go ou quand l'index a 1 jour
• Warm (après 7 jours) : l'index est compacté en 1 seul shard et les segments Lucene sont fusionnés pour optimiser l'espace
• Cold (après 30 jours) : les replicas sont supprimés pour économiser de l'espace disque
• Delete (après 90 jours) : l'index est définitivement supprimé

Pour appliquer cette politique à un index template :

PUT _index_template/logs-template
{
  "index_patterns": ["logs-*"],
  "template": {
    "settings": {
      "number_of_shards": 1,
      "number_of_replicas": 1,
      "index.lifecycle.name": "logs-policy"
    }
  }
}

Tous les index dont le nom commence par "logs-" seront automatiquement gérés par cette politique ILM.

Query DSL : le langage de requêtes d'Elasticsearch

Le Query DSL (Domain Specific Language) est le langage JSON utilisé pour interroger Elasticsearch. C'est l'équivalent du SQL pour les bases de données relationnelles, mais adapté à la recherche full-text et aux agrégations sur des données distribuées.

Query context vs Filter context

Elasticsearch distingue deux contextes d'exécution pour les requêtes. Comprendre cette distinction est essentiel pour écrire des requêtes performantes :

Les types de requêtes essentiels

Exemples de requêtes courantes

1. Recherche full-text simple

Trouver tous les documents contenant "connection refused" dans le champ message :

GET logs-*/_search
{
  "query": {
    "match": {
      "message": "connection refused"
    }
  }
}

La requête match analyse le texte : elle cherche "connection" OU "refused". Pour une expression exacte, utilisez match_phrase.

2. Requête combinée avec bool

Trouver les erreurs 500 du service "api-gateway" survenues dans les dernières 24 heures :

GET logs-*/_search
{
  "query": {
    "bool": {
      "must": [
        { "match": { "service": "api-gateway" } }
      ],
      "filter": [
        { "term": { "status_code": 500 } },
        { "range": {
            "@timestamp": {
              "gte": "now-24h",
              "lte": "now"
            }
          }
        }
      ]
    }
  }
}

Le must influence le score de pertinence. Le filter filtre sans calculer de score (plus performant). C'est la structure la plus utilisée en production.

3. Agrégation : top 5 des erreurs par service

Compter le nombre d'erreurs par service et afficher les 5 services avec le plus d'erreurs :

GET logs-*/_search
{
  "size": 0,
  "query": {
    "term": { "level": "error" }
  },
  "aggs": {
    "errors_par_service": {
      "terms": {
        "field": "service.keyword",
        "size": 5
      }
    }
  }
}

"size": 0 signifie qu'on ne veut pas les documents eux-mêmes, uniquement le résultat de l'agrégation. Le champ .keyword est utilisé pour les termes exacts (non analysés).

4. Recherche avec date range et tri

Dernières 100 entrées de logs, triées par date décroissante :

GET logs-*/_search
{
  "size": 100,
  "sort": [
    { "@timestamp": { "order": "desc" } }
  ],
  "query": {
    "range": {
      "@timestamp": {
        "gte": "now-7d"
      }
    }
  }
}

Bonnes pratiques architecture ELK