Architektur-\u00dcberblick: Schwachstellen von Einplatinencomputern<\/h2>\n
Einplatinencomputer mit ARM-Architektur wie der Raspberry Pi 4 und 5 operieren unter engen thermischen und I\/O-spezifischen Grenzen. Dauerhafte Container-Workloads, h\u00e4ufige Schreibzyklen von Datenbanken und hoher Netzwerkdurchsatz f\u00fchren regelm\u00e4\u00dfig zu unbemerkter Hardware-Degradation. Hohe SoC-Temperaturen aktivieren das dynamische Thermal-Throttling durch die Broadcom-Firmware, was die ARM-Taktfrequenz senkt, ohne dass explizite Fehlermeldungen in den Protokollen von Benutzeranwendungen erscheinen. Ebenso f\u00fchren kontinuierliche zuf\u00e4llige Schreiboperationen auf MicroSD-Karten oder \u00fcber USB angebundenen SSDs zur Ersch\u00f6pfung von Flash-Bl\u00f6cken, I\/O-Engp\u00e4ssen und letztendlich zu korrupten Dateisystemen.<\/p>\n
Die Implementierung einer Bare-Metal-Performance-Diagnose-Pipeline<\/strong> mit Prometheus<\/strong> und Grafana<\/strong> verwandelt intransparente Hardware-Zust\u00e4nde in pr\u00e4zise Zeitreihenmetriken. Durch die Kombination des standardm\u00e4\u00dfigen node_exporter<\/code>-Daemons mit einem spezialisierten Textfile-Collector-Skript lassen sich kritische Raspberry-Pi-Indikatoren \u2013 darunter SoC-Kerntemperaturen, Unterspannungs-Flags, Taktfrequenzen, RAM-S\u00e4ttigung und Speicher-I\/O-Wartezeiten \u2013 alle 15 Sekunden abfragen (die per vcgencmd<\/code> ermittelten Werte aktualisiert das eingeplante Collector-Skript einmal pro Minute), auf Schwellenwertverletzungen pr\u00fcfen und in Echtzeit-Dashboards visualisieren.<\/p>\n\nDatenfluss der Diagnose-Pipeline: Die vcgencmd<\/code>-Werte gelangen \u00fcber Textfile-Collector, Node Exporter und Prometheus bis nach Grafana \u2014 und l\u00f6sen oberhalb von 75 \u00b0C oder bei gesetzter Throttling-Bitmask einen Alarm aus.<\/figcaption><\/figure>\n
Schritt 1: Deployment des Node Exporters und des Textfile-Collectors<\/h3>\n
Zur Erfassung der standardm\u00e4\u00dfigen Linux-Kernel-Telemetrie sowie propriet\u00e4rer Broadcom-Hardwarestatistiken wird node_exporter<\/code> installiert und ein dediziertes Verzeichnis f\u00fcr eigene Metrik-Dateien eingerichtet:<\/p>\n
Erstellung eines Shell-Skripts unter \/opt\/scripts\/rpi-hardware-metrics.sh<\/code>, das SoC-Temperatur, Kernspannung und Hardware-Throttling-Flags mittels vcgencmd<\/code> extrahiert:<\/p>\n
Schritt 2: Neukonfiguration des systemd-Dienstes des Node Exporters<\/h3>\n
Anpassung der systemd-Konfiguration des node_exporter<\/code>, damit Metriken aus dem benutzerdefinierten Textfile-Verzeichnis eingelesen werden:<\/p>\n
Neustart des Dienstes zur \u00dcbernahme der Flags: systemctl restart prometheus-node-exporter<\/code>.<\/p>\n
Schritt 3: Konfiguration des Prometheus-Scrapers<\/h3>\n
Bereitstellung von Prometheus via Docker Compose mit network_mode: host<\/code> und Konfiguration eines 15-Sekunden-Scrape-Intervalls auf das lokale Node-Exporter-Ziel:<\/p>\n
Schritt 4: Grafana-Deployment und Import von Bare-Metal-Panels<\/h3>\n
Start von Grafana via Docker Compose, ebenfalls mit network_mode: host<\/code>, Einbindung der Prometheus-Datenbank (http:\/\/127.0.0.1:9090<\/code>) als Standard-Datenquelle und Erstellung von Dashboard-Panels auf Basis folgender PromQL-Abfragen:<\/p>\n
\n
SoC-Kerntemperatur-Panel:<\/strong> rpi_soc_temperature_celsius<\/code> (Alarm-Schwellenwert konfiguriert bei > 75 \u00b0C).<\/li>\n
Unterspannungs- & Throttling-Alarm:<\/strong> rpi_soc_throttled_bitmask > 0<\/code> (Signalisiert unzureichende Netzteile oder \u00dcberhitzung, aktuell oder seit dem letzten Start; bleibt bis zum Neustart aktiv).<\/li>\n
Speicher-I\/O-Auslastung:<\/strong> rate(node_disk_io_time_seconds_total[1m]) * 100<\/code> (Erkennt Flash-Controller-Engp\u00e4sse und abgenutzte Speicherbl\u00f6cke).<\/li>\n
Verf\u00fcgbarkeitsrate des Arbeitsspeichers:<\/strong> (node_memory_MemAvailable_bytes \/ node_memory_MemTotal_bytes) * 100<\/code>.<\/li>\n<\/ul>\n
Schritt 5: Qualit\u00e4tssicherung und Stress-Tests<\/h3>\n
Zur Verifikation, dass die Telemetrie-Pipeline Hardware-Auslastungen korrekt protokolliert, m\u00fcssen Lasttests durchgef\u00fchrt werden:<\/p>\n
\n
Validierung der I\/O-Last:<\/strong> Ausf\u00fchrung eines intensiven Schreibtests mit fio<\/code> (z. B. fio --name=test --ioengine=libaio --rw=randwrite --bs=4k --size=1G<\/code>) und Kontrolle, ob das Grafana-I\/O-Wait-Panel Echtzeit-Latenzspitzen anzeigt.<\/li>\n
Simulation von Thermal-Throttling:<\/strong> Auslastung aller ARM-CPU-Kerne \u00fcber stress-ng --cpu 4 --timeout 120s<\/code> bei gleichzeitiger \u00dcberwachung von rpi_soc_temperature_celsius<\/code> in Prometheus, um die pr\u00e4zise Temperaturmessung bis zum Einsetzen der K\u00fchll\u00fcfter zu best\u00e4tigen.<\/li>\n
Audit des Textfile-Parsings:<\/strong> Ausf\u00fchrung von curl -s http:\/\/127.0.0.1:9100\/metrics | grep rpi_<\/code> im Terminal zur Verifikation, dass eigene Spannungs- und Throttling-Metriken fehlerfrei und ohne Syntax-Probleme bereitgestellt werden.<\/li>\n<\/ol>\n
Zusammenfassung und resultierender Mehrwert<\/h2>\n
Was sich damit erreichen l\u00e4sst:<\/strong> Der Aufbau einer autonomen Bare-Metal-Hardware-Diagnose-Pipeline auf dem Raspberry Pi mittels Prometheus-Scraper, eigenen SoC-Textfile-Collectors und Grafana-Dashboards.<\/p>\n
Resultierender Mehrwert:<\/strong><\/p>\n
\n
Fr\u00fcherkennung von Speicherausf\u00e4llen:<\/strong> Die kontinuierliche \u00dcberwachung von I\/O-Wartezeiten und Flash-Verschlei\u00df erm\u00f6glicht den pr\u00e4ventiven Austausch abgenutzter SD-Karten oder SSDs vor einem Dateisystemschaden.<\/li>\n
Vermeidung von Thermal-Throttling:<\/strong> Die Echtzeit-Sichtbarkeit von SoC-Temperaturen und Throttling-Bitmasken garantiert, dass containerisierte Dienste dauerhaft mit maximaler Taktfrequenz operieren.<\/li>\n
Qualit\u00e4tskontrolle der Stromversorgung:<\/strong> Die sofortige Protokollierung von Unterspannungs-Flags (Bit 0, bitmask 0x1<\/code>) identifiziert defekte USB-C-Netzteile oder \u00fcberm\u00e4\u00dfigen Stromverbrauch angeschlossener Peripherieger\u00e4te vor Hardware-Abst\u00fcrzen.<\/li>\n<\/ul>\n
\n
Fragen und Antworten<\/h2>\n
Warum bleibt der Throttling-Alarm nach einem einzigen Vorfall bis zum n\u00e4chsten Neustart aktiv?<\/h3>\n
Weil get_throttled zwei Arten von Bits liefert. Die unteren Bits beschreiben den Zustand im Augenblick, darunter Bit 0 f\u00fcr Unterspannung und Bit 2 f\u00fcr Drosselung. Die Bits ab 16 halten fest, dass dasselbe seit dem Start irgendwann aufgetreten ist, und bleiben gesetzt, bis der Raspberry Pi neu startet. Ein kurzer Spannungseinbruch am Morgen ergibt deshalb etwa 0x50000 (Unterspannung und Drosselung aufgetreten), dezimal 327680, und dieser Wert bleibt f\u00fcr den Rest des Tages gr\u00f6\u00dfer als null.<\/p>\n
F\u00fcr die Auswertung lohnt es sich, beides zu trennen. PromQL kennt den Operator %, und rpi_soc_throttled_bitmask % 16 > 0<\/code> pr\u00fcft nur die vier unteren Bits, also den aktuellen Zustand; rpi_soc_throttled_bitmask >= 65536<\/code> meldet, dass seit dem Start etwas vorgefallen ist. \u00dcbersichtlicher ist es, das Skript gleich einzelne Metriken je Bit schreiben zu lassen.<\/p>\n
Dazu kommt der Takt des Skripts: Es l\u00e4uft min\u00fctlich, und get_throttled liefert nur den Zustand in diesem Moment. Eine Drosselung von wenigen Sekunden zwischen zwei L\u00e4ufen zeigen die unteren Bits nicht, die Bits ab 16 dagegen schon. Gerade f\u00fcr kurze Unterspannungen ist der festgehaltene Teil deshalb der zuverl\u00e4ssigere.<\/p>\n
Erreicht Prometheus im Container das Ziel 127.0.0.1:9100?<\/h3>\n
Nur mit network_mode: host. In einem gew\u00f6hnlichen Docker-Netz ist 127.0.0.1 der Container selbst, w\u00e4hrend der node_exporter au\u00dferhalb davon direkt auf dem Host l\u00e4uft; das Ziel bleibt dann dauerhaft down. F\u00fcr Grafana gilt dasselbe: Teilen sich beide Container ein Docker-Netz, steht in der Adresse der Datenquelle der Name des Prometheus-Dienstes statt 127.0.0.1.<\/p>\n<\/div>\n
![\"Datenfluss](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/rpi-prometheus-grafana-pipeline-de.png\")