ECC-Überwachung vom Kernel bis zur Alarmierung prüfen

Wenn ein Datenbankprozess unerwartet beendet wird und gleichzeitig Speicherfehler im Kernel-Log auftauchen, stellt ein Neustart der Anwendung lediglich den Prozess wieder her. Die Fehlerursache erklärt er nicht. ECC kann bestimmte Speicherfehler korrigieren, übernimmt aber weder die dauerhafte Ereignisspeicherung noch die Trendbewertung oder die Beweissicherung für ein Support-Ticket. Bei der Inbetriebnahme eines Dedicated Servers sollte deshalb die gesamte Kette geprüft werden: Meldung durch die Hardware, Empfang durch den Kernel, Speicherung der Ereignisse, Erkennung durch das Monitoring und Zustellung der Alarme.

Die Dedicated Server von CloudSFP mit AMD EPYC 7543P verwenden DDR4-3200 ECC und sind mit zwei Speicherausstattungen erhältlich: 128GB und 256GB. Der folgende Prüfablauf verwendet Debian 12 als Beispiel. Die Befehle werden im Host-Betriebssystem ausgeführt, nicht in einem Gastsystem. Welche Informationen verfügbar sind, kann je nach Kernel und Firmware variieren. Fehlende Datenquellen müssen gesondert dokumentiert werden; sie dürfen nicht als null Fehler gewertet werden.

1. Zuerst Fehler von Überwachungslücken unterscheiden

Korrigierbare Fehler werden üblicherweise als CE bezeichnet. Das bedeutet, dass der gemeldete Fehler korrigiert wurde. Nicht korrigierbare Fehler werden üblicherweise als UE bezeichnet: Der betreffende Fehler lässt sich durch den jeweiligen Korrekturmechanismus nicht beheben. Die konkreten Auswirkungen hängen außerdem vom Fehlerort, der Verarbeitung durch den Kernel und dem betroffenen Prozess ab. Aus dem Kürzel allein lässt sich nicht ableiten, dass die Anwendungsdaten unversehrt sind.

Bei CE sind vor allem der Zählerzuwachs, wiederholt betroffene Stellen und die Last zum Ereigniszeitpunkt relevant. Ein einzelnes Ereignis und fortlaufende Ereignisse an derselben Stelle erfordern unterschiedliche Prioritäten. Bei UE hat der Schutz der Daten Vorrang: Beendete Prozesse, Systemauffälligkeiten und vorhandene Backups prüfen und die betroffene Last nicht weiter erhöhen.

„Keine Einträge“ hat nur dann Aussagekraft, wenn die Erfassungskette nachweislich funktioniert. Ein leeres EDAC-Verzeichnis, ein gestoppter Erfassungsdienst oder eine nicht lesbare Ereignisdatenbank sind Überwachungslücken – kein Nachweis für fehlerfreien Speicher.

ECC ersetzt weder Datenprüfung noch Speicherredundanz oder Backups. Fehlerhafte Anwendungsergebnisse und beschädigte Dateien müssen anhand von Zeitangaben und Belegen aus dem Anwendungsbetrieb mit Speicherfehlern in Zusammenhang gebracht werden. Ein ursächlicher Zusammenhang darf nicht einfach unterstellt werden.

2. Die tatsächlich vom Kernel bereitgestellten Datenquellen prüfen

Zunächst die Boot-ID und die Kernel-Version dokumentieren, anschließend das Verzeichnis der Speichercontroller und die Kernel-Ereignisse prüfen. Diese Befehle lesen lediglich den aktuellen Zustand aus. Sie laden keine Treiber und ändern keine Hardwareeinstellungen.

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'

In diesem Verzeichnis dient mc_name zur Identifizierung des Controllers. ce_count und ue_count sind die kumulierten Zählerstände des jeweiligen Controllers. Ist der erste ausgelesene Wert ungleich null, wird er zunächst als Ausgangswert gespeichert. Der gesamte bisherige Zählerstand darf nicht als gerade neu aufgetretener Alarm behandelt werden.

