#Fix : Elasticsearch refresh_interval (consumer Kafka lent)

#Contexte

Le consumer Kafka central-job-show (groupe ShowStream) indexe chaque message dans ES avec ?refresh=wait_for. ES bloque jusqu’au prochain refresh de l’index avant de retourner — par défaut 1 seconde, soit ~1 msg/sec max.

Ce paramètre est configurable dynamiquement sur les index ouverts, sans redémarrage ES ni applicatif.

#Symptôme

• Lag Kafka ShowStream qui croît ou stagne (~200 msgs/10min au lieu de ~2000+)
• Logs abandoned subscription because consuming was taking too long dans central-job-show

#Fix — réduire refresh_interval

#Appliquer (200ms)

curl -X PUT "http://<es-host>:9200/cineges-*/_settings" \
  -H 'Content-Type: application/json' \
  -d '{"index.refresh_interval": "200ms"}'

Résultat observé en qualif : lag résorbé ~5x plus vite (de ~200 à ~1000 msgs/10min).

#Revenir au défaut (1s)

curl -X PUT "http://<es-host>:9200/cineges-*/_settings" \
  -H 'Content-Type: application/json' \
  -d '{"index.refresh_interval": "1s"}'

#Vérifier la valeur active

curl -s "http://<es-host>:9200/cineges-show-*/_settings/index.refresh_interval"

#Application en production

Remplacer <es-host> par l’endpoint ES du cluster cible (ex. es6-headless.prod-central.svc.cluster.local).

La commande est idempotente et s’applique à chaud sur tous les index cineges-* ouverts.

#Limites

• Ne supprime pas le wait_for — c’est un palliatif. La vraie cause est l’utilisation d’ES comme base de données synchrone dans le pattern Kafka→ES.
• Un refresh_interval trop court (< 100ms) augmente la charge IO sur Ceph.
• La valeur 200ms est un bon compromis : cohérence des données dans 200ms max, charge Ceph acceptable.