Surveillance et alertes Apache Spark avec exemples pratiques

Introduction

Apache Spark peut traiter d'immenses volumes de données, mais la fiabilité en production repose sur l'observation des bons signaux et la capacité d'agir rapidement. Ce guide montre exactement quoi surveiller, comment collecter et alerter dessus avec un risque minimal, et comment vérifier la configuration. Il inclut des extraits de configuration concrets, des règles d'alertes pratiques, les résultats attendus, les modes de défaillance courants, les étapes de restauration et une liste de contrôle opérationnelle à exécuter chaque semaine.

Utilisez ce guide pour :

• Établir un projet pilote ciblé et à faible risque avant un déploiement large.
• Faire émerger la santé du driver et des executors, la pression mémoire, les performances de shuffle, les goulots d'étranglement SQL/Streaming, et les points d'intégration (Kafka, HDFS, déclencheurs Airflow/NiFi).
• Construire des alertes et des tableaux de bord actionnables avec des étapes de vérification claires et des actions de récupération.

Inventaire des versions et de l'environnement

Commencez par consigner exactement ce que vous exécutez. Cela évite les configurations incompatibles et vous donne un point de restauration propre.

Enregistrez :

• Distribution et version de Spark (par exemple : Spark 3.3.x ou 3.4.x)
• Version de la JVM (par exemple : OpenJDK 11 ou 17)
• Gestionnaire de cluster (Standalone, YARN ou Kubernetes)
• Types de charges de travail (batch, Structured Streaming, Spark SQL)
• Allocation dynamique activée/désactivée, nombres et tailles typiques d'executors
• Sources et puits de données concernés (par exemple : Kafka, HDFS, stockage objet)
• Composants du pipeline de métriques (par exemple : agent JMX exporter, Prometheus, outil de tableau de bord)

Attentes de base :

• Spark expose les métriques via son système de métriques et le JMX de la JVM. Vous attacherez un collecteur de métriques (sink) ou un JMX exporter au driver et aux executors.
• Les logs (driver/executor) sont collectés centralement (par exemple : via filebeat/agent ou les logs du gestionnaire de cluster). Vous utiliserez des motifs de logs spécifiques pour les déclencheurs d'incidents et le diagnostic.

Parcours de configuration sécurisé

Déployez incrémentalement avec un projet pilote étroit que vous pouvez inspecter localement :