Fehlt das Verzeichnis oder enthält es keine Controllereinträge, sollten die Befehlsausgaben gesichert und die Meldungen zur Treiberinitialisierung im Kernel-Log geprüft werden. Treiberunterstützung, Firmwareeinstellungen und der Meldeweg der Plattform können die Sichtbarkeit beeinflussen. Auf einem Produktivsystem wiederholt unbekannte Module zu laden, um die Unterstützung auszuprobieren, ist nicht empfehlenswert.

Auch MCE- oder Hardware Error-Meldungen im Kernel-Log weisen nicht zwangsläufig auf einen Speicherfehler hin. Das Ereignis kann von einer anderen Hardwarekomponente stammen. Der vollständige Kontext muss erhalten bleiben. Eine einzelne Zeile mit dem Wort „error“ reicht nicht aus, um das Ereignis einzuordnen.

3. rasdaemon-Aufzeichnung und Zählerbasis einrichten

Unter Debian 12 lässt sich rasdaemon aus den Distributionspaketen installieren. Vor Änderungen die bestehende Dienstkonfiguration sichern. Nach der Installation sowohl den Dienststatus und die Startparameter als auch den tatsächlich laufenden Prozess prüfen.

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

--status ist nur ein Teil der Prüfung und keine vollständige Zustandsbewertung. Zusätzlich das Dienstprotokoll auf fehlgeschlagene Ereignisabonnements, Berechtigungsfehler und Probleme beim Schreiben in die Datenbank prüfen.

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

Ein laufender Erfassungsprozess garantiert keine dauerhafte Speicherung

Prüfen, ob in den Startparametern -r oder --record aktiviert ist und ob das installierte Paket Datenbankunterstützung bietet. Läuft der Dienst ohne dauerhafte Aufzeichnung, kann ein Neustart des Erfassungsprozesses eine Lücke in den Nachweisen verursachen. Der Datenbankpfad muss anhand der tatsächlichen Paketkonfiguration ermittelt werden; Pfade anderer Distributionen dürfen nicht ungeprüft übernommen werden.

Bei jeder Abfrage sollten mindestens Maschinenkennung, Boot-ID, Abfragezeitpunkt, Controllername sowie die CE- und UE-Zählerstände gespeichert werden. Zählerdifferenzen dürfen nur innerhalb derselben Boot-ID und derselben Datenquelle verglichen werden. Nach einem Systemneustart, dem erneuten Laden eines Moduls oder einem Rückgang des Zählerstands ist eine neue Zählerbasis anzulegen, statt einen negativen Zuwachs zu berechnen und anschließend zu ignorieren.

rasdaemon und EDAC erfassen nicht zwangsläufig denselben Datenumfang. Vor einem Vergleich müssen Ereignistypen, Erfassungsbeginn und Controller abgeglichen werden. Die Gesamtzahlen beider Aufzeichnungen müssen nicht schematisch übereinstimmen.

4. Alarme sollen Risiken vermitteln, nicht Meldungen anhäufen

Es empfiehlt sich, die Überwachung in drei Kategorien aufzuteilen: Ausfall der Erfassungskette, neue CE-Ereignisse und neue UE-Ereignisse. Zu Ausfällen der Erfassungskette gehören ein gestoppter Dienst, fehlgeschlagene Messwertabfragen und Fehler bei Datenbankabfragen. Dafür sind eigene Alarme erforderlich. Ein Fehlerzustand darf nicht durch den Zahlenwert null ersetzt werden.

Benachrichtigungen zu neuen CE-Ereignissen sollten den aktuellen Zuwachs, den Controller und das ursprüngliche Ereignis enthalten. Sind Ortsangaben in den Datensätzen vorhanden, können wiederholte Ereignisse nach ihrem Ort zusammengefasst werden. Eine für alle Maschinen gültige „unbedenkliche Anzahl“ sollte jedoch nicht festgelegt werden. Ereignisrate, Häufung und Symptome im Anwendungsbetrieb müssen gemeinsam bestimmen, wann eine Eskalation erforderlich ist.

Neue UE-Ereignisse sind mit höherer Priorität zu behandeln. Nach der Sicherung des aktuellen Zustands muss die Integrität der Anwendungen und ihrer Daten geprüft werden. Den Fehler nicht durch zusätzliche Stresstests bestätigen und die Maschine nicht zunächst neu starten, nur um die Zähler zurückzusetzen.

Die Alarmierungskette lässt sich mit Offline-Testdaten prüfen: Zwei Zählereingaben für den Zustand vor und nach einer Änderung erstellen und damit getrennt einen Zuwachs von null, einen CE-Zuwachs, einen UE-Zuwachs, eine fehlgeschlagene Abfrage und eine geänderte Boot-ID testen. Testmeldungen deutlich als Übung kennzeichnen. Sie werden ausschließlich dem Monitoring-Parser zugeführt und nicht in die echte Hardware-Ereignisdatenbank geschrieben.

Auf Produktivhosts wird die Zustellung von Benachrichtigungen nicht durch Fehlerinjektion geprüft. Ein erfolgreicher Benachrichtigungstest bestätigt lediglich, dass Auswertung und Zustellung funktionieren. Ob Hardwareereignisse vom Kernel empfangen werden können, muss weiterhin gesondert anhand des Treiberstatus, der Ereignisquellen und tatsächlicher Aufzeichnungen geprüft werden.

5. Belege sichern, die die Hardwareanalyse voranbringen

Bei wiederholten Fehlern zunächst das Kernel-Log des aktuellen Boot-Zyklus, das rasdaemon-Dienstprotokoll und die Ergebnisse der Ereignisabfragen exportieren. Anschließend einen aktuellen Stand der Zähler sichern. Die Zugriffsrechte auf das Verzeichnis zur Beweissicherung einschränken. Vor dem Anhängen von Dateien an ein Support-Ticket prüfen, ob sie Adressen, Kontodaten oder sensible Informationen aus dem Anwendungsbetrieb enthalten.

Das Support-Ticket in folgender Reihenfolge aufbauen:

• Maschinenkennung, Betriebssystem- und Kernel-Version sowie Boot-ID.
• Zeitpunkt der ersten Feststellung mit eindeutiger Zeitzone und Angabe, ob weiterhin neue Fehler auftreten.
• Ursprüngliche CE- und UE-Ereignisse sowie Zählerstände vor und nach der Änderung, nicht nur Screenshots von Alarmen.
• Controller- und Ortsangaben aus den Berichten; fehlende Felder ausdrücklich kennzeichnen.
• Zeitgleiche Symptome im Anwendungsbetrieb sowie bereits durchgeführte Maßnahmen und deren Ergebnisse.

DIMM-Bezeichnungen oder Adressen aus Ereignismeldungen dürfen nicht eigenständig in physische Steckplatznummern umgerechnet werden. Die Zuordnung kann je nach Plattform unterschiedlich sein. Die Lokalisierung der betroffenen Hardware übernehmen die Support-Mitarbeiter anhand der Maschineninformationen. Der Mieter ist für den Schutz des Betriebssystems, der Anwendungsdaten und der Backups verantwortlich.

Das Ergebnis der regelmäßigen Prüfung ist kein Screenshot, auf dem „alles grün“ ist. Es besteht aus einer nachvollziehbaren Zählerbasis, einem klar dokumentierten Abdeckungsumfang der Datenquellen, einer erprobten Alarmierungskette und vollständigen Fehlernachweisen. Nach einem Kernel-Update oder einem Neustart der Maschine müssen diese Voraussetzungen erneut geprüft werden, damit ein Ausfall der Erfassung nicht mit dem Verschwinden der Fehler verwechselt wird.

Häufig gestellte Fragen