PRTG-Reboot

PRTG-Reboot

Diese Seite zeigt, wie ein PRTG-Custom/XML Sensor nicht nur bestimmte Werte überwachen und melden kann, sondern auch aktiv an der Heilung beteiligt werden kann.

Vorgeschichte

Der Anlass für diesen einfachen aber effektiven Sensor war eine VM, auf der ein Prozess anscheinend sporadisch Speicher gefressen hat und selbst zwar noch lief aber doch nicht mehr funktionierte. Allein am Hauptspeicher konnte die Situation zuverlässig erkannt werden. Als "Notlösung" wurde daher erst ein Skript entwickelt, welches per Taskplaner alle Stunde gestartet wurde. Der relevante Teil ist sehr übersichtlich:

$os = Get-Ciminstance Win32_OperatingSystem
if ($os.FreePhysicalMemory -lt 500000) {
   restart-computer -force
}

Der Job wurde dann als "geplanter Task" eingestellt und versah seinen Dienst. Allerdings fehlte natürlich eine Überwachung, ob der Tasks auch wirklich gestartet wurde. Da kam dann die Idee auf statt des Windows Taskplaners einfach PRTG zu missbrauchen.

PRTG Probe als Taskplaner

Wir haben dazu auf dem Windows Server selbst einfach eine PRTG-Probe installiert., so dass wir auf "Remote Commands" etc. verzichten können. Wenn ein Server aufgrund von Speichermangel keine Verbindungen mehr annimmt, dann kann eine entfernte Probe das zwar melden aber eben auch keinen Neustart mehr initiieren. Zumindest solange es sich nicht um eine VM handelt oder ein anderes Remote Management den Druck auf den virtuellen oder realen Power-Button/Reset-Button erlaubt.

Das obige Skript wurde dann natürlich um Parameter und eine Ausgabe der Aktionen auf STDOUT erweitert, so dass die Rückgabe auch von der Probe ausgewertet werden kann. Über die Einrichtung eines "Custom EXE/XML"-Sensors auf der Probe wurde dann dafür gesorgt, dass die PRTG-Probe das PowerShell-Script alle Minute einmal aufruft. Das Skript hat erst mal den freien Speicher geprüft und bei der Unterschreitung einen Neustarts erzwungen. Hierbei konnten wir aber nicht auf "Restart-Computer" zurückgreifen, da dieses Commandlet den Restart sofort eingeleitet hat. Das Skript konnte die Info daher gar nicht mehr an PRTG senden. Daher haben wir mit dem alten "shutdown.exe" den Reboot mit einer Verzögerung von 30 Sekunden eingestellt.

Damit durch einen Programmfehler hier keine Endlosschleife mit Reboot passiert, prüft das Skript die Uptime und verhindern eine einstellbar Zeit (60 Min Default) den Reboot.

So konnte das Skript auch den anstehenden Reboot selbst noch als Meldung an PRTG schreiben. Es ist sogar möglich vom fraglichen Prozess zu Fehlersuche einen DUMP anzufertigen und erst dann neu zu starten.

Ausgabe

Die Probe erfasst die Werte und sendet sie an den PRTG-Server, der letztlich dann die Daten anzeigt. Hier sehen Sie einen Abschnitt von zwei Stunden.

  • Obere hellblaue Linie: Physical RAM
    Das ist der gesamte sichtbare Speicher. Das sollte eine Linie bleiben, es sei denn der VM-Host ändert den bereitgestellten Speicher. Es könnte aber auch sein, dass die Hardware ein defektes Modul hat, welches vom BIOS dann ausgeblendet wird
  • Untere graue Linie: Reboot Limit
    Wenn der verfügbare Speicher unter diese Linie kommt, dann startet das Skript neu. Auch diese Linie ist normalerweise waagrecht, es sei denn Sie verändern den Parameter für den Grenzwert
  • Roter Graph: Free Memory
    Dies ist die absolute Menge an "freiem Speicher"
  • dunkelblaue Anzeige
    Der freie Speicher in Prozent.
  • Dünne gelbe Linie: Uptime
    Diese ansteigende Linie zeigt die Uptime des Systems an,. So kann ein Reboot schnell ermittelt werden.

In dem folgenden Bild sehen Sie exemplarisch einen 2-Stunden Abschnitt eines Systems

Die gelbe Linie zeigt an, dass am Anfang (c 7:15) das System gebootet wurde und dann ca. eine Stunde später gegen 08:15 erneut durchgestartet wurde. ist auch gut zu sehen, wie der Speicher immer wieder weiter abnimmt. Beim zweiten Messintervall ist es schon sehr nahe an der unteren Grenze. Der Neustart ist hier wohl nur eine Frage der Zeit.

Download

Das Skript ist wirklich keine "Meisterleistung" und daher entsprechend übersichtlich. Aber vielleicht ist es daher gerade für erste Gehversuche in eine Überwachung durch PRTG samt "Problemlösung" zu sehen

prtg-reboot..ps1.txt

Intern nutze ich ein Skript, welches vor dem Neustart noch schnell einen DUMP des zu überwachenden Prozesses zieht. So kann der Entwickler sich dann gleich auf die Suche nach dem Fehler begeben.

Weitere Links