Logstash en production : files persistantes, DLQ et multi-pipelines

1. Ne rien perdre : la file persistante #

Mémoire ou disque.

Le problème #

Par défaut, Logstash garde les événements en transit dans une file en mémoire (queue.type: memory) : un arrêt brutal les perd. La file persistante (PQ) les écrit sur disque entre les inputs et les filtres : ils survivent à un redémarrage et absorbent les pics quand Elasticsearch ralentit.

Configuration #

# config/pipelines.yml
- pipeline.id: web
  path.config: /usr/share/logstash/pipeline/web.conf
  queue.type: persisted
  queue.max_bytes: 4gb          # au-delà : contre-pression vers les inputs
  path.queue: /var/lib/logstash/queue
  dead_letter_queue.enable: true

Erreur courante : Croire que la PQ protège de tout : elle ne remplace ni un disque fiable, ni un émetteur qui sait réémettre. Un input UDP (syslog) perd toujours ce qui arrive pendant un arrêt ; placez Kafka devant si la perte est inacceptable.

Bonne pratique : La livraison est « au moins une fois » : en cas de reprise, un événement peut être réindexé. Calculez un identifiant stable (filtre fingerprint) et passez-le en document_id pour rendre l'écriture idempotente.

2. La dead letter queue #

Garder les rejets.

Principe #

Quand Elasticsearch refuse un document (erreur 400 ou 404, typiquement un conflit de mapping), la sortie elasticsearch l'écrit dans la DLQ au lieu de le jeter, avec la raison du refus. On le corrige ensuite et on le réinjecte.

# Pipeline de reprise : lit la DLQ du pipeline « web »
input {
  dead_letter_queue {
    path => "/usr/share/logstash/data/dead_letter_queue"
    pipeline_id => "web"
    commit_offsets => true
  }
}
filter {
  # la raison du rejet : [@metadata][dead_letter_queue][reason]
  mutate { convert => { "status" => "integer" } }
}
output { elasticsearch { hosts => ["http://elasticsearch:9200"] data_stream => true } }

À savoir : Seuls les refus « définitifs » vont en DLQ ; les erreurs temporaires (429, 503) sont réessayées sans fin par la sortie : c'est la contre-pression qui protège alors les données.

3. Plusieurs pipelines #

Isoler les flux.

pipelines.yml #

Un seul gros pipeline mélange les flux : un filtre lent ou une sortie en panne bloque tout. pipelines.yml déclare plusieurs pipelines indépendants, chacun avec ses workers, sa file et sa configuration.

- pipeline.id: entree
  config.string: |
    input { beats { port => 5044 } }
    output {
      if [event][dataset] == "nginx.access" { pipeline { send_to => ["web"] } }
      else if [event][category] == "authentication" { pipeline { send_to => ["securite"] } }
      else { pipeline { send_to => ["autres"] } }
    }
- pipeline.id: web
  path.config: /etc/logstash/conf.d/web.conf     # input { pipeline { address => "web" } }
  pipeline.workers: 4
- pipeline.id: securite
  path.config: /etc/logstash/conf.d/securite.conf
  queue.type: persisted

4. Performances #

Workers, lots, JVM.

Les réglages #

curl -s localhost:9600/_node/stats/pipelines?pretty | jq '.pipelines.web.events'
curl -s localhost:9600/_node/hot_threads?human=true | head -40

Bonne pratique : Mesurez avant de régler : comparez events.in, events.out et duration_in_millis par filtre dans _node/stats pour trouver le filtre qui coûte.