01 - L'Elastic Stack de A a Z
Ce que tu vas apprendre
- Le rôle de chaque composant de l'Elastic Stack
- Comment les donnees circulent de la source a la visualisation
- Les différentes architectures possibles (minimale, standard, bufferisee)
- Quand utiliser Logstash, quand s'en passer
Prerequisites
- Avoir lu l'article 00 - Introduction
- Connaitre les bases de Docker (ou avoir lu la serie Docker pour les devs)
ELK, ca veut dire quoi au juste
Quand j'ai entendu "ELK" pour la première fois en 2020, j'ai cru que c'etait un framework. Un collegue m'a corrige : "c'est trois outils empiles". Elasticsearch, Logstash, Kibana. Trois projets separes, trois équipes, trois repos. Ils se trouvent juste bien ensemble.
Depuis, Elastic a ajoute Beats et renomme le tout "Elastic Stack". Mais tout le monde continue de dire ELK. Dans cette serie, j'utilise les deux termes de facon interchangeable.
Les quatre composants
Elasticsearch : le moteur de stockage et de recherche
Elasticsearch stocke les donnees et les rend cherchables en temps réel (ou presque). C'est une base de donnees orientee documents, construite sur Apache Lucene. Tu envoies du JSON, tu cherches avec du JSON.
Ce n'est pas une base relationnelle. Il n'y a pas de tables, pas de SQL natif (meme si Elastic a ajoute une couche SQL par-dessus). On stocke des documents dans des index.
json// Un document dans un index "logs-app"
{
"@timestamp": "2026-03-31T14:23:01.456Z",
"level": "ERROR",
"service": "api-users",
"message": "Connection refused to PostgreSQL",
"host": "prod-api-01",
"duration_ms": 5023
}
Ce qui rend Elasticsearch special, c'est la recherche full-text et la vitesse des aggregations. Tu peux chercher dans des millions de documents en quelques millisecondes.
Logstash : le pipeline de transformation
On en a parle dans l'article précédent. Logstash prend des donnees en entree, les transforme, et les envoie quelque part. C'est le composant qui fait le travail sale : parser des lignes de log, convertir des types, enrichir avec des donnees externes, router vers différentes destinations.
input {
beats { port => 5044 }
}
filter {
grok {
match => { "message" => "%{COMBINEDAPACHELOG}" }
}
geoip {
source => "clientip"
}
}
output {
elasticsearch {
hosts => ["http://elasticsearch:9200"]
index => "logs-apache-%{+YYYY.MM.dd}"
}
}Ce pipeline recoit des logs Apache depuis Filebeat, les parse avec Grok pour en extraire les champs (IP, méthode, URL, code HTTP, user-agent), ajoute la geolocalisation de l'IP, et envoie le tout dans Elasticsearch avec un index par jour.
Kibana : la visualisation
Kibana est l'interface web de l'Elastic Stack. Tu te connectes sur le port 5601, et tu peux :
- Explorer les donnees dans "Discover" (recherche libre, filtres, timeline)
- Creer des dashboards avec des graphiques, des cartes, des tableaux
- Configurer des alertes
- Gerer les index et les politiques de cycle de vie
- Utiliser "Dev Tools" pour envoyer des requêtes directement a Elasticsearch
Kibana ne stocke rien (a part sa propre configuration). Il lit tout depuis Elasticsearch.
Beats : les agents de collecte
Les Beats sont des agents legers installes sur les machines qui produisent des donnees. Chaque Beat est specialise :
- Filebeat : lit des fichiers de log
- Metricbeat : collecte les metriques système (CPU, RAM, disque, réseau)
- Heartbeat : vérifié la disponibilité de services (ping, HTTP, TCP)
- Packetbeat : capture le trafic réseau
- Auditbeat : audit de sécurité (modification fichiers, logins)
Filebeat est de loin le plus utilise. Il consomme ~15 Mo de RAM, gere la rotation des fichiers, et garantit qu'aucune ligne n'est perdue grâce à un registre interne.
Comment les donnees circulent
Architecture minimale : Beats -> Elasticsearch
La plus simple. Pas de Logstash. Filebeat lit les logs et les envoie directement a Elasticsearch. Les ingest pipelines d'Elasticsearch font les transformations basiques.
┌──────────────┐ ┌──────────────┐ ┌──────────┐
│ Serveur │ │ │ │ │
│ │ │ Elasticsearch│────>│ Kibana │
│ ┌──────────┐ │ │ │ │ │
│ │ Filebeat │─┼───────────────────>│ ingest │ │ :5601 │
│ └──────────┘ │ │ pipeline │ │ │
│ │ │ │ │ │
│ app.log │ │ :9200 │ │ │
└──────────────┘ └──────────────┘ └──────────┘Ca marche pour des cas simples : des logs JSON deja structures, des metriques système, du monitoring de disponibilité.
Ca ne suffit plus quand :
- Les logs ne sont pas structures (lignes de texte brutes)
- Tu dois enrichir les donnees (GeoIP, lookup en base)
- Tu dois router vers plusieurs destinations
- Tu veux decoupler la collecte du stockage
Architecture standard : Beats -> Logstash -> Elasticsearch
C'est l'architecture ELK classique. Filebeat collecte, Logstash transforme, Elasticsearch stocke.
┌──────────┐ ┌──────────┐
│ Serveur 1│ │ │
│ Filebeat │────>│ │ ┌──────────────┐ ┌──────────┐
└──────────┘ │ │ │ │ │ │
│ Logstash │────>│ Elasticsearch│────>│ Kibana │
┌──────────┐ │ │ │ │ │ │
│ Serveur 2│ │ :5044 │ │ :9200 │ │ :5601 │
│ Filebeat │────>│ │ │ │ │ │
└──────────┘ │ │ └──────────────┘ └──────────┘
└──────────┘
┌──────────┐ ^
│ Serveur 3│ │
│ Filebeat │──────────┘
└──────────┘Logstash écoûte sur le port 5044 (input Beats). Tous les Filebeat envoient leurs logs la. Logstash parse, enrichit, nettoie, et pousse dans Elasticsearch.
L'avantage : tu peux changer le parsing sans toucher aux serveurs. Toute la logique de transformation est centralisee dans Logstash.
L'inconvenient : Logstash est un point unique de defaillance. S'il tombe, les Filebeat bufferisent en local, mais si Logstash ne revient pas, tu perds des donnees.
Architecture bufferisee : Beats -> Kafka -> Logstash -> Elasticsearch
Pour la production serieuse. Kafka agit comme un buffer entre la collecte et le traitement.
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐
│ Serveur 1│ │ │ │ │ │ │
│ Filebeat │────>│ │ │ │ │ │
└──────────┘ │ │ │ │ │ │
│ Kafka │────>│ Logstash │────>│ Elasticsearch│
┌──────────┐ │ │ │ │ │ │
│ Serveur 2│ │ topics │ │ consumer │ │ │
│ Filebeat │────>│ │ │ group │ │ │
└──────────┘ │ │ │ │ └──────────────┘
└──────────┘ └──────────┘
┌──────────┐ ^
│ Serveur 3│ │
│ Filebeat │──────────┘
└──────────┘Kafka absorbe les pics de trafic. Si Logstash tombe, les messages restent dans Kafka. Quand Logstash revient, il reprend ou il s'etait arrêté. Zero perte.
Tu peux aussi scaler Logstash horizontalement : plusieurs instances dans le meme consumer group, Kafka repartit les messages entre elles.
C'est l'architecture que j'utilise sur les projets paltemps.fr qui depassent 10 000 événements par seconde. En dessous, l'architecture standard suffit.
Architecture ETL : Base de donnees -> Logstash -> Elasticsearch
Logstash sait aussi lire dans des bases de donnees. Tu configures un input JDBC, tu ecris une requête SQL, et Logstash synchronise les résultats vers Elasticsearch.
┌──────────────┐ ┌──────────┐ ┌──────────────┐
│ │ │ │ │ │
│ PostgreSQL │────>│ Logstash │────>│ Elasticsearch│
│ │ │ │ │ │
│ table: │ │ JDBC │ │ index: │
│ products │ │ polling │ │ products │
│ │ │ toutes │ │ │
│ │ │ les 30s │ │ │
└──────────────┘ └──────────┘ └──────────────┘C'est utile quand tu veux rendre une base SQL cherchable avec la recherche full-text d'Elasticsearch. On fera un cas pratique complet dans l'article 28.
Un compose.yaml pour découvrir
Voici le squelette Docker Compose qu'on va utiliser tout au long de cette serie. Trois services : Elasticsearch, Kibana, Logstash.
yamlservices:
elasticsearch:
image: docker.elastic.co/elasticsearch/elasticsearch:8.17.0
environment:
- discovery.type=single-node
- xpack.security.enabled=false
- "ES_JAVA_OPTS=-Xms512m -Xmx512m"
ports:
- "9200:9200"
volumes:
- es-data:/usr/share/elasticsearch/data
kibana:
image: docker.elastic.co/kibana/kibana:8.17.0
environment:
- ELASTICSEARCH_HOSTS=http://elasticsearch:9200
ports:
- "5601:5601"
depends_on:
- elasticsearch
logstash:
image: docker.elastic.co/logstash/logstash:8.17.0
environment:
- "LS_JAVA_OPTS=-Xms256m -Xmx256m"
volumes:
- ./logstash/pipeline/:/usr/share/logstash/pipeline/
- ./logstash/config/logstash.yml:/usr/share/logstash/config/logstash.yml
ports:
- "5044:5044"
depends_on:
- elasticsearch
volumes:
es-data:
On detaillera chaque service dans l'article 02. Pour l'instant, note les versions : tout est en 8.17.0. Utiliser la meme version pour les trois composants évité des problèmes de compatibilité.
La question de la mémoire
Un point qui surprend souvent : l'Elastic Stack consomme de la RAM. Beaucoup de RAM.
| Composant | RAM minimum | RAM recommandee |
|---|---|---|
| Elasticsearch | 512 Mo | 1-2 Go |
| Logstash | 256 Mo | 1 Go |
| Kibana | 256 Mo | 512 Mo |
| Filebeat | 15 Mo | 50 Mo |
Avec les trois composants principaux, tu as besoin d'au moins 1 Go de RAM libre. Sur un laptop avec 8 Go, ca passe. Sur un vieux portable de 4 Go, ca va ramer.
Les valeurs dans le compose.yaml ci-dessus sont ajustees pour le dev local (-Xms512m pour ES, -Xms256m pour Logstash). En production, on verra des configurations plus genereuses dans l'article 21.
Versions et licences
L'Elastic Stack est disponible sous deux licences depuis 2021 :
- Elastic License 2.0 : gratuite, mais pas open source au sens strict. Tu peux utiliser, modifier, déployer. Tu ne peux pas revendre en tant que service manage.
- SSPL (Server Side Public License) : alternative open-source, memes restrictions sur le service manage.
En pratique, pour un dev qui deploie pour son entreprise ou ses clients, c'est gratuit. La restriction ne touche que les cloud providers qui voudraient vendre "Elasticsearch as a Service".
Pour les versions, la regle est simple : utilise la meme version majeure et mineure pour tous les composants. Elasticsearch 8.17.0, Logstash 8.17.0, Kibana 8.17.0. Ne melange pas les versions.
Résumé
- L'Elastic Stack = Elasticsearch (stockage) + Logstash (transformation) + Kibana (visualisation) + Beats (collecte)
- Trois architectures types : minimale (Beats -> ES), standard (Beats -> Logstash -> ES), bufferisee (Beats -> Kafka -> Logstash -> ES)
- Logstash est nécessaire quand tu as du parsing complexe, de l'enrichissement ou du routage
- L'Elastic Stack consomme de la RAM : prevoir au moins 1 Go pour le trio ES + Logstash + Kibana en dev
- Toujours utiliser la meme version pour tous les composants
Precedent : 00 - Introduction | Suivant : 02 - Installation avec Docker