Surveiller les workers asynchrones : KPIs Celery, Redis et OpenTelemetry

Marketing team discussing marketing terms in front of a white board with post-its
Apprenez à définir, suivre et interpréter les indicateurs clés de performance des tâches Celery et du cache Redis grâce à OpenTelemetry.

Introduction

Les architectures Python modernes s’appuient largement sur Celery pour exécuter des tâches en arrière‑plan. Pourtant, la visibilité sur ces workers reste souvent limitée : les erreurs apparaissent dans les logs, tandis que les métriques Redis sont observées séparément. Cette dissociation complique le diagnostic et allonge le MTTR. Dans cet article, nous détaillons les indicateurs clés à suivre, comment les exposer via OpenTelemetry, et comment interpréter les corrélations pour prendre des décisions éclairées.

1. Identifier les KPIs essentiels pour les workers Celery

1.1. Taux d’erreur (error_rate)

Le taux d’erreur mesure le pourcentage de tâches qui se terminent en exception. Un pic soudain indique souvent un problème de dépendance ou de ressource.

1.2. Temps moyen de traitement (mean_task_latency)

Le latence moyenne reflète la durée entre la mise en file d’une tâche et son achèvement. Une hausse peut signaler un goulot d’étranglement au niveau du broker ou du worker.

1.3. Nombre de retries (retry_count)

Le nombre de retries montre combien de fois une tâche a été relancée. Un taux élevé peut masquer des erreurs transitoires mais indique aussi une charge supplémentaire.

1.4. Charge du broker Redis (redis_cpu, redis_memory)

Les métriques CPU et mémoire de Redis permettent de détecter la saturation du broker, qui impacte directement la latence des tâches.

Astuce : regroupez ces KPIs dans un tableau de bord unique afin de visualiser les corrélations en temps réel.

2. Instrumenter Celery et Redis avec OpenTelemetry

2.1. Ajouter le SDK OpenTelemetry à votre projet Python

pip install opentelemetry-sdk opentelemetry-instrumentation-celery opentelemetry-instrumentation-redis

2.2. Configurer le tracer pour Celery

from opentelemetry import trace
from opentelemetry.instrumentation.celery import CeleryInstrumentor

trace.set_tracer_provider(TracerProvider())
CeleryInstrumentor().instrument()

2.3. Exporter les métriques vers un backend compatible (ex. Prometheus)

from opentelemetry.exporter.prometheus import PrometheusMetricsExporter
exporter = PrometheusMetricsExporter(port=8000)

2.4. Instrumenter le client Redis

from opentelemetry.instrumentation.redis import RedisInstrumentor
RedisInstrumentor().instrument()

Avec ces deux instrumentations, chaque appel Redis et chaque tâche Celery génèrent des spans et des metrics partageant le même trace_id, ce qui rend la corrélation triviale.

3. Corréler les erreurs Celery aux métriques Redis

3.1. Utiliser le trace_id comme clé de jointure

Lorsque OpenTelemetry crée un span pour une tâche Celery, il transmet le trace_id aux appels Redis sous‑jacent. En agrégeant les données dans Prometheus ou Grafana, on peut créer une requête du type :

sum by (trace_id) (rate(celery_task_failed_total[5m]))
  /
sum by (trace_id) (rate(redis_cpu_seconds_total[5m]))

Cette requête montre le ratio d’erreurs Celery par unité de CPU consommée par Redis, révélant les scénarios où la surcharge du broker entraîne des échecs.

3.2. Dashboard recommandé

  • Panel 1 : taux d’erreur Celery (graph line)
  • Panel 2 : utilisation CPU Redis (graph line)
  • Panel 3 : tableau croisé trace_id → error_rate / redis_cpu
  • Panel 4 : histogramme des latences de tâche par statut (succès/échec)

4. Interpréter les corrélations pour améliorer la fiabilité

  1. Spike d’erreur + CPU Redis élevé → le broker est saturé ; envisager le scaling horizontal ou le réglage du pool de connexions.
  2. Erreur élevée mais CPU stable → problème applicatif (ex. dépendance externe, bug de code).
  3. Latence croissante sans erreur → charge de travail accrue ; ajuster le nombre de workers ou la taille du pool de threads.

En suivant ces scénarios, les équipes SRE peuvent prioriser les actions : scaling du broker, optimisation du code ou amélioration du pool de workers.

5. Bonnes pratiques et limites

  • Limiter le volume de traces : activez le sampling (ex. 10 % des tâches) pour éviter la surcharge du backend.
  • Conserver les métriques historiques : configurez une rétention suffisante (au moins 30 jours) pour analyser les tendances saisonnières.
  • Sécuriser les exportateurs : utilisez TLS et l’authentification lorsqu’ils exposent des métriques publiques.

Rappel : la corrélation ne remplace pas une bonne architecture ; elle complète les stratégies de résilience comme le retry back‑off et le circuit‑breaker.

Conclusion

En instrumentant vos workers Celery et votre broker Redis avec OpenTelemetry, vous obtenez une visibilité unifiée sur les erreurs et les performances. Les KPIs présentés permettent de détecter rapidement les goulots d’étranglement, de réduire le MTTR et d’optimiser le dimensionnement de votre infrastructure.

Pour aller plus loin, la documentation Lescopr détaille la mise en place pas à pas.