NAB9 Runtime Monitoring

Das Monitoring ist als PowerShell-7-Skript umgesetzt. Es erfasst Sensorwerte, bewertet den Status, wendet Hysterese und Overshoot an, schreibt Logs und Statefile und sendet Telegram-Alerts bei Statuswechsel. Es kann manuell ausgeführt oder über die Windows-Aufgabenplanung periodisch geplant werden.

Warum PowerShell 7? Native Windows-Integration, Task-Scheduler-Anbindung, direkter Zugriff auf DLLs, REST-/Telegram-Aufrufe ohne Drittsoftware, geringer Runtime-Overhead und lokal betreibbar ohne zusätzliche Plattform.

1. 1 Scriptstart
2. 2 Sensor-Initialisierung
3. 3 CPU-Temperaturwerte erfassen
4. 4 CPU-Auslastung erfassen
5. 5 Temperatur plausibilisieren
6. 6 Base-State bestimmen (Get-BaseState)
7. 7 Hysterese anwenden (Apply-Hysteresis)
8. 8 Overshoot-Label bestimmen (Get-Label)
9. 9 Vorherigen Zustand aus Statefile laden
10. 10 Statuswechsel erkennen
11. 11 Telegram-Alert auslösen (nur bei Wechsel)
12. 12 Logeintrag schreiben
13. 13 Statefile aktualisieren
14. 14 Scriptende

Eine einzige Sensorquelle wäre Single Point of Failure. Die Kaskade greift in dieser Reihenfolge:

• Primär – LibreHardwareMonitor (über LibreHardwareMonitorLib.dll): CPU Package, Core Max, Core Average
• Fallback 1 – OpenHardwareMonitor (über OpenHardwareMonitorLib.dll)
• Fallback 2 – WMI/CIM ThermalZone (MSAcpi_ThermalZoneTemperature) als Last-Resort
• Fallback 3 – LibreHardwareMonitor.exe Report (erfordert ggf. erhöhte Rechte)

Bekannte Stolperfalle in der Umsetzung: Unter PowerShell 7 trat mit bestimmten DLL-Builds der Fehler Method not found: System.Security.AccessControl.FileSecurity auf. Das ist ein Hinweis auf eine .NET-Framework-DLL in einer .NET-Core-Runtime. Lösung: kompatible LibreHardwareMonitor-DLL verwenden oder PowerShell 5.1 für Sensorzugriffe nutzen.

WMI liefert Temperaturwerte in einem ungewöhnlichen Format: Kelvin multipliziert mit 10. Die Umrechnung erfolgt deshalb mit ($value / 10) - 273.15. In der realen Umsetzung lieferte WMI für den NAB9 trotz spürbarer CPU-Last nur 27.9 °C. Der Grund: WMI greift oft nur auf ACPI-/System-Thermal-Zones zu, nicht auf die echten CPU-Core-Sensoren. Je nach BIOS und Hersteller liefert WMI deshalb unplausibel niedrige Werte. Deshalb wird WMI bewusst nur als Last-Resort verwendet, wenn LibreHardwareMonitor und OpenHardwareMonitor beide ausfallen.

Temperatur und Load werden in vier Betriebszustände übersetzt: OK, WARN, CRIT, SENSORERROR. Schwellwerte sind konfigurierbar (z. B. WARN ab 70 °C, CRIT ab 80 °C).

Hysterese: Ein Downgrade erfolgt erst, wenn die Temperatur klar unter Schwelle − Hysterese fällt. Damit wird Flattern um die Schwelle herum verhindert.

Overshoot: Liegt der Wert deutlich über der Schwelle, erzeugt das Skript ein zusätzliches Label (WARN_OS, CRIT_OS). Der Base-State bleibt gleich, der Betrieb erkennt aber, dass die Lage relevanter ist.

Das Statefile speichert den letzten bekannten Zustand. So sendet das System nicht bei jedem Lauf dieselbe Meldung, sondern nur bei echten Statuswechseln, beim Erstauftreten eines Sensorfehlers oder bei explizit aktiviertem AlwaysNotify.

• prev = OK, neu WARN → Meldung wird gesendet
• prev = WARN, neu wieder WARN → keine Meldung
• prev = CRIT, Temperatur sinkt aber bleibt über CRIT−Hysterese → keine verfrühte Entwarnung
• Sensorfehler nach OK → eigenständiger SENSORERROR-Alert

Bot-Token und Chat-ID liegen ausschliesslich in Umgebungsvariablen (TELEGRAM_BOT_TOKEN, TELEGRAM_CHAT_ID). Sie befinden sich niemals im Skript.

Das Logfile enthält Skriptstart, Sensorinformationen, Fehler, Statusbewertung, Telegram-Versand und „Keine-Meldung"-Fälle, jeweils mit Zeitstempel. Eine konfigurierbare Retention (z. B. 2 Tage) entfernt alte Einträge automatisch. Zusätzlich kann eine maximale Logfile-Grösse definiert werden.

So bleibt das Logfile langfristig lesbar und ohne Log-Wildwuchs. Die Lösung bleibt damit nachvollziehbar wartbar.

Das Skript wird über die Windows-Aufgabenplanung periodisch ausgeführt, typischerweise im Minuten- oder Stundenintervall. Damit entsteht eine kontinuierliche Runtime-Überwachung ohne dauerhaft laufenden Dienst.

• Hintergrundausführung mit minimaler Last
• Autostart nach Reboot
• Konfigurierbares Intervall
• Logging deckt jeden Lauf ab

Die strukturierten Alert-Felder (Host, Status, Temperatur, Load, Quelle, Zeitstempel) sind so vorbereitet, dass sie in ein ITSM-/Ticket-System überführt werden können. Sie sind konzeptionell anschlussfähig an Jira-/Servicedesk-Prozesse. Betriebsereignisse bleiben über Logs nachvollziehbar.

Alle Komponenten der Lösung liegen in einer klar definierten Verzeichnisstruktur. Das macht Wiederherstellung, Migration oder Übergabe an Operations trivial.

C:\DATEN\PowerShell_Scripte\TempMonitor\
  ├─ TempMonitor.ps1              # Hauptskript
  ├─ TempMonitor.log             # Runtime- und Betriebslog
  ├─ TempMonitor.state          # Letzter bekannter Zustand
  ├─ LibreHardwareMonitorLib.dll  # Primäre Sensorbibliothek
  ├─ OpenHardwareMonitorLib.dll   # Fallback-Sensorbibliothek
  ├─ LibreHardwareMonitor.exe     # Optionaler EXE-Fallback
  ├─ LibreHardwareMonitor\
  ├─ OpenHardwareMonitor\
  ├─ Logs\
  └─ Archive\

Die aktuelle Lösung deckt CPU-Temperatur, Load, Statusmodell und Alerting ab. Die Architektur ist bewusst modular gehalten, damit weitere Monitoring-Dimensionen ohne Neuaufbau ergänzt werden können. Mögliche Erweiterungen: