📊 ELK / Elastic Stack – Logs, Recherche & Dashboards

Flux ELK (mental model)

[Apps / Servers / Containers]
   │ logs (files, stdout, syslog)
   ▼
[Agents]
  - Filebeat / Elastic Agent
  - Fluent Bit (si K8s)
   │
   ▼
[Ingest layer]
  - Logstash (grok, enrich, route)
  - Elasticsearch ingest pipelines (option)
   │
   ▼
[Elasticsearch]
  - index / data stream
  - mappings + analyzers
  - shards + replicas
  - ILM (retention)
   │
   ▼
[Kibana]
  - Discover (recherche)
  - Dashboards (Lens)
  - Alerting
        

Objectif : réduire le temps “incident → cause → fix” en rendant les logs consultables en 10 secondes.

Pièges classiques (et comment les éviter)

Nommage d’index (lisible + ILM)

Exemples:
- logs-nginx-prod-YYYY.MM.DD
- logs-django-prod-YYYY.MM.DD
- logs-system-dev-YYYY.MM.DD

Ou en data streams (recommandé):
- logs-nginx-prod (data stream) -> backing indices gérés par rollover/ILM
        

But : query facile + rétention facile (ILM) + séparation prod/dev.

Champs standard (minimum viable schema)

Qualité des données (ELK “pro”)

• Décider : JSON logs ou texte + grok (JSON recommandé).
• Normaliser niveaux : DEBUG/INFO/WARN/ERROR.
• Ajouter request_id dans Nginx + app (corrélation).
• Éviter champs dynamiques (risque mapping explosion).

Pré-requis Linux (très fréquent)

# Elasticsearch a souvent besoin de :
sudo sysctl -w vm.max_map_count=262144
# (persist: /etc/sysctl.conf)

# Vérifier mémoire/disque:
free -h
df -h
        

Si ES refuse de démarrer, vm.max_map_count est souvent la cause.

Checklist production

Ports courants

9200 : Elasticsearch HTTP API
9300 : Elasticsearch transport (cluster interne)
5601 : Kibana
5044 : Logstash beats input
        

En prod : éviter d’exposer 9200 publiquement (WAF/VPN + auth + TLS).

Collecte logs app Django

filebeat.inputs:
- type: filestream
  id: django-app
  paths:
    - /opt/app/logs/django.log
  fields:
    service: django
    env: prod
  fields_under_root: true

processors:
  - add_host_metadata: ~
  - add_cloud_metadata: ~
        

Si tes logs Django sont JSON → tu peux parser directement (moins de grok).

Multiline (stack traces)

parsers:
  - multiline:
      type: pattern
      pattern: '^\['
      negate: true
      match: after
        

Objectif : une exception Python = un seul “event” indexé.

Best practices agents

• Ajouter service, env, host en champs standard.
• Limiter bruit : DEBUG en prod seulement si nécessaire.
• Rotation logs côté OS/app + vérifier permissions.
• Éviter données sensibles (tokens, passwords) dans logs.

Grok (si logs texte)

filter {
  if [service] == "nginx" {
    grok {
      match => { "message" => "%{IPORHOST:client_ip} - %{DATA:remote_user} \[%{HTTPDATE:ts}\] \"%{WORD:method} %{DATA:uri} HTTP/%{NUMBER:http_version}\" %{NUMBER:status} %{NUMBER:bytes}" }
    }
  }
}
        

Grok est puissant mais coûteux : si possible, préfère logs JSON.

Enrichissement (geoip + fingerprint)

filter {
  if [client_ip] {
    geoip { source => "client_ip" }
  }
  fingerprint {
    source => ["message"]
    target => "event_hash"
    method => "SHA1"
  }
}
        

Routing vers index différents

output {
  if [service] == "django" {
    elasticsearch { index => "logs-django-%{env}-%{+YYYY.MM.dd}" }
  } else if [service] == "nginx" {
    elasticsearch { index => "logs-nginx-%{env}-%{+YYYY.MM.dd}" }
  } else {
    elasticsearch { index => "logs-misc-%{env}-%{+YYYY.MM.dd}" }
  }
}
        

Mapping : éviter les surprises

- keyword : filtres exacts (service, env, status)
- text    : full-text (message)
- date    : @timestamp
- long    : bytes, latency_ms
        

Danger : champs dynamiques non maîtrisés → “mapping explosion”.

Shards/replicas : l’erreur n°1

• Trop de shards = surcharge metadata + cluster lent.
• Pas assez = index trop gros, queries lentes.
• ILM + rollover = stratégie moderne (index “petits”).

Requêtes utiles (concept Kibana)

service: nginx AND env: prod AND http.response.status_code: >=500
request_id: "abc123"
message: "timeout" AND NOT uri: "/health"
        

Lens = graphiques rapides

• Time series : erreurs/minute, latence p95.
• Top values : top endpoints, top IPs.
• Breakdown : par env/service.

Dashboards “prod web” recommandés

• HTTP 5xx (par endpoint)
• Latence p95 (par endpoint)
• Top IP / UA
• Django ERROR logs (stack traces)
• DB timeouts / slow queries (si loggués)

Alerting (concept)

Alert 1: 5xx rate > threshold for 5 minutes
Alert 2: p95 latency > threshold
Alert 3: login failures spike (security)
        

Commencer simple, sinon trop d’alertes = ignorées.

Causes fréquentes

Fix rapides (pragmatiques)

• Activer ILM + réduire rétention (si disque).
• Réduire shards + rollover (indices plus petits).
• Passer vers logs JSON pour réduire grok.
• Limiter champs dynamiques (templates).

Playbook incident ELK

1. Réduire time range + filtre service/env.
2. Checker disque + watermark.
3. Observer ingestion rate (agents/logstash).
4. Identifier index “heavy” (trop gros / trop shards).
5. Appliquer ILM / rollover / delete policy.