Surveillance ECC : vérifier la chaîne du noyau à l’alerte

Lorsqu’un processus de base de données s’arrête de manière inattendue et que des erreurs mémoire apparaissent au même moment dans les journaux du noyau, redémarrer l’application ne fait que relancer le processus : cela n’explique pas l’origine de l’incident. L’ECC peut corriger certaines erreurs mémoire, mais ne prend pas automatiquement en charge la conservation des événements, l’analyse des tendances ni la collecte des éléments nécessaires à un ticket d’assistance. La validation d’un serveur dédié avant sa mise en service doit couvrir toute la chaîne : signalement par le matériel, réception par le noyau, conservation de l’événement, détection par la supervision et réception de l’alerte.

Les serveurs dédiés CloudSFP équipés d’un AMD EPYC 7543P utilisent de la mémoire DDR4-3200 ECC et sont proposés en deux capacités : 128 Go et 256 Go. La procédure ci-dessous prend Debian 12 comme exemple. Les commandes s’exécutent dans le système d’exploitation hôte, et non dans un système invité. Les informations exposées peuvent varier selon le noyau et le micrologiciel. Toute source de données manquante doit être signalée séparément, et non assimilée à une absence d’erreurs.

1. Distinguer les erreurs des lacunes de supervision

Les erreurs corrigibles sont généralement désignées par CE, ce qui indique que l’erreur concernée a été corrigée. Les erreurs non corrigibles sont généralement désignées par UE : le mécanisme de correction concerné ne peut pas les réparer. Leur impact dépend aussi de l’emplacement de l’erreur, du traitement effectué par le noyau et du processus touché. Ces abréviations ne suffisent pas à conclure que les données de l’application sont nécessairement intactes.

Pour les CE, il faut surtout examiner l’augmentation des compteurs, la répétition des erreurs au même emplacement et la charge au moment de leur apparition. Un événement isolé et des événements récurrents au même endroit ne doivent pas recevoir la même priorité de traitement. En cas d’UE, la protection des données passe en premier : vérifiez les arrêts de processus, les anomalies du système et les sauvegardes existantes, puis cessez d’augmenter la charge concernée.

« Aucun événement enregistré » n’est une observation exploitable que si le bon fonctionnement de la chaîne de collecte a été confirmé. Un répertoire EDAC vide, un service de collecte arrêté ou une base d’événements illisible sont des lacunes de supervision, pas des preuves de bon fonctionnement.

L’ECC ne remplace pas non plus les contrôles d’intégrité des données, la redondance du stockage ni les sauvegardes. Pour relier un résultat applicatif erroné ou un fichier corrompu à une erreur mémoire, il faut une corrélation temporelle et des éléments issus de l’application. On ne peut pas en déduire directement un lien de cause à effet.

2. Vérifier les sources de données réellement exposées par le noyau

Commencez par relever l’identifiant de démarrage et la version du noyau, puis examinez le répertoire des contrôleurs mémoire et les événements du noyau. Ces commandes se limitent à lire l’état actuel : elles ne chargent aucun pilote et ne modifient aucun paramètre matériel.

uname -r
cat /proc/sys/kernel/random/boot_id
ls -ld /sys/devices/system/edac/mc
find /sys/devices/system/edac/mc -maxdepth 2 -type f \
  \( -name ce_count -o -name ue_count -o -name mc_name \) \
  -print -exec cat {} \;
sudo journalctl -k -b --no-pager \
  --grep='EDAC|MCE|Hardware Error|memory error'

Dans ce répertoire, mc_name permet d’identifier le contrôleur, tandis que ce_count et ue_count sont ses compteurs cumulés. Si la première lecture donne des valeurs non nulles, enregistrez-les d’abord comme référence initiale. Ne traitez pas l’ensemble du cumul historique comme une alerte venant de se produire.

Si le répertoire est absent ou ne contient aucune entrée de contrôleur, conservez la sortie des commandes et recherchez les messages d’initialisation des pilotes dans les journaux du noyau. La prise en charge par les pilotes, les paramètres du micrologiciel et le chemin de signalement de la plateforme peuvent tous influer sur la visibilité des données. Il est déconseillé de procéder par essais successifs en chargeant des modules inconnus sur une machine de production.

Un message MCE ou Hardware Error dans les journaux du noyau ne désigne pas nécessairement une défaillance de la mémoire : l’événement peut provenir d’un autre composant matériel. Il faut conserver tout le contexte, et non classer l’événement à partir d’une seule ligne contenant le mot « error ».

3. Configurer l’enregistrement avec rasdaemon et établir les compteurs de référence

Sur Debian 12, rasdaemon peut être installé à partir des paquets de la distribution. Avant toute modification, sauvegardez la configuration actuelle du service. Après l’installation, vérifiez à la fois l’état du service, ses paramètres de lancement et le processus effectivement exécuté.

sudo apt-get update
sudo apt-get install rasdaemon
sudo systemctl enable --now rasdaemon
systemctl status rasdaemon --no-pager
systemctl cat rasdaemon
ps -C rasdaemon -o pid,args
sudo ras-mc-ctl --status
sudo ras-mc-ctl --summary
sudo ras-mc-ctl --errors

La vérification avec --status n’est qu’une partie du contrôle, pas un bilan complet de l’état du système. Consultez également les journaux du service pour repérer d’éventuels échecs d’abonnement aux événements, erreurs de permissions ou problèmes d’écriture dans la base de données.

sudo journalctl -u rasdaemon -b --no-pager

Un processus actif ne garantit pas l’enregistrement sur disque

Vérifiez que les paramètres de lancement incluent -r ou --record, et que le paquet installé prend en charge la base de données. Si le service fonctionne sans conserver les événements de manière persistante, le redémarrage du processus de collecte peut créer une rupture dans l’historique de diagnostic. Déterminez l’emplacement de la base à partir de la configuration réelle du paquet, sans reprendre arbitrairement le chemin utilisé par une autre distribution.

À chaque relevé, conservez au minimum l’identifiant de la machine, l’identifiant de démarrage, l’heure du relevé, le nom du contrôleur et les compteurs CE et UE. Les variations de compteur ne doivent être comparées que pour un même identifiant de démarrage et une même source de données. Après un redémarrage du système, un rechargement de module ou une baisse du compteur, établissez une nouvelle référence au lieu de calculer une variation négative puis de l’ignorer.

Les données couvertes par rasdaemon et EDAC ne sont pas nécessairement identiques. Avant de les comparer, vérifiez le type d’événement, le début de la collecte et le contrôleur concerné. N’exigez pas que les totaux des deux sources coïncident mécaniquement.

4. Faire ressortir le risque dans les alertes plutôt que multiplier les messages

Il est recommandé de séparer la supervision en trois catégories : défaillance de la chaîne de collecte, nouvelles CE et nouvelles UE. Les défaillances de collecte comprennent l’arrêt du service, l’échec de lecture des compteurs et les erreurs de requête à la base de données. Elles doivent déclencher des alertes distinctes : une anomalie ne doit jamais être masquée par une valeur nulle.

Une notification de nouvelles CE doit inclure la variation constatée, le contrôleur et l’événement d’origine. Si les enregistrements comportent des champs de localisation, les événements répétés peuvent être regroupés par emplacement. En revanche, il ne faut pas définir un « nombre acceptable » d’erreurs valable pour toutes les machines. La fréquence des événements, leur concentration et les symptômes applicatifs doivent être pris en compte ensemble pour décider d’une escalade.

Les nouvelles UE doivent recevoir une priorité plus élevée. Conservez d’abord les éléments décrivant l’état au moment de l’incident, puis vérifiez l’intégrité des données de l’application. Ne lancez pas de test de charge pour confirmer davantage la panne et ne redémarrez pas la machine simplement pour remettre les compteurs à zéro.

La validation de la chaîne d’alerte peut se faire à l’aide de jeux de données hors ligne : préparez deux relevés de compteurs, avant et après variation, puis vérifiez séparément l’absence de variation, une augmentation des CE, une augmentation des UE, un échec de lecture et un changement d’identifiant de démarrage. Les messages de test doivent être clairement marqués comme des exercices. Ils ne doivent alimenter que l’analyseur de supervision, sans être écrits dans la base réelle des événements matériels.

Ne validez pas les notifications par injection d’erreurs sur un serveur de production. Un test de notification réussi prouve uniquement que l’analyse des messages et leur acheminement fonctionnent. La réception des événements matériels par le noyau doit encore être confirmée séparément, à partir de l’état des pilotes, des sources d’événements et des enregistrements réels.

5. Conserver les éléments utiles à l’investigation matérielle

Lorsque des erreurs se répètent, commencez par exporter les journaux du noyau du démarrage en cours, les journaux du service rasdaemon et les résultats des requêtes d’événements, puis sauvegardez un instantané des compteurs. Limitez les droits d’accès au répertoire de diagnostic. Avant de joindre des fichiers au ticket d’assistance, vérifiez qu’ils ne contiennent pas d’adresses, d’informations de compte ou de données applicatives sensibles.

Organisez le ticket dans l’ordre suivant :

• Identifiant de la machine, versions du système et du noyau, identifiant de démarrage.
• Date et heure de la première détection, avec fuseau horaire explicite, et indication précisant si de nouvelles erreurs continuent d’apparaître.
• Événements CE et UE d’origine, ainsi que les compteurs avant et après variation, et pas seulement une capture d’écran de l’alerte.
• Champs de contrôleur et de localisation présents dans le rapport, en indiquant explicitement les champs manquants.
• Symptômes applicatifs observés sur la même période, actions déjà effectuées et résultats obtenus.

Ne convertissez pas vous-même une étiquette DIMM ou une adresse figurant dans un événement en numéro d’emplacement physique : la correspondance peut varier selon la plateforme. Laissez le support localiser le composant matériel à partir des informations de la machine. Le locataire reste responsable de la protection du système d’exploitation, des données applicatives et des sauvegardes.

Le résultat final de cette vérification n’est pas une capture d’écran « tout au vert », mais une référence vérifiable, un périmètre de couverture des sources clairement défini, une chaîne d’alerte testée et un dossier d’incident complet. Après une mise à jour du noyau ou un redémarrage de la machine, ces conditions doivent être vérifiées à nouveau, pour éviter de confondre une défaillance de collecte avec la disparition des erreurs.

Questions fréquentes