Surveillance et alertes HDFS : guide pratique de mise en œuvre

Introduction

La surveillance et les alertes HDFS avec des exemples pratiques doivent aider les opérateurs à passer d'un problème observé à un résultat vérifié. Ce guide se concentre sur la surveillance HDFS pour les développeurs, les consultants DevOps et les équipes techniques de startups. Il relie les alertes HDFS, les métriques HDFS, les tableaux de bord HDFS et la réponse aux incidents HDFS aux commandes, aux sorties attendues, aux signaux de défaillance et aux décisions de récupération.

L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des variables fictives au lieu de secrets, vérifier le résultat et documenter comment récupérer si l'état attendu n'est pas atteint.

Cet article suppose un cluster HDFS fonctionnel. Il couvre l'inventaire de version et d'environnement, les modifications de configuration sécurisées, la vérification et les diagnostics, les modes de défaillance et la récupération, ainsi qu'une liste de contrôle opérationnelle. Chaque section comprend des commandes concrètes, des sorties attendues et des conseils pour les pièges courants.

Inventaire de version et d'environnement

Avant de surveiller HDFS, identifiez la version installée et la topologie de déploiement. Utilisez des commandes en lecture seule pour capturer l'état actuel. Ne modifiez rien tant que vous n'avez pas compris le cluster.

Pour trouver la version HDFS, exécutez :

hdfs version

La sortie attendue ressemble à :

Hadoop 3.3.6
Source code repository https://github.com/apache/hadoop.git -r 2f5c...
Compiled by ubuntu on 2023-06-18T15:10Z
Compiled with protoc 3.7.1
From source with checksum 5e8f...
This command was run using /opt/hadoop/share/hadoop/common/hadoop-common-3.3.6.jar

Enregistrez la version car les noms de métriques et les options de commande changent entre les versions majeures. Par exemple, HDFS 2.x utilise dfs.namenode.fs-limits.min-block-size alors que HDFS 3.x peut utiliser une valeur par défaut différente. Lorsque vous consultez la documentation, filtrez par votre version exacte.

Pour voir la topologie, exécutez :

hdfs dfsadmin -report

Cela rapporte les DataNodes vivants et morts, leur capacité de stockage et le nombre de blocs. Recherchez :

• Les nœuds désaffectés
• Les nœuds en mode maintenance
• Les blocs sous-répliqués
• Les blocs manquants

Exemple d'extrait :

Live datanodes (3):

Name: 10.0.0.2:9866 (datanode1.example.com)
Hostname: datanode1.example.com
Decommission Status : Normal
Configured Capacity: 1099511627776 (1 TB)
DFS Used: 268435456000 (250 GB)
Non DFS Used: 85899345920 (80 GB)
DFS Remaining: 781684047872 (728 GB)
...

Si un DataNode est mort, enquêtez avant de modifier la configuration. Utilisez hdfs dfsadmin -refreshNodes uniquement après avoir résolu le problème sous-jacent.

Capturez l'état actuel du Namenode :

hdfs haadmin -getAllServiceState

Pour un cluster en haute disponibilité, cela renvoie les nœuds actifs et en veille. Par exemple :

namenode1: active
namenode2: standby

Si aucun Namenode actif n'est trouvé, HDFS est indisponible en lecture et en écriture. Ne modifiez pas la configuration ; restaurez d'abord le nœud actif.

Prérequis pour la surveillance

• Accès SSH aux nœuds HDFS avec un utilisateur disposant d'autorisations en lecture seule pour les terminaux de métriques et les fichiers journaux.
• Accès réseau à l'interface web du Namenode (port par défaut 9870 pour HTTP, 9871 pour HTTPS).
• Un puits de métriques configuré (par exemple, JMX, Ganglia, Graphite, Prometheus) si vous avez besoin de données historiques.
• Pour les alertes, une plateforme d'alerte ou un exécuteur de scripts (par exemple, Nagios, Prometheus Alertmanager, tâches cron personnalisées).

Pièges courants

• Exécuter des commandes avec des privilèges élevés peut accidentellement déclencher un basculement ou un rapport de blocs. Utilisez toujours un utilisateur de surveillance dédié avec des autorisations en lecture seule.
• Ignorer les métriques spécifiques à la version. Une métrique disponible en 2.x peut être renommée ou supprimée en 3.x. Consultez la documentation officielle pour votre version.
• Se fier uniquement à l'interface web. L'interface peut être insensible lorsque le cluster est surchargé, donc ayez des solutions de repli CLI et API.

Surveillance des métriques HDFS

HDFS expose des métriques via JMX, des points de terminaison HTTP et des fichiers journaux. Pour la surveillance en temps réel, utilisez les points de terminaison JMX du Namenode et du Datanode. Par exemple, pour obtenir les métriques du Namenode en JSON :

curl -s http://namenode1.example.com:9870/jmx | jq '.beans[] | select(.name=="Hadoop:service=NameNode,name=FSNamesystem")'

Les métriques pertinentes incluent :

• CapacityTotal, CapacityUsed, CapacityRemaining : capacité de stockage en octets.
• TotalFiles, TotalBlocks : comptages de fichiers et de blocs.
• UnderReplicatedBlocks, PendingReplicationBlocks, MissingBlocks : santé de la réplication.
• CorruptBlocks : nombre de blocs corrompus.
• VolumeFailuresTotal : nombre de volumes en échec sur tous les Datanodes.

Exemple d'alerte conditionnelle utilisant ces métriques :

