ELKObservabilitéInfrastructure

Déployer une stack ELK de A à Z : les décisions clés

11 mars 2026 · Sphinx-Digital

Une stack ELK mal dimensionnée tient en dev et s’effondre en production. Les décisions d’architecture prises au démarrage conditionnent la tenue à l’échelle. Voici les plus importantes.

Beats ou Logstash pour la collecte ?

Filebeat est léger et fait une chose bien : lire des fichiers de logs et les envoyer. Il consomme très peu de ressources sur les hôtes monitored.

Logstash est un ETL complet : il peut filtrer, enrichir, transformer, et router vers plusieurs destinations. Son coût en ressources est significativement plus élevé.

Architecture recommandée :

[Hosts] → Filebeat → [Kafka] → Logstash → Elasticsearch

L’interposition de Kafka entre Filebeat et Logstash crée un buffer qui absorbe les pics d’ingestion et découple la collecte du traitement.

La décision de sharding Elasticsearch

PUT /logs-2026-03
{
  "settings": {
    "number_of_shards": 5,
    "number_of_replicas": 1
  }
}

Règle empirique : viser des shards de 20-50 Go en état stable. Un shard trop petit crée une surcharge de métadonnées ; un shard trop grand rend la récupération après incident plus longue.

Ne pas modifier le nombre de shards primaires après création (contrairement aux réplicas). Planifiez avant de déployer.

Index lifecycle management (ILM)

ILM automatise le cycle de vie de vos indices : hot (données récentes, requêtes fréquentes) → warm (moins requêté, compressé) → cold (archivage) → delete.

PUT _ilm/policy/logs-policy
{
  "policy": {
    "phases": {
      "hot":  { "actions": { "rollover": { "max_size": "50GB" } } },
      "warm": { "min_age": "7d", "actions": { "shrink": { "number_of_shards": 1 } } },
      "cold": { "min_age": "30d", "actions": { "freeze": {} } },
      "delete": { "min_age": "90d", "actions": { "delete": {} } }
    }
  }
}

Kibana : les dashboards qui comptent

Les dashboards les plus utiles ne sont pas les plus beaux — ce sont ceux qui répondent aux questions que vous posez le plus souvent lors d’un incident :

  • Taux d’erreur par service sur les 30 dernières minutes
  • Top 10 des endpoints les plus lents
  • Distribution des codes HTTP dans le temps
  • Volume de logs par niveau (ERROR, WARN, INFO) par service

Sécuriser la stack

Par défaut, Elasticsearch n’a pas d’authentification. En production, activez la sécurité X-Pack (incluse gratuitement depuis ES 7.x) :

# elasticsearch.yml
xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true

Puis créez des utilisateurs avec les rôles appropriés — ne laissez pas elastic:changeme traîner en production.

Notre formation Elastic Stack couvre le déploiement complet avec des labs sur cluster réel.