Installer ELK - Évitez les pièges courants et sécurisez votre stack

Mettre en place Elasticsearch, Logstash et Kibana ne consiste pas seulement à installer trois briques séparées. Le vrai sujet, c’est de partir sur une base cohérente: mêmes versions, sécurité activée, bons ports et un premier flux de logs qui prouve que tout circule correctement. Dans un contexte DevOps, je cherche toujours une installation reproductible, lisible et assez proche d’un vrai usage pour ne pas découvrir les problèmes au mauvais moment.

Ce que recouvre vraiment une installation ELK

ELK n’est pas un simple trio d’outils à lancer dans le désordre. Elasticsearch stocke et indexe, Logstash transforme et route, Kibana visualise et explore. Dans un environnement DevOps, cette séparation est précieuse, parce qu’elle évite de mélanger ingestion, stockage et présentation dans un seul composant difficile à diagnostiquer.

Le premier réflexe que je recommande, c’est de respecter l’ordre d’installation. Elastic documente clairement qu’il faut installer d’abord Elasticsearch, puis Kibana, puis Logstash. Je fais la même chose en pratique, parce que Kibana dépend d’Elasticsearch, et que Logstash n’a d’intérêt que si la cible de sortie existe déjà.

Le deuxième réflexe, plus important qu’on ne le croit, concerne la compatibilité des versions. Sur une pile Elastic, je préfère garder une version unique sur tous les composants. Mélanger les branches peut fonctionner dans certains cas, mais ce n’est pas la base la plus saine pour apprendre, tester ou maintenir un environnement stable.

À partir de là, la vraie question n’est plus “qu’est-ce qu’ELK ?”, mais “quelle méthode d’installation me donne le meilleur rapport entre vitesse, propreté et maintenabilité ?”.

Choisir la bonne méthode selon le contexte

Je ne choisis pas la même approche pour un lab local, une VM durable ou une plateforme déjà industrialisée. Le bon chemin dépend surtout de ce que vous voulez obtenir au bout de la journée, pas seulement de ce qui semble le plus simple au départ.

Méthode	Quand je la choisis	Avantages	Limites
Docker Compose	Poste de dev, démonstration, POC	Démarrage rapide, environnement reproductible, nettoyage facile	Demande de la mémoire, gestion des volumes à surveiller, pas le meilleur choix pour une exposition large
Paquets système	VM ou serveur Linux durable	Services gérés par systemd, emplacements standard, maintenance plus claire	Un peu plus verbeux à mettre en place, moins portable qu’un conteneur
Archive tar.gz	Environnement verrouillé, absence de droits admin, besoin de contrôle fin	Très portable, installation manuelle maîtrisée, utile en CI ou sur un hôte contraint	Plus de supervision à gérer soi-même, plus facile de rater un paramètre
Kubernetes avec ECK	Plateforme Kubernetes déjà en place	Déclaratif, intégration à l’operator, bon pour les équipes k8s matures	Complexité plus élevée, logique d’exploitation différente d’un simple serveur

Si je dois être tranchant, je dirais ceci: Docker Compose est le meilleur choix pour comprendre rapidement la mécanique de la pile, tandis que les paquets système restent plus propres dès qu’on veut un socle durable. Avec ce cadrage, on peut passer à une mise en route locale qui fonctionne vite sans perdre la logique de la stack.

Installer une pile locale avec Docker Compose

Pour un premier montage, j’aime démarrer Elasticsearch et Kibana avec Docker Compose, puis ajouter Logstash une fois que la base répond correctement. C’est la voie la plus pratique pour valider l’accès à l’interface, tester la sécurité et éviter de se battre trop tôt avec des détails d’exploitation.

Le point de vigilance numéro un, c’est la mémoire. Sur Docker Desktop, Elastic recommande au moins 4 Go de RAM, et c’est un vrai minimum si vous voulez ouvrir Kibana sans ralentissements frustrants. En pratique, je préfère disposer d’une marge supplémentaire dès qu’un navigateur, un éditeur et quelques conteneurs tournent en même temps.

STACK_VERSION=
ELASTIC_PASSWORD=
KIBANA_PASSWORD=
ES_PORT=127.0.0.1:9200

docker compose up -d

Dans ce modèle, je veille à trois choses: une seule version pour tous les services, des mots de passe corrects dans le fichier d’environnement, et un port Elasticsearch limité à 127.0.0.1 si je travaille en local. Exposer 9200 sur toutes les interfaces n’apporte rien pour un test de développement et augmente inutilement la surface d’attaque.

Au premier démarrage, les versions récentes d’Elasticsearch activent la sécurité automatiquement: certificats TLS générés, mot de passe initial pour l’utilisateur elastic, et token d’enrôlement pour Kibana. C’est pratique, mais cela signifie aussi qu’il faut vérifier la connexion de Kibana au lieu de supposer qu’elle se fera toute seule.

Pour un simple test de démarrage local, la commande de quickstart fournie par Elastic peut aussi servir de point d’entrée, mais elle reste orientée validation rapide et ne remplace pas une vraie chaîne ELK dès qu’on veut parser et router des logs. Une fois ce socle en place, la question suivante devient celle du déploiement plus stable sur un hôte Linux classique.

Installer sur Linux avec des paquets système

Quand je vise un serveur durable, je préfère les paquets système pour Elasticsearch, Kibana et Logstash. On obtient une intégration plus nette avec systemd, des emplacements de configuration standard et une exploitation plus simple au quotidien, surtout si plusieurs personnes doivent reprendre l’environnement.

Sur Debian ou Ubuntu, l’approche la plus propre consiste à ajouter le dépôt officiel puis à installer les paquets. Sur les distributions RPM, la logique est la même. L’intérêt n’est pas seulement l’installation elle-même: c’est aussi la façon dont les services sont démarrés, supervisés et remis en route après un reboot.

1. J’installe Elasticsearch en premier et je le laisse initialiser sa sécurité.
2. Je récupère ensuite Kibana et je l’enrôle auprès du cluster Elasticsearch.
3. Je termine par Logstash, en plaçant ses pipelines dans le répertoire de configuration prévu par le paquet.
4. Je démarre les services avec systemd et je vérifie les journaux avant de passer à la suite.

Le point qui change souvent la vie, c’est de comprendre que Kibana ne se “branche” pas comme un simple site web. Sur les versions récentes, il faut compter avec la sécurité intégrée, l’enrôlement et les certificats. Ce n’est pas un obstacle, mais ce n’est pas non plus un simple service start sans contexte.

Si vous utilisez l’archive tar.gz plutôt qu’un paquet, gardez aussi en tête la JVM et les chemins de configuration. Sur Logstash, le sujet Java reste à surveiller; avec les paquets officiels, une partie de cette complexité est absorbée par la distribution. Quand Elasticsearch et Kibana répondent proprement, il reste le point qui donne de la valeur à ELK: la chaîne d’ingestion et de transformation.

Brancher Logstash sur un premier flux

Logstash est utile quand les logs ne sont pas déjà propres, structurés ou prêts à être exploités. C’est là que je le privilégie: parsing de texte brut, enrichissement GeoIP, normalisation ECS, routage vers plusieurs index, ou séparation des événements selon leur type.

Elastic décrit Logstash comme une chaîne en trois étapes: inputs, filters, outputs. J’aime garder cette logique très visible dans la configuration, parce qu’elle rend les erreurs beaucoup plus simples à localiser. Si le flux entre, mais que rien ne sort, le problème n’est pas au même endroit que si la lecture échoue dès le départ.

input {
  file {
    path => "/var/log/app.log"
    start_position => "beginning"
    sincedb_path => "/dev/null"
  }
}

filter {
  json { source => "message" }
}

output {
  stdout { codec => rubydebug }
}

Ce premier pipeline est volontairement minimal. Il sert à valider la lecture du fichier, la transformation de base et la sortie console avant de brancher un output Elasticsearch. Une fois que ce test passe, je remplace la sortie stdout par une destination Elasticsearch adaptée au cluster, avec authentification et chiffrement si l’environnement est sécurisé.

Sur Debian et RPM, les pipelines Logstash se placent dans /etc/logstash/conf.d avec l’extension .conf. C’est un détail banal, mais c’est l’un des pièges les plus fréquents: un fichier mal nommé ou déposé au mauvais endroit donne l’impression que Logstash “ne lit rien”, alors que le problème est purement structurel.

Si vos logs sont déjà proches du format JSON ou ECS, je réduis le filtrage au strict nécessaire. Logstash ne doit pas devenir une usine à gaz; il doit surtout faire le travail que votre source d’événements ne sait pas faire proprement. Et avant de brancher des logs de production, je vérifie toujours les mêmes erreurs, parce que ce sont elles qui font perdre le plus de temps.

Les erreurs qui font perdre du temps au premier démarrage

Les premiers échecs sur une installation ELK viennent rarement d’un bug exotique. Ils viennent presque toujours d’un détail d’exploitation: mémoire insuffisante, versions mélangées, ports exposés n’importe comment ou fichiers de configuration déposés au mauvais endroit.

• Je ne mélange pas les versions entre Elasticsearch, Kibana et Logstash.
• Je ne sous-dimensionne pas Docker Desktop: 4 Go, c’est le minimum utile, pas un confort.
• Je ne laisse pas 9200 ouvert sur le réseau si le cluster sert seulement en local.
• Je ne lance pas Kibana en supposant qu’Elasticsearch se configurerait tout seul: la sécurité et l’enrôlement comptent.
• Je vérifie que les pipelines Logstash sont bien dans /etc/logstash/conf.d et qu’ils portent bien l’extension .conf.
• Je garde des mots de passe simples mais valides si j’utilise l’exemple Docker fourni par Elastic, parce que les caractères spéciaux ne passent pas toujours dans ce contexte.

Le symptôme le plus trompeur, c’est souvent Kibana qui affiche une page de connexion sans qu’on sache si le problème vient de l’authentification, du token d’enrôlement ou simplement d’un Elasticsearch encore en train de démarrer. Mon réflexe est de lire les logs dans l’ordre: Elasticsearch, puis Kibana, puis Logstash. Cela évite de chercher au mauvais endroit.

Une fois ces points verrouillés, la transition vers la préproduction devient beaucoup plus simple que la première mise en route.

Ce que je garde en tête avant de brancher les vrais logs

Quand je passe d’un lab à un environnement sérieux, je ne cherche pas à “faire marcher ELK” au sens minimal. Je veux surtout une base exploitable: chiffrement maîtrisé, accès limités, rotation des données, et assez de ressources pour absorber les pics sans casser l’ingestion.

Je regarde toujours quatre choses avant d’ouvrir l’accès à d’autres équipes: les sauvegardes via snapshots, la rétention via index lifecycle management, les droits avec des comptes séparés, et la surveillance du disque et du tas JVM. Sur Elasticsearch, le disque plein est souvent plus dangereux qu’un simple ralentissement; sur Logstash, une pipeline mal réglée peut créer un bouchon discret qui se voit trop tard.

Si je devais résumer ma méthode, je dirais: Docker Compose pour apprendre vite, paquets système pour stabiliser, Logstash pour transformer ce qui ne doit pas partir brut, et sécurité active avant d’ouvrir Kibana aux équipes. C’est ce cadre simple qui fait la différence entre une démonstration fragile et une vraie base d’observabilité.