MISSING_BLOCKS=$(curl -s http://namenode1.example.com:9870/jmx | jq '.beans[] | select(.name=="Hadoop:service=NameNode,name=FSNamesystem") | .MissingBlocks')
if [ "$MISSING_BLOCKS" -gt 0 ]; then
  echo "ALERTE : $MISSING_BLOCKS blocs manquants détectés à $(date)" | mail -s "HDFS Missing Blocks" [email protected]
fi

Pour les métriques du Datanode, interrogez :

curl -s http://datanode1.example.com:9864/jmx | jq '.beans[] | select(.name=="Hadoop:service=DataNode,name=DataNodeActivity-hostname-9866")'

Métriques clés du Datanode :

• BytesWritten, BytesRead : taux d'E/S.
• BlocksWritten, BlocksRead : comptages d'opérations de blocs.
• Remaining : capacité restante en octets.
• NumFailedVolumes : nombre de disques en échec.

Configuration de la surveillance Prometheus

Si vous utilisez Prometheus, vous pouvez exporter les métriques HDFS à l'aide de l'exportateur JMX. Téléchargez le fichier JAR de l'exportateur JMX et créez un fichier de configuration, par exemple, hdfs_jmx_exporter.yaml :

startDelaySeconds: 0
hostPort: namenode1.example.com:9870
ssl: false
rules:
- pattern: 'Hadoop:service=NameNode,name=FSNamesystem'
  name: hdfs_namenode_fsnamesystem
  labels:
    cluster: "prod"
  type: GAUGE

Ensuite, exécutez l'exportateur comme agent Java :

java -javaagent:./jmx_prometheus_javaagent-0.17.0.jar=9090:hdfs_jmx_exporter.yaml -jar your-app.jar

Alternativement, exécutez-le comme serveur HTTP autonome en utilisant jmx_prometheus_httpserver. Pour les Datanodes, répétez avec l'hôte et le port appropriés.

Exemple de configuration de collecte Prometheus :

scrape_configs:
  - job_name: 'hdfs-namenode'
    static_configs:
      - targets: ['namenode1.example.com:9090']
  - job_name: 'hdfs-datanode'
    static_configs:
      - targets: ['datanode1.example.com:9091', 'datanode2.example.com:9091', 'datanode3.example.com:9091']

Règles d'alerte pour Prometheus

Créez des règles d'alerte dans Prometheus. Par exemple, alertez sur les blocs manquants :

groups:
- name: hdfs_alerts
  rules:
  - alert: HDFSMissingBlocks
    expr: hdfs_namenode_fsnamesystem_MissingBlocks{cluster="prod"} > 0
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Blocs manquants HDFS détectés"
      description: "Blocs manquants dans HDFS pour le cluster prod : {{ $value }}."

De même, alertez sur les blocs sous-répliqués, les blocs corrompus ou les DataNodes morts.

Modifications de configuration sécurisées

Parfois, vous devez modifier la configuration HDFS pour améliorer la surveillance ou résoudre un problème. Suivez un chemin sûr : capturez l'état actuel, effectuez une modification ciblée, vérifiez et documentez la récupération.

Exemple : augmenter la journalisation pour les audits du Namenode

Supposons que vous ayez besoin d'auditer les opérations HDFS pour la surveillance de sécurité. Augmentez temporairement le niveau de journalisation d'audit.

1. Localisez le fichier log4j.properties du Namenode (souvent dans $HADOOP_CONF_DIR).
2. Capturez le paramètre actuel du journaliseur d'audit :

grep hdfs.audit.logger $HADOOP_CONF_DIR/log4j.properties

Sortie attendue :

log4j.logger.org.apache.hadoop.hdfs.server.namenode.FSNamesystem.audit=WARN

1. Changez WARN en INFO :

sed -i 's/log4j.logger.org.apache.hadoop.hdfs.server.namenode.FSNamesystem.audit=WARN/log4j.logger.org.apache.hadoop.hdfs.server.namenode.FSNamesystem.audit=INFO/' $HADOOP_CONF_DIR/log4j.properties

1. Redémarrez le Namenode (ou utilisez kill -1 pour un rechargement gracieux si pris en charge).
2. Vérifiez le changement :

grep hdfs.audit.logger $HADOOP_CONF_DIR/log4j.properties

La sortie attendue montre INFO.

1. Surveillez le journal d'audit pour une opération de test. Si vous constatez une croissance excessive du journal, revenez immédiatement à WARN.

Rayon d'impact : affecte uniquement les journaux d'audit du Namenode. Cela peut augmenter l'utilisation du disque pour les journaux ; surveillez la rotation des journaux.

Exemple : activation du puits de métriques vers Graphite

Si vous devez envoyer des métriques à Graphite, ajoutez un puits à hadoop-metrics2.properties.

1. Sauvegardez le fichier actuel :

cp $HADOOP_CONF_DIR/hadoop-metrics2.properties $HADOOP_CONF_DIR/hadoop-metrics2.properties.bak.$(date +%Y%m%d)

1. Ajoutez la configuration suivante pour le puits du Namenode :

namenode.sink.graphite.class=org.apache.hadoop.metrics2.sink.GraphiteSink
namenode.sink.graphite.server_host=graphite.example.com
namenode.sink.graphite.server_port=2003
namenode.sink.graphite.metrics_prefix=hadoop.namenode

1. Redémarrez le Namenode (ou le système de métriques s'il peut être rechargé).
2. Vérifiez que les métriques apparaissent dans Graphite :

curl -s http://graphite.example.com/render?target=hadoop.namenode.*&format=json | jq '.[0].target'

Récupération : si les métriques s'arrêtent, revenez au fichier de sauvegarde et redémarrez le service.

Rayon d'impact : affecte uniquement l'exportation des métriques du Namenode.

Vérification et diagnostics

Après tout changement, vérifiez que la surveillance fonctionne et que le cluster est sain. Utilisez des diagnostics en lecture seule.

Vérification de la santé HDFS via la ligne de commande

hdfs fsck / -files -blocks -locations

Cela rapporte la santé du système de fichiers, y compris les blocs sous-répliqués, sur-répliqués, mal répliqués et corrompus. Exemple de sortie :

Status: HEALTHY
 Total size:    536870912000 B (500 GB)
 Total dirs:    1024
 Total files:   2048
 Total blocks (validated):      4096 (avg. block size 134217728 B)
 Minimally replicated blocks:   4096 (100.0 %)
 Over-replicated blocks:        0 (0.0 %)
 Under-replicated blocks:       0 (0.0 %)
 Mis-replicated blocks:         0 (0.0 %)
 Default replication factor:    3
 Average block replication:     3.0
 Corrupt blocks:                0
 Missing replicas:              0 (0.0 %)
 Number of data-nodes:          3
 Number of racks:               1

Si Status n'est pas HEALTHY, enquêtez avant de continuer.

Test de la livraison des alertes

Testez votre pipeline d'alerte en déclenchant une alerte de test. Pour un script personnalisé, exécutez :

./send_test_alert.sh --severity warning --message "Alerte de test de la surveillance HDFS" --channel ops

Vérifiez que l'alerte apparaît dans votre Slack/e-mail/PagerDuty. Si ce n'est pas le cas, inspectez le script et la configuration du service de notification.

Validation des requêtes du tableau de bord

Si vous avez construit un tableau de bord Grafana, exécutez manuellement les requêtes sous-jacentes. Pour Prometheus, utilisez :

curl -s 'http://prometheus.example.com:9090/api/v1/query?query=hdfs_namenode_fsnamesystem_CapacityRemaining' | jq '.data.result'

Assurez-vous que la valeur correspond à l'interface web ou à hdfs dfsadmin -report.

Modes de défaillance et récupération

HDFS peut échouer de nombreuses façons. Voici les modes de défaillance courants, comment les détecter et les étapes de récupération.

Défaillance du Namenode

Symptômes :

• Les commandes HDFS se bloquent ou renvoient une connexion refusée.
• L'interface web est inaccessible.
• hdfs haadmin -getAllServiceState ne montre aucun Namenode actif.

Détection :

hdfs haadmin -getAllServiceState

Si aucun actif, vérifiez le processus Namenode :

jps | grep NameNode

S'il est absent, démarrez-le :

hdfs --daemon start namenode

Pour la haute disponibilité, si le nœud en veille est sain, promouvez-le :

hdfs haadmin -failover namenode1 namenode2

Ensuite, réparez le nœud actif d'origine.

Vérification de la récupération : exécutez hdfs dfs -ls / pour vous assurer que le système de fichiers est accessible.

Défaillance d'un DataNode

Symptômes :

• Les blocs sous-répliqués augmentent.
• hdfs dfsadmin -report montre un nœud mort.
• Des blocs manquants après une défaillance prolongée.

Détection :

hdfs dfsadmin -report | grep -A5 "Dead datanodes"

Si un DataNode est mort, vérifiez ses journaux ($HADOOP_LOG_DIR/hadoop-hdfs-datanode-*.log). Causes courantes : défaillance de disque, partition réseau ou forte pression mémoire.

Récupération :

• Si le disque a échoué, remplacez-le et redémarrez le DataNode.
• Si partition réseau, rétablissez la connectivité et exécutez hdfs dfsadmin -refreshNodes pour relire la topologie.
• Si le nœud ne peut pas être récupéré, désaffectez-le correctement :

hdfs dfsadmin -refreshNodes

Assurez-vous que la réplication est satisfaite en vérifiant hdfs fsck / -files -blocks -locations pour les blocs sous-répliqués.

Utilisation élevée du disque sur les DataNodes

Symptômes :

• CapacityRemaining tombe en dessous d'un seuil.
• Les écritures échouent avec « Disque plein ».

Détection :

hdfs dfsadmin -report | grep -A10 "Live datanodes" | grep "DFS Remaining"

Configurez une alerte lorsque la capacité restante est inférieure à 10 %.

Récupération :

• Rééquilibrez le cluster pour redistribuer les données :

hdfs balancer -threshold 10

• Supprimez les fichiers inutiles ou déplacez les données vers un stockage externe.
• Ajoutez de nouveaux DataNodes si nécessaire.

Blocs corrompus

Symptômes :

• hdfs fsck / rapporte Corrupt blocks : N.
• Les applications échouent à lire certains fichiers.

Détection :

hdfs fsck / -list-corruptfileblocks

Récupération :

• Si le facteur de réplication est suffisamment élevé, HDFS peut automatiquement répliquer une bonne copie à partir d'une autre réplique.
• Si toutes les répliques sont corrompues, restaurez à partir de la sauvegarde ou récupérez manuellement si possible.
• Ensuite, supprimez les fichiers de blocs corrompus et laissez HDFS répliquer à partir de bonnes copies.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle pour vous assurer que votre surveillance HDFS est efficace et sûre. Attribuez un responsable unique pour chaque élément et une fréquence de révision.

Chaque responsable est chargé d'enquêter et de résoudre les problèmes liés à sa vérification. Si une vérification échoue, suivez le chemin d'escalade défini dans votre plan de réponse aux incidents.

Pièges courants et comment les éviter

Voici les erreurs fréquentes dans la surveillance HDFS avec les raisons et les solutions.

1. Fatigue des alertes

Pourquoi cela arrive : Trop d'alertes, seuils trop bas ou alertes non actionnables.

Comment éviter : Définissez des seuils significatifs basés sur des données historiques. Par exemple, alertez sur les blocs sous-répliqués uniquement si le compte reste > 0 pendant plus de 10 minutes. Regroupez les alertes similaires dans une seule notification. Révisez et ajustez régulièrement les alertes.

2. Ignorer les tendances de défaillance de disque

Pourquoi cela arrive : Les défaillances de disque surviennent progressivement, mais la surveillance se concentre sur la capacité globale plutôt que sur la santé individuelle des disques.

Comment éviter : Surveillez les métriques par disque à partir du JMX du DataNode, telles que NumFailedVolumes et les données SMART des disques. Définissez des alertes pour tout volume en échec, pas seulement lorsque la capacité est faible.

3. Ne pas tester les procédures de récupération

Pourquoi cela arrive : Les équipes supposent que la récupération fonctionne jusqu'à ce qu'un incident se produise.

Comment éviter : Effectuez régulièrement des exercices d'incendie. Simulez une défaillance de DataNode en arrêtant le service et en vérifiant que la réplication et les alertes fonctionnent. Documentez le temps de récupération (RTO) et visez à le réduire.

4. Utiliser les ports JMX par défaut sans authentification

Pourquoi cela arrive : Les configurations par défaut exposent les métriques et les points de terminaison JMX sans authentification, ce qui peut divulguer des informations sensibles.

Comment éviter : Activez l'authentification Kerberos pour JMX ou restreignez l'accès via des politiques réseau. Utilisez un proxy de métriques qui exige une authentification.

5. Modifier la configuration sans contrôle de version

Pourquoi cela arrive : Des corrections rapides sont appliquées directement, entraînant une dérive de configuration.

Comment éviter : Stockez tous les fichiers de configuration HDFS dans un contrôle de version (par exemple, Git). Utilisez des outils de gestion de configuration (Ansible, Puppet, Chef). Ces changements peuvent être examinés, annulés et audités.

6. Négliger l'utilisation du tas du Namenode

Pourquoi cela arrive : La pression mémoire du Namenode peut entraîner des performances lentes ou des plantages, mais les équipes se concentrent sur le disque et le processeur.

Comment éviter : Surveillez l'utilisation du tas du Namenode via JMX (java.lang:type=Memory). Définissez des alertes lorsque l'utilisation du tas dépasse 80 % pendant une période prolongée. Envisagez d'ajuster la taille du tas ou de réduire la taille des métadonnées.

Conclusion

La surveillance et les alertes HDFS avec des exemples pratiques ne sont utiles que si chaque recommandation est spécifique à la version, observable et réversible lorsque la technologie le permet. Copier une commande sans vérifier les prérequis et la sortie attendue n'est pas une procédure opérationnelle.

Comme prochaine étape, choisissez une vérification à faible risque pour la surveillance HDFS, enregistrez l'état actuel, exécutez la vérification documentée, comparez le résultat avec le signal attendu et examinez les dépendances telles qu'Apache Spark, NiFi et Kafka.

Un flux de travail technique fiable rend les défaillances visibles, protège les valeurs sensibles, limite les changements à la ressource prévue et définit la vérification de la récupération avant qu'un incident ne force la décision.