🔍 Elasticsearch – Installation, Querying & Intégration

Un moteur de recherche distribué

Elasticsearch est un **moteur de recherche et d'analyse** distribué, open-source, construit sur **Apache Lucene**.

Il est souvent qualifié de base de données **NoSQL orientée document** (comme MongoDB), mais sa force principale est la **recherche full-text** (texte intégral) et l'analyse en temps réel.

Toutes les interactions se font via une API RESTful (JSON sur HTTP).

Cas d'usage (Stack ELK/Elastic)

• Recherche de site web : La barre "Rechercher..." de votre site.
• Logging & Métriques : (Le 'E' de la stack ELK : Elasticsearch, Logstash, Kibana). Centralisation et analyse de logs serveur.
• Analyse (BI) : Agrégation et visualisation de grands volumes de données.
• APM : (Application Performance Monitoring).

Parallèle SQL vs Elasticsearch

Pour comprendre ES, voici une analogie (imparfaite) avec le monde SQL :

Les Nœuds (Nodes)

Un **Nœud** (Node) est une instance (un processus) d'Elasticsearch. C'est le "worker". Un nœud peut avoir plusieurs rôles (master, data, ingest...).

Le Cluster

Un **Cluster** est un groupe d'un ou plusieurs nœuds qui communiquent entre eux et partagent la charge de travail. Ils sont identifiés par le même cluster.name (dans elasticsearch.yml).

L'API REST vous permet de parler à n'importe quel nœud, qui relaiera la requête au bon endroit.

Schéma d'un Cluster (3 Nœuds)

[Image d'un cluster Elasticsearch]
         (API REST, ex: Port 9200)
             |
             ▼
+-----------------------+
| Nœud 1 (Master éligible, Data) |
+-----------------------+
       ^ \
       |  \ (Communication interne)
       |   \
+------+...V---------------+
| Nœud 2 (Data)         |
+-----------------------+
       ^ \
       |  \
       |   \
+------+...V---------------+
| Nœud 3 (Data)         |
+-----------------------+

Index (l'équivalent de la BDD)

Un Index est une collection de Documents qui ont une structure similaire (un "Mapping"). Ex: articles, logs-2025-11.

Document (l'équivalent de la Ligne)

Un Document est l'unité de base de l'information. C'est un simple objet JSON.

// Un Document dans l'index 'articles'
{
    "_index": "articles",
    "_id": "1", // L'ID unique
    "_source": { // Le JSON original
        "titre": "Elasticsearch et Python",
        "auteur": "Alice",
        "date_pub": "2025-11-01T10:00:00Z",
        "tags": ["python", "search"],
        "publie": true
    }
}

Index Inversé (Le secret de la vitesse)

Elasticsearch (via Lucene) utilise un Index Inversé pour la recherche full-text. Au lieu de mapper une page à des mots, il mappe des mots aux pages.

Documents (Entrée)

Doc 1: "the quick brown fox"
Doc 2: "a quick brown dog"

Index Inversé (Sortie, simplifié)

Terme   | Doc 1 | Doc 2
--------|-------|-------
a       |       | X
brown   | X     | X
dog     |       | X
fox     | X     |
quick   | X     | X
the     | X     |

Une recherche pour "quick dog" trouve instantanément les documents (Doc 2) via l'index, sans scanner le texte.

Shards (Scalabilité Horizontale)

Un index peut devenir trop gros pour un seul nœud. ES vous permet de le diviser en morceaux appelés Shards (Partitions). C'est le mécanisme de scalabilité horizontale.

Si vous créez un index avec 3 Shards (P0, P1, P2), ES les répartit sur vos nœuds. Quand vous recherchez, ES interroge les 3 Shards en parallèle et fusionne les résultats.

Replicas (Haute Disponibilité)

Un Replica est une copie d'un Shard. Si un nœud tombe, le replica (sur un autre nœud) prend le relais. C'est le mécanisme de haute disponibilité (HA).

Schéma (3 Nœuds, 1 Index, 3 Shards, 1 Replica)

[Image d'une architecture Shards/Replicas]
Index "articles" (3 Shards Primaires, 1 Replica)

+------------------+   +------------------+   +------------------+
| Nœud 1           |   | Nœud 2           |   | Nœud 3           |
|                  |   |                  |   |                  |
| +----+   +----+  |   | +----+   +----+  |   | +----+   +----+  |
| | P0 |   | R1 |  |   | | P1 |   | R2 |  |   | | P2 |   | R0 |  |
| +----+   +----+  |   | +----+   +----+  |   | +----+   +----+  |
|                  |   |                  |   |                  |
+------------------+   +------------------+   +------------------+

P0, P1, P2 = Shards Primaires (les "originaux")
R0, R1, R2 = Shards Replicas (les "copies")

Si le Nœud 2 tombe :

• P1 est perdu.
• ES promeut automatiquement R1 (sur Nœud 1) en nouveau Primaire P1.
• Le cluster passe en statut "yellow" (données disponibles, mais un replica manque).

L'interface de la Stack Elastic

Kibana est l'interface web officielle (le 'K' de ELK). C'est un outil de visualisation et de gestion.

Installation (Linux)

# (En supposant que le dépôt Elastic 8.x est déjà ajouté)
sudo apt-get install kibana
# ou
sudo dnf install kibana

Configuration (kibana.yml)

Le fichier /etc/kibana/kibana.yml doit pointer vers ES.

# /etc/kibana/kibana.yml

server.port: 5601
server.host: "0.0.0.0" # Écouter sur toutes les interfaces

# Adresse d'Elasticsearch
elasticsearch.hosts: ["http://localhost:9200"]

Démarrage

sudo systemctl enable --now kibana

Dev Tools (L'outil indispensable)

L'outil le plus important de Kibana est les Dev Tools.

C'est une console (type Postman ou client curl) qui permet d'envoyer des requêtes à l'API REST d'ES, avec autocomplétion et formatage JSON.

Toutes les requêtes de ce guide (GET _search, PUT /index) se font via cet outil.

Exemple (Console Dev Tools)

# Colonne de Gauche (Requête)
GET /_cluster/health

# Colonne de Droite (Réponse JSON)
{
  "cluster_name" : "ideo-lab-cluster",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  ...
}

API REST

Tout dans Elasticsearch est une API REST. Les verbes HTTP ont un sens :

• GET : Lire (_search, _doc, _cat).
• POST : Créer (avec auto-ID) ou Actions (_search, _update).
• PUT : Créer ou Mettre à jour (avec ID fixe) (_doc/1, _mapping).
• DELETE : Supprimer (_doc/1, /mon-index).

# Ping de base (GET)
curl -X GET "http://localhost:9200/"

{
  "name" : "node-1",
  "cluster_name" : "ideo-lab-cluster",
  ...
  "version" : { "number" : "8.11.1", ... }
}

API _cat (Monitoring simple)

L'API _cat (Compact and Aligned Text) est une API lisible par l'homme (pas JSON) pour le monitoring rapide.

# Santé du cluster (green, yellow, red)
curl "localhost:9200/_cat/health?v"
# v = verbose (ajoute les en-têtes)

# Lister les Nœuds
curl "localhost:9200/_cat/nodes?v"

# Lister les Index
curl "localhost:9200/_cat/indices?v"

# Lister les Shards (et leur état)
curl "localhost:9200/_cat/shards?v"

# Lister les Mappings
curl "localhost:9200/_cat/mappings?v"

POST (Auto-ID)

Utilisez POST /index/_doc si vous n'avez pas d'ID unique (ex: logs). ES générera un ID unique.

POST /logs/_doc
{
  "timestamp": "2025-11-01T22:00:00Z",
  "level": "ERROR",
  "message": "Connexion BDD échouée"
}

-- Réponse (ES a généré _id)
{
  "_index" : "logs",
  "_id" : "aBc1dEf2gHi3...",
  "result" : "created",
  ...
}

PUT (ID Spécifique)

Utilisez PUT /index/_doc/id si vous avez déjà un ID (ex: ID de votre BDD SQL).

PUT /articles/_doc/1
{
  "titre": "Article sur Python",
  "auteur_id": 101,
  "tags": ["python", "tech"]
}

-- Réponse
{
  "_index" : "articles",
  "_id" : "1",
  "result" : "created", // (ou 'updated' si l'ID 1 existait)
  ...
}

GET (Lire un document)

GET /articles/_doc/1

-- Réponse
{
  "_index" : "articles",
  "_id" : "1",
  "found" : true,
  "_source" : {
    "titre": "Article sur Python", ...
  }
}

DELETE (Supprimer un document)

DELETE /articles/_doc/1

-- Réponse
{
  ...
  "result" : "deleted",
  "_id" : "1"
}

_update (Mise à jour partielle)

Utilisez _update (avec POST) pour modifier un document sans écraser le reste.

POST /articles/_update/1
{
  "doc": {
    "titre": "Nouveau Titre (modifié)",
    "statut": "publie"
  }
}
-- (Laisse 'auteur_id' et 'tags' intacts)

_update (Script)

POST /articles/_update/1
{
  "script": {
    "source": "ctx._source.tags.add(params.new_tag)",
    "params": {
      "new_tag": "elasticsearch"
    }
  }
}

_search

Toute recherche utilise l'endpoint _search (GET ou POST) et un corps JSON (le "Query DSL").

match_all (Tout récupérer)

GET /articles/_search
{
  "query": {
    "match_all": {}
  },
  "size": 10,
  "from": 0
}

match (Full-Text)

Utilise l'Analyzer (cf 3.3). C'est la recherche "Google".

GET /articles/_search
{
  "query": {
    "match": {
      "titre": "python elasticsearch"
    }
  }
}
-- (Trouve "Article sur Python et Elasticsearch"
--  car 'et' est un stop-word et 'Python'/'Elasticsearch'
--  sont tokenizés)

term (Exact)

Recherche une valeur exacte (non-analyzée). Doit être utilisé sur un champ keyword.

GET /articles/_search
{
  "query": {
    "term": {
      "tags.keyword": "python"
    }
  }
}
-- (Ne trouve que les tags 'python' exacts)

terms (Liste)

GET /articles/_search
{
  "query": {
    "terms": {
      "statut.keyword": ["publie", "archive"]
    }
  }
}

Le "GROUP BY" d'Elasticsearch

Les agrégations (aggs) permettent de faire des statistiques sur vos données.

terms (Grouper par tag)

Requête : "Compte le nombre d'articles par tag".

GET /articles/_search
{
  "size": 0, // On ne veut pas les documents, juste les aggs
  "aggs": {
    "group_by_tags": {
      "terms": {
        "field": "tags.keyword" // DOIT être 'keyword'
      }
    }
  }
}

-- Réponse (simplifiée)
"aggregations": {
  "group_by_tags": {
    "buckets": [
      { "key": "python", "doc_count": 50 },
      { "key": "tech", "doc_count": 35 },
      ...
    ]
  }
}

Sous-Agrégations (Group by imbriqué)

Requête : "Grouper par tag, PUIS calculer la note moyenne par tag".

GET /articles/_search
{
  "size": 0,
  "aggs": {
    "group_by_tags": {
      "terms": { "field": "tags.keyword" },
      "aggs": {
        "avg_note": {
          "avg": { "field": "note" }
        }
      }
    }
  }
}

date_histogram (Séries temporelles)

Requête : "Compte le nombre d'articles par mois".

GET /articles/_search
{
  "size": 0,
  "aggs": {
    "articles_par_mois": {
      "date_histogram": {
        "field": "date_pub",
        "calendar_interval": "month"
      }
    }
  }
}

La Stack ELK (ou Elastic Stack)

Concerne l'ingestion de logs (ex: logs Nginx, syslogs).

• Filebeat (Agent Léger) : Un agent (comme un DaemonSet K8s) qui "tail" (suit) les fichiers de logs et les envoie.
• Logstash (ETL) : Un "pipeline" lourd (Java) qui reçoit les logs de Filebeat. Il peut Parser (ex: Grok), Transformer (ex: enrichir l'IP) et Charger dans Elasticsearch.
• Elasticsearch (Base) : Stocke et indexe les logs.
• Kibana (UI) : Visualise les logs (Dashboards).

Schéma de flux (Logs)

[Image d'une architecture ELK]

[Serveur Web 1] -> [Filebeat] ->-+
                                |
[Serveur Web 2] -> [Filebeat] ->-+
                                |
[Serveur DB 1]  -> [Filebeat] ->-+
                                |
                                ▼
                        +----------------+
                        | Logstash (ETL) |
                        | (Grok, Mutate) |
                        +----------------+
                                |
                                ▼
                   +-----------------------+
                   | Elasticsearch (Index) |
                   +-----------------------+
                                |
                                ▼
                        +----------------+
                        | Kibana (UI)    |
                        +----------------+

API _cluster/health

L'endpoint le plus important pour le monitoring.

GET /_cluster/health

{
  ...
  "status" : "yellow",
  "number_of_nodes" : 1,
  "unassigned_shards" : 3,
  ...
}

Les Statuts (Green, Yellow, Red)

1. Déclarer un "Repository"

On ne peut pas "juste" copier les fichiers. Il faut déclarer un "Repository" (ex: un dossier partagé (NFS) ou un bucket S3).

Ajouter à elasticsearch.yml (sur tous les nœuds) :

path.repo: ["/mnt/backups/es"]

# Déclarer le repo (via API)
PUT /_snapshot/mon_repo_local
{
  "type": "fs",
  "settings": {
    "location": "/mnt/backups/es"
  }
}

2. Prendre un Snapshot (Backup)

# Lance le snapshot (non-bloquant)
POST /_snapshot/mon_repo_local/snapshot_20251101?wait_for_completion=true

# (wait_for_completion=true attend la fin)

3. Restaurer un Snapshot

# D'abord, fermer l'index (si on l'écrase)
POST /articles/_close

# Lancer la restauration
POST /_snapshot/mon_repo_local/snapshot_20251101/_restore

# Rouvrir l'index
POST /articles/_open