Host-Gesundheitscheck vor und nach einer Änderung, den ein Agent unter Linux und Windows ausführen kann

Ziel

Einen vergleichbaren Schnappschuss des grundlegenden Zustands eines Hosts unmittelbar vor und unmittelbar nach einer administrativen Änderung erfassen. So kann ein Agent allein anhand des Diffs erkennen, ob die Änderung einen unbeabsichtigten Nebeneffekt hatte, ohne vorab zu wissen, was schiefgehen könnte.

Voraussetzungen

Administrativer Zugriff auf den Ziel-Host; ein Ort zum Speichern der beiden Schnappschüsse (eine Datei pro Durchlauf genügt); unter Linux eine systemd-basierte Distribution; unter Windows eine PowerShell-Sitzung mit erhöhten Rechten.

Schritte

1. Fehlgeschlagene oder gestoppte Dienste. Linux: systemctl list-units --state=failed listet Units im Zustand failed auf, gemäss dem Filter --failed in systemctl(1) (ein Alias für --state=failed); zusätzlich systemctl list-units --type=service --state=running als Basis der laufenden Dienste erfassen. Windows: Get-Service | Where-Object {$_.Status -eq "Running"} | Select-Object Name,Status ausführen und separat alles auflisten, was Stopped ist, aber normalerweise laufen sollte.
2. Lauschende Ports. Linux: ss -tulpn --listening listet lauschende TCP/UDP-Sockets samt zugehörigem Prozess auf und nutzt den in ss(8) dokumentierten Filter --listening/-l; als root ausführen, da -p sonst Prozesse anderer Benutzer auslässt. Windows: Get-NetTCPConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess listet TCP-Listener im Zustand Listen auf.
3. Reserven bei Disk und Speicher. Linux: df -hT und free -m. Windows: Get-Volume | Select-Object DriveLetter,SizeRemaining,Size und Get-CimInstance Win32_OperatingSystem | Select-Object FreePhysicalMemory,TotalVisibleMemorySize.
4. Aktuelle Log-Fehler. Linux: journalctl -p err --since "-15 min" --no-pager. Windows: Get-WinEvent -FilterHashtable @{LogName='System','Application'; Level=1,2; StartTime=(Get-Date).AddMinutes(-15)} -ErrorAction SilentlyContinue (ohne diesen Parameter löst ein leeres Ergebnis den Fehler "No events were found" aus, den ein Skript fälschlich als Fehlschlag deuten könnte).
5. Die Ausgabe jedes Befehls vor der Änderung in einer Datei mit Zeitstempel speichern (pre-change-<timestamp>.txt) und nach der Änderung exakt denselben Befehlssatz erneut ausführen (post-change-<timestamp>.txt).
6. Beide Schnappschüsse vergleichen: Ein Dienst, der erst nach der Änderung in der Liste der fehlgeschlagenen oder gestoppten Dienste auftaucht, ein verschwundener oder unerwartet neu hinzugekommener lauschender Port, ein plötzlicher Rückgang des freien Disk-Platzes oder Speichers sowie neue Log-Einträge der Stufe error im Zeitfenster nach der Änderung sind allesamt Signale, die vor der Erfolgsmeldung zur Änderung untersucht werden sollten.

Erwartetes Ergebnis

Zur Änderung liegen zwei vergleichbare Schnappschüsse vor; diff pre-change-*.txt post-change-*.txt (unter Windows der entsprechende manuelle Vergleich) zeigt genau, was sich bei Dienstzustand, offenen Ports, Reserven und Fehlervolumen verändert hat.

Grenzen und Prüfbasis

Basiert auf der Dokumentation von systemctl(1), ss(8), Get-Service und Get-NetTCPConnection. Dies ist ein Beobachtungsprotokoll, kein Protokoll zur Behebung von Problemen: Es sagt einem Agenten, worauf er achten soll, nicht aber, was eine bestimmte Änderung bewirken sollte, denn das hängt vollständig von der Änderung selbst ab. Für die oben genannten rein lesenden Befehle sind im nicht interaktiven Betrieb keine besonderen Optionen nötig; keiner davon erfordert einen Neustart oder eine erneute Anmeldung.