22 - Monitoring Logstash : metriques et alertes

Ce que tu vas apprendre

• Les endpoints de l'API de monitoring Logstash
• Les metriques a surveiller (JVM, throughput, queues)
• Configurer Metricbeat pour collecter les metriques
• Les seuils d'alerte recommandes
• Lire les hot threads pour diagnostiquer les lenteurs

Prerequisites

• Un pipeline en fonctionnement
• Avoir compris le tuning (voir article 21)

Pourquoi monitorer Logstash

Un pipeline qui tourne ne veut pas dire un pipeline qui va bien. J'ai eu un Logstash en prod qui traitait 10 000 events/seconde pendant des semaines. Puis un jour, le heap usage a grimpe a 95%, le garbage collector s'est mis a tourner en boucle, et le throughput est tombe a 500 events/seconde. Sans monitoring, on aurait mis des heures a comprendre. Avec les metriques, on a vu le problème en 2 minutes : un nouveau format de log generait des événements 10x plus gros que la normale.

L'API de monitoring

Logstash expose une API REST sur le port 9600.

Sante générale

bashcurl -s http://localhost:9600/ | python3 -m json.tool

json{
  "host": "logstash",
  "version": "8.17.0",
  "status": "green",
  "pipeline": {
    "workers": 4,
    "batch_size": 125
  }
}

status : green (tout va bien), yellow (degradation), red (problème).

Statistiques du noeud

bashcurl -s http://localhost:9600/_node/stats | python3 -m json.tool

Réponse (abregee, les champs importants) :

json{
  "jvm": {
    "mem": {
      "heap_used_percent": 42,
      "heap_used_in_bytes": 440401920,
      "heap_max_in_bytes": 1073741824
    },
    "gc": {
      "collectors": {
        "young": { "collection_count": 234, "collection_time_in_millis": 1200 },
        "old": { "collection_count": 3, "collection_time_in_millis": 450 }
      }
    },
    "threads": {
      "count": 42
    }
  },
  "process": {
    "cpu": {
      "percent": 35
    }
  },
  "events": {
    "in": 1500000,
    "filtered": 1500000,
    "out": 1500000,
    "duration_in_millis": 450000,
    "queue_push_duration_in_millis": 2000
  }
}

Statistiques par pipeline

bashcurl -s http://localhost:9600/_node/stats/pipelines | python3 -m json.tool

Donne les metriques par pipeline quand tu utilises des pipelines multiples. On l'a vu dans l'article 21.

Hot threads

bashcurl -s http://localhost:9600/_node/hot_threads?human=true

Affiche les threads qui consomment le plus de CPU. Si un thread passe 80% de son temps dans org.jruby.RubyRegexp, c'est Grok qui rame.

Les metriques a surveiller

Metriques critiques

Metriques de debit

Si events.in >> events.out, les événements s'accumulent. Soit la queue grandit (persistent), soit ils sont droppes (memory queue pleine).

Metriques JVM

Les GC young sont normales et rapides (quelques ms). Les GC old sont lentes (dizaines/centaines de ms) et bloquent le pipeline. Si le nombre de GC old augmente, la heap est trop petite.

Monitoring avec Metricbeat

Pour historiser les metriques et les afficher dans Kibana, utilise Metricbeat avec le module Logstash.

compose.yaml avec Metricbeat

yamlservices:
  # ... elasticsearch, logstash, kibana ...

  metricbeat:
    image: docker.elastic.co/beats/metricbeat:8.17.0
    container_name: metricbeat
    user: root
    volumes:
      - ./metricbeat/metricbeat.yml:/usr/share/metricbeat/metricbeat.yml:ro
    depends_on:
      elasticsearch:
        condition: service_healthy
    command: ["metricbeat", "-e", "-strict.perms=false"]

metricbeat.yml

yamlmetricbeat.modules:
  - module: logstash
    metricsets: ["node", "node_stats"]
    period: 10s
    hosts: ["logstash:9600"]

  - module: elasticsearch
    metricsets: ["node", "node_stats"]
    period: 10s
    hosts: ["elasticsearch:9200"]

output.elasticsearch:
  hosts: ["elasticsearch:9200"]

setup.kibana:
  host: "kibana:5601"

setup.dashboards.enabled: true

Metricbeat collecte les metriques de Logstash toutes les 10 secondes et les envoie dans Elasticsearch. Les dashboards pre-configures apparaissent dans Kibana sous "Dashboard" > "Metricbeat Logstash".

Alertes recommandees

En production, configure des alertes dans Kibana (Stack Management > Rules) :

La première alerte a configurer est "heap critique". Si la heap atteint 95%, le prochain pas c'est l'OutOfMemoryError et le crash. Sur paltemps.fr, c'est la seule alerte qui page en dehors des heures de bureau.

Diagnostic rapide : checklist

Quand quelque chose ne va pas, dans cet ordre :

1. curl localhost:9600/          → status green/yellow/red ?
2. curl localhost:9600/_node/stats
   → heap_used_percent > 80% ?  → augmenter la heap
   → gc.old en augmentation ?    → heap trop petite ou fuite memoire
   → events.in > events.out ?   → bottleneck output ou queue
3. curl localhost:9600/_node/hot_threads
   → quel thread consomme ?     → Grok, Ruby, output ES ?
4. docker compose logs logstash --tail 50
   → erreurs Elasticsearch ?    → mapping conflict, cluster red
   → _grokparsefailure ?        → nouveau format de log

Résumé

• L'API de monitoring sur le port 9600 expose la sante, les stats et les hot threads
• Les metriques critiques : heap usage, GC old, events in/out, queue size
• Metricbeat avec le module Logstash historise les metriques dans Elasticsearch
• Les dashboards Metricbeat pre-configures donnent une vue immediate dans Kibana
• Première alerte a configurer : heap > 85% pendant 5 minutes
• Diagnostic rapide : status -> stats -> hot_threads -> logs

Precedent : 21 - Performance et tuning | Suivant : 23 - Dead Letter Queue

Sources

• Monitoring Logstash - elastic.co
• Monitoring APIs - elastic.co
• Metricbeat Logstash Module - elastic.co