1. Choisissez une application Spark non critique représentant votre charge de travail courante (par exemple : un ETL quotidien avec jointures et shuffle).
2. Instrumentez les JVM du driver et des executors avec un JMX exporter ou activez un collecteur de métriques Spark éprouvé.
3. Collectez un ensemble minimal de métriques : mémoire JVM du driver, mémoire et GC des executors, tâches actives, tâches en échec, durée des stages, lecture/écriture shuffle, durée des micro-batchs streaming (si applicable).
4. Construisez un tableau de bord pilote et trois alertes maximum. Maintenez l'alertage étroit et mesurable.
5. Vérifiez en induisant des conditions de test à faible risque (voir Vérification) et confirmez que les alertes se déclenchent et se résolvent.
6. Documentez la restauration (supprimez les indicateurs d'agent ou la configuration du collecteur de métriques) et les configurations connues comme bonnes.
7. Étendez aux deux prochaines applications critiques après 1 à 2 semaines de signal-bruit stable.

Ce petit pilote mesurable est rapide à valider et facile à annuler si quelque chose se comporte mal.

Quoi surveiller et alerter

Spark fournit plusieurs couches utiles de signaux. Commencez par l'essentiel, puis ajoutez de la profondeur sélectivement.

Composants principaux et signaux

Règles d'alertes pratiques (commencez petit)

Utilisez les alertes pour faire émerger les problèmes visibles par les utilisateurs ou les risques urgents. Commencez avec un ensemble compact pour éviter le bruit.

Notes :

• Ce sont des exemples construits et des seuils. Ajustez selon les normes de charge après la semaine 1.
• Utilisez des métriques de taux/ratio quand possible pour stabiliser malgré les tailles de charge variables.

Signaux de logs qui comptent

Complétez les métriques avec des motifs de logs pour accélérer le tri des incidents :

• OutOfMemoryError ou GC overhead limit exceeded
• ExecutorLostFailure ou FetchFailedException
• TaskKilled dû à des pics de spéculation ou de préemption
• Avertissements de maintenance StateStore pour le streaming
• Timeouts et échecs d'autorisation clients HDFS/Kafka

Transformez les motifs répétés en alertes silencieuses ou liens vers des runbooks plutôt qu'en pages immédiates.

Implémentation : collecte des métriques et logs

Spark offre deux approches principales pour extraire les métriques numériques du driver et des executors : son système de métriques (collecteurs/sinks) et le JMX de la JVM. La voie JMX est largement compatible et facile à vérifier.

Option A : JMX exporter comme agent Java (driver et executors)

1. Obtenez un fichier jar JMX exporter et choisissez un port (exemple : 7071 pour le driver, 7072 pour les executors).
2. Créez un YAML JMX exporter minimal (exemple construit) :

rules:
 - pattern: "org.apache.spark.*"
   name: spark_$0
   type: GAUGE
   labels: {}

1. Ajoutez l'agent aux JVM du driver et des executors. Exemple de drapeaux spark-submit (chemins et ports construits) :

spark-submit \
 --class com.example.YourJob \
 --conf "spark.driver.extraJavaOptions=-javaagent:/opt/jmx/jmx_exporter.jar=7071:/opt/jmx/jmx.yaml" \
 --conf "spark.executor.extraJavaOptions=-javaagent:/opt/jmx/jmx_exporter.jar=7072:/opt/jmx/jmx.yaml" \
 --conf "spark.executor.instances=4" \
 your-job-assembly.jar

1. Vérification locale :

• Confirmez que le point de terminaison HTTP JMX du driver est accessible : curl http://localhost:7071/metrics retourne du texte.
• Pendant une exécution, confirmez qu'au moins un point de terminaison JMX d'executor répond sur son port de nœud.
• Récupérez ces points de terminaison dans votre magasin de métriques et construisez un tableau de bord pilote en utilisant les signaux listés plus haut.

Avantages : changements de configuration Spark minimaux, supporte les sous-systèmes JVM et Spark via MBeans. Inconvénients : assurez-vous que les ports sont autorisés et uniques par processus.

Option B : Système de métriques Spark (collecteur d'exemple)

Alternativement, configurez le système de métriques Spark avec spark.metrics.conf pour envoyer les métriques vers un collecteur choisi (exemple utilise un collecteur CSV simple). Exemple construit :

Créez spark.metrics.conf et placez-le dans le classpath ou spécifiez-le via la propriété spark.metrics.conf :

*.sink.csv.class=org.apache.spark.metrics.sink.CsvSink
*.sink.csv.period=10
*.sink.csv.unit=seconds
*.sink.csv.directory=/tmp/spark-metrics

master.source.jvm.class=org.apache.spark.metrics.source.JvmSource
worker.source.jvm.class=org.apache.spark.metrics.source.JvmSource
executor.source.jvm.class=org.apache.spark.metrics.source.JvmSource
driver.source.jvm.class=org.apache.spark.metrics.source.JvmSource

Soumettez avec :

spark-submit \
 --conf spark.metrics.conf=/path/to/spark.metrics.conf \
 your-job-assembly.jar

Vérification :

• Confirmez que les fichiers apparaissent sous /tmp/spark-metrics sur les hôtes driver et executor.
• Inspectez les jauges JVM et les métriques de tâches pour vous assurer que l'activité est enregistrée.

Avantages : pas de ports de processus supplémentaires. Inconvénients : vous pourriez avoir besoin d'un routeur vers votre magasin de métriques central.

Logs

• Assurez-vous que les logs du driver et des executors sont conservés centralement avec une rétention stable.
• Ajoutez des analyseurs pour les exceptions courantes et les balises de sous-systèmes Spark (ID executor, ID stage, ID job).
• Indexez par ID d'application et numéro de tentative pour lever l'ambiguïté des retentatives.

Tableaux de bord qui pilotent l'action

Commencez avec un tableau de bord ciblé par type de charge de travail. Évitez les pages tentaculaires. Regroupez par action d'opérateur.

Sections à inclure :

1. Santé du driver : tas utilisé %, temps GC %, threads, CPU JVM.
2. Executors : total vs actifs, executors perdus, tâches actives, échecs de tâches, temps de tâche p95.
3. Stages et shuffle : durée des stages p50/p95, asymétrie (p95/p50), lecture/écriture shuffle Mo/s, attente récupération p95.
4. SQL/ETL : enregistrements entrée/sortie, métriques de spill, taille de broadcast, top-N requêtes par durée.
5. Streaming (si applicable) : taux entrée vs traitement, durée des batchs, arriéré/lag, taille du state store, latence d'écriture des checkpoints.
6. Bords : lag Kafka ou erreurs d'écriture HDFS (panneaux construits si vos métriques les incluent).

Maintenez-le lisible. Maximum 12 à 16 panneaux sur la vue principale ; liez vers des analyses approfondies.

Vérification et diagnostics

La vérification assure des signaux fiables sans bruit de paging. Exécutez ces tests dans le pilote avant le déploiement complet.

1. Accessibilité des points de terminaison

• Driver : interrogez le point de terminaison JMX ou métriques et confirmez une réponse non vide.
• Au moins un executor : confirmez un point de terminaison pendant une exécution.
• Si vous utilisez un collecteur, validez les fichiers ou l'évacuation réseau au taux attendu.

1. Forme des métriques et étiquettes

• Confirmez que application_id, executor_id, stage_id et job_id apparaissent dans les étiquettes ou noms de métriques.
• Assurez-vous que la cardinalité des étiquettes est raisonnable (par exemple : n'exposez pas d'étiquettes par partition).

1. Essais à sec d'alertes (exemples construits)

• Risque mémoire : allouez un jeu de données plus grand pour pousser le tas driver utilisé > 85 % temporairement ; vérifiez que l'alerte se déclenche et se résout quand la charge se termine.
• Échecs de tâches : introduisez un jeu d'entrées contrôlé défectueux pour causer un petit nombre d'échecs ; confirmez que l'alerte basée sur le taux se déclenche sans spammer.
• Pression shuffle : exécutez une jointure large pour augmenter la lecture/écriture shuffle ; observez la distribution d'attente de récupération.
• Contre-pression streaming : réduisez les ressources pour un test afin que la durée du batch dépasse l'intervalle de déclencheur ; vérifiez l'alerte.

1. Recoupements

• Comparez les tendances du tableau de bord avec l'interface Spark UI pour la même tentative d'application.
• Confirmez que les durées de stages et les compteurs de tâches correspondent dans des limites raisonnables.

1. Répétition du runbook

• Pour chaque alerte, suivez vos étapes de première action et confirmez qu'elles sont suffisantes. Mettez à jour les notes du runbook avec les noms d'hôtes, chemins de fichiers et commandes que vous avez réellement utilisés.

Résultats attendus :

• Les métriques arrivent dans les 10 à 30 secondes suivant un changement.
• Les alertes se déclenchent dans une fenêtre d'évaluation, se résolvent quand la condition se nettoie, et ne flappent pas.
• Les opérateurs peuvent corréler l'alerte à l'interface Spark UI et aux logs en moins de 2 minutes.

Modes de défaillance et récupération

Anticipez et préparez-vous à ces problèmes courants.

1. Exporter non attaché ou mauvais port

• Symptôme : pas de métriques du driver/executors ; erreurs de récupération.
• Correction : confirmez les drapeaux extraJavaOptions, le chemin du jar et la disponibilité du port. Redémarrez le job.
• Restauration : supprimez extraJavaOptions et redéployez le job.

1. Étiquettes à haute cardinalité

• Symptôme : gonflement du magasin de métriques, tableaux de bord lents.
• Correction : réétiquetez pour supprimer les étiquettes par tâche ou par partition ; agrégez au niveau stage/job/application.
• Restauration : revenez au mapping ou fichier de règles précédent.

1. Churn d'allocation dynamique

• Symptôme : executors apparaissant/disparaissant rapidement causent des séries temporelles manquantes ou des alertes bruyantes.
• Correction : agrégez les alertes au niveau application ; ajoutez une allocation minimale pour stabiliser les métriques pendant le pilote.
• Restauration : désactivez les alertes concernées jusqu'à stabilisation.

1. Gaps d'expédition des logs

• Symptôme : logs driver/executor manquants pendant les incidents.
• Correction : vérifiez les permissions de l'agent et les paramètres de rotation ; augmentez la rétention pendant le déploiement.
• Restauration : revenez aux logs du gestionnaire de cluster pendant la réparation des agents.

1. Blocage réseau ou pare-feu

• Symptôme : le récupérateur ne peut pas atteindre les ports JMX.
• Correction : ouvrez les ports requis du récupérateur vers les nœuds driver/executor ; envisagez d'utiliser des exportateurs au niveau nœud.
• Restauration : basculez vers l'approche collecteur de métriques Spark qui utilise les chemins d'évacuation existants.

1. Fatigue d'alertes

• Symptôme : trop de pages Moyenne, les opérateurs ignorent.
• Correction : rétrogradez les non-urgents vers ticket ou email ; durcissez les conditions et durées.
• Restauration : revenez au petit ensemble de démarrage d'alertes.

Liste de contrôle de récupération après un changement de surveillance :

• Si la nouvelle configuration a causé l'instabilité, redéployez immédiatement la dernière configuration de job connue comme bonne.
• Confirmez que les métriques et alertes précédentes fonctionnent comme avant.
• Ouvrez un enregistrement de changement notant les horodatages, configurations et raison de la restauration.

Actions pratiques du runbook

Quand une alerte se déclenche, les opérateurs ont besoin d'étapes suivantes concrètes.

Pression mémoire du driver :

• Capturez le tas actuel, le temps GC % et les charges de travail requêtes/stages récentes.
• Vérifiez l'onglet Stockage de l'interface Spark UI pour les jeux de données mis en cache ; évictez si sûr.
• Envisagez d'augmenter la mémoire du driver pour la prochaine exécution ou de refactoriser les appels collect() volumineux.

Échecs de tâches ou perte d'executors :

• Inspectez les logs d'executors pour erreurs disque, réseau ou OOM.
• Validez la cohérence des données d'entrée pour cette fenêtre d'exécution.
• Si un petit sous-ensemble de partitions échoue, relancez le stage avec retentatives après correction de l'entrée.

Goulots d'étranglement du shuffle :

• Vérifiez la santé du service de shuffle et les E/S disque sur les nœuds affectés.
• Envisagez d'augmenter les partitions de shuffle ou d'activer l'exécution de requête adaptative pour un meilleur dimensionnement des partitions.

Contre-pression du streaming :

• Comparez le taux d'entrée au taux de traitement ; ajustez l'intervalle de déclencheur.
• Ajustez la compaction ou le TTL du state store ; assurez-vous que le stockage de checkpoint est sain et à faible latence.

Liste de contrôle opérationnelle

Utilisez cette liste hebdomadairement et pendant les déploiements.

• Inventaire
• Vérifiez que les versions de Spark, JVM et outils de métriques sont inchangées ou documentées.
• Confirmez les drapeaux d'agent driver/executor ou configurations de collecteur dans le contrôle de version.

• Tests de fumée
• Exécutez un petit job et confirmez que les métriques et logs arrivent dans les 30s.
• Vérifiez qu'au moins un point de terminaison de métriques d'executor est accessible pendant l'exécution.

• Tableaux de bord
• Confirmez que les panneaux driver, executor, stage et shuffle affichent des données actuelles.
• Revoyez le top-N des jobs ou requêtes lents par durée.

• Alertes
• Revoyez les alertes de la semaine passée ; ajustez seuils/durations pour réduire le bruit.
• Déclenchez manuellement une alerte de test sûre par mois (par exemple : pic de charge court et contrôlé).

• Signaux de capacité
• Vérifiez les tendances du tas driver et du temps GC sur les 7 derniers jours.
• Revoyez les compteurs d'échecs d'executors et leurs raisons.

• Bords de données
• Inspectez le panneau de lag Kafka ou d'erreurs HDFS pour anomalies.

• Runbooks
• Mettez à jour les étapes avec tout nouveau chemin de fichier, port ou changement d'outil.
• Assurez-vous que la rotation d'astreinte a les accès et permissions.

• Sauvegarde et restauration
• Stockez les configurations actuelles et les dernières versions connues comme bonnes.
• Confirmez que vous pouvez supprimer les drapeaux d'agent et redéployer dans les 10 minutes.

Conclusion

Vous avez maintenant un chemin pratique et à faible risque pour implémenter la surveillance et l'alertage Apache Spark :

• Commencez avec un pilote étroit et un petit ensemble de métriques à haute valeur.
• Attachez un JMX exporter ou configurez des collecteurs de métriques Spark pour le driver et les executors.
• Construisez un tableau de bord ciblé et un ensemble d'alertes compact et actionnable.
• Vérifiez les points de terminaison, les étiquettes de métriques et le comportement des alertes avec des tests sûrs avant d'étendre à l'échelle du cluster.
• Anticipez les modes de défaillance et gardez les étapes de restauration prêtes.

Une fois que le pilote fonctionne de manière fiable pendant 1 à 2 semaines, déployez sur plus d'applications, en ajustant les seuils par charge de travail. Maintenez les changements petits, mesurables et faciles à inspecter localement avant un déploiement large. Cette approche disciplinée réduit le retravail et conduit à une réponse aux incidents plus rapide et plus confiante.