30 - Logstash en production : architecture et bonnes pratiques
Ce que tu vas apprendre
- Les architectures de production (HA, bufferisee, multi-tier)
- Dimensionner Logstash selon le volume de donnees
- Configurer le load balancing devant Logstash
- Les bonnes pratiques de déploiement
- Une checklist de pre-production
Prerequisites
- Tous les articles précédents (celui-ci rassemble tout)
Du lab a la prod : ce qui change
En dev, un seul Logstash suffit. En production, il faut répondre a trois questions :
- Que se passe-t-il si Logstash tombe ?
- Que se passe-t-il si le volume double ?
- Que se passe-t-il si Elasticsearch est temporairement indisponible ?
Les architectures qui suivent repondent a ces questions.
Architecture 1 : deux Logstash derrière un load balancer
La plus simple pour de la haute disponibilité.
┌──────────┐ ┌──────────────┐ ┌──────────────┐
│ Filebeat │ │ Nginx │ │ Logstash 1 │
│ Filebeat │────>│ (LB) │────>│ workers: 4 │──┐
│ Filebeat │ │ :5044 │ │ heap: 2g │ │ ┌──────────────┐
└──────────┘ │ │ └──────────────┘ ├──>│ Elasticsearch│
│ round-robin │ │ │ cluster │
│ │ ┌──────────────┐ │ └──────────────┘
│ │────>│ Logstash 2 │──┘
│ │ │ workers: 4 │
└──────────────┘ │ heap: 2g │
└──────────────┘Filebeat pointe vers le load balancer. Le LB distribue les connexions entre les deux Logstash. Si un Logstash tombe, le LB redirige tout vers l'autre.
Filebeat avec load balancing natif
Filebeat sait faire du load balancing sans Nginx :
yaml# filebeat.yml
output.logstash:
hosts: ["logstash-1:5044", "logstash-2:5044"]
loadbalance: true
worker: 2
loadbalance: true repartit les événements entre les deux Logstash. Si un tombe, Filebeat envoie tout a l'autre. Pas besoin de load balancer externe.
Architecture 2 : Kafka comme buffer
Pour les volumes eleves ou quand la fiabilité est critique.
┌──────────┐ ┌────────────────────────┐ ┌──────────────┐
│ Filebeat │ │ Kafka │ │ Logstash 1 │
│ Filebeat │────>│ │────>│ consumer │──┐
│ Filebeat │ │ topic: logs-raw │ │ group: │ │
└──────────┘ │ partitions: 6 │ │ logstash │ │ ┌──────────────┐
│ retention: 72h │ └──────────────┘ ├─>│ Elasticsearch│
│ replication: 3 │ │ │ cluster │
│ │ ┌──────────────┐ │ └──────────────┘
│ │────>│ Logstash 2 │──┘
│ │ │ consumer │
└────────────────────────┘ │ group: │
│ logstash │
└──────────────┘Kafka absorbe les pics. Si tu as un burst de 100 000 events/s mais que Logstash ne traite que 50 000/s, Kafka stocke le surplus. Logstash rattrape quand le pic est passe.
Avec un retention: 72h, tu as 3 jours pour reagir si Logstash est en panne. Aucun événement perdu.
Les deux Logstash sont dans le meme consumer group. Kafka repartit les partitions : Logstash 1 prend les partitions 0-2, Logstash 2 prend les partitions 3-5. Si un Logstash tombe, Kafka rebalance les partitions sur l'autre.
Architecture 3 : multi-tier
Pour les organisations avec des exigences de séparation et de scalabilité.
┌─────────┐ ┌─────────────┐ ┌─────────────┐ ┌──────────────┐
│ Beats │ │ Tier 1 │ │ Tier 2 │ │ │
│ (edge) │────>│ Logstash │────>│ Logstash │────>│ Elasticsearch│
│ │ │ (ingest) │ │ (enrich) │ │ │
└─────────┘ │ │ │ │ └──────────────┘
│ - reception │ │ - GeoIP │
│ - parsing │ │ - lookups │
│ - routing │ │ - classify │
└─────────────┘ └─────────────┘Le Tier 1 fait le travail leger (parsing, routing). Le Tier 2 fait le travail lourd (enrichissement, lookups en base). Tu scales chaque tier indépendamment.
La communication entre les tiers peut etre directe (Logstash-to-Logstash via TCP) ou via Kafka.
Dimensionnement
Regles de base
| Volume | Logstash instances | CPU | RAM | Heap |
|---|---|---|---|---|
| < 5 000 events/s | 1 | 2 cores | 4 Go | 1 Go |
| 5 000 - 20 000 events/s | 2 | 4 cores chacun | 8 Go | 2 Go |
| 20 000 - 50 000 events/s | 2-4 | 8 cores chacun | 16 Go | 4 Go |
| > 50 000 events/s | 4+ (avec Kafka) | 8+ cores | 16+ Go | 4-8 Go |
Ces chiffres supposent un pipeline standard (Grok + Date + GeoIP + Mutate + ES output). Si tu as des filtres Ruby complexes ou des lookups jdbc_static, prevois plus de CPU.
Calculer le debit nécessaire
Nombre de serveurs x lignes de log par seconde par serveur
= events/seconde a traiter
Exemple :
20 serveurs x 500 lignes/s = 10 000 events/s
→ 2 Logstash avec 4 workers chacunLe disk pour la persistent queue
events/s x taille moyenne d'un event x duree de retention queue
= espace disque necessaire
Exemple :
10 000 events/s x 1 Ko/event x 3600s (1h de buffer)
= 36 Go de persistent queueEn pratique, 10 a 50 Go de SSD pour la persistent queue suffisent pour la plupart des deployments.
Configuration de production
logstash.yml
yaml# logstash/config/logstash.yml
# API
api.http.host: "0.0.0.0"
api.http.port: 9600
# Rechargement
config.reload.automatic: true
config.reload.interval: 30s
# Logs
log.level: info
log.format: json
# Dead Letter Queue
dead_letter_queue.enable: true
dead_letter_queue.max_bytes: 2048mb
# Pipeline par defaut
pipeline.ordered: auto
pipelines.yml
yaml- pipeline.id: main
path.config: "/usr/share/logstash/pipeline/main.conf"
pipeline.workers: 8
pipeline.batch.size: 250
pipeline.batch.delay: 10
queue.type: persisted
queue.max_bytes: 10gb
queue.drain: true
JVM options
# jvm.options ou LS_JAVA_OPTS
-Xms4g
-Xmx4g
-XX:+UseG1GC
-XX:G1ReservePercent=25G1GC est le garbage collector recommande pour les heaps > 2 Go. G1ReservePercent=25 garde 25% de la heap en reserve pour éviter les pauses longues.
Checklist pre-production
Infrastructure
- Logstash en HA (2 instances minimum)
- Persistent queue activee
- DLQ activee avec une taille suffisante
- Volumes Docker pour les donnees Logstash (queue, DLQ, sincedb)
- Heap JVM = min(4 Go, 50% de la RAM)
- SSD pour la persistent queue
- Monitoring actif (Metricbeat ou API polling)
Pipeline
- Index templates définis explicitement (pas de dynamic mapping)
- Secrets dans le keystore (pas en clair dans les .conf)
- TLS active sur tous les inputs et outputs
- Health checks supprimes (drop /health, /ready)
- Tags de debug supprimes
- stdout supprime ou conditionnel
- Grok patterns optimises (ancres, Dissect quand possible)
Opérations
- Alertes configurees (heap > 85%, throughput chute, queue pleine)
- Procedure de rollback documentee (revenir a l'ancien .conf)
- Tests automatises en CI
- Log rotation pour les logs Logstash eux-memes
- Runbook pour les incidents courants
Elasticsearch
- Cluster ES en HA (3 noeuds minimum)
- ILM configure pour la retention
-
http_compression: truesur l'output - Retries configures avec backoff
Ce que j'ai appris en production
Quelques leçons apprises sur paltemps.fr apres deux ans de Logstash en prod :
Le reload a chaud est fiable. config.reload.automatic: true fonctionne bien. Mais en production, je mets config.reload.interval: 30s au lieu de 3s. Moins de charge CPU pour la vérification des fichiers.
La persistent queue sauve des vies. On a eu un Elasticsearch indisponible pendant 20 minutes (upgrade de cluster). Sans la persistent queue, 20 minutes de logs perdues. Avec, zero perte. Les événements ont ete bufferises sur disque et envoyes quand ES est revenu.
Le monitoring est non-negociable. Un Logstash qui rame silencieusement est pire qu'un Logstash qui crash. Au moins un crash te previent. Un pipeline qui prend du retard sans alerte, tu le decouvres quand un collegue dit "les dashboards sont vides depuis hier".
Les index templates sont obligatoires. Le dynamic mapping d'Elasticsearch a créé un champ status en text au lieu de keyword parce que le premier document contenait "OK" au lieu de 200. Tous les dashboards bases sur des aggregations de status ont casse. Un template aurait évité ca.
Résumé
- En production : 2 Logstash minimum, avec persistent queue et DLQ
- Kafka comme buffer pour les volumes > 20 000 events/s ou la fiabilité critique
- Dimensionnement : 1 instance pour < 5 000 events/s, scale horizontalement au-delà
- Heap JVM : 1-4 Go selon le volume, jamais > 50% de la RAM
- La checklist couvre l'infra, le pipeline, les opérations et Elasticsearch
- Monitoring et alertes sont non-negociables
Precedent : 29 - Cas pratique : enrichissement | Suivant : 31 - Glossaire