New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


Windows Prozess auf Speicherbedarf überwachen - Nicht immer vorhanden

Votes:

0

Your Vote:

Up

Down

Es gibt auf einem unserer Server einen Windows Prozess, welcher nicht immer vorhanden ist. Eigentlich ist dieser nur zur Ausführung bestimmter Vorgänge aktiv und wird danach sofort wieder beendet. Läuft das ordnungsgemäß, dann ist der Prozess auch beendet und nicht mehr vorhanden.

Allerdings gibt es seltene, aber kritische Situationen in diesen der Windows Prozess nicht ordnungsgemäß beendet wird. Dann fängt dieser Prozess an, kon­ti­nu­ier­lich Speicher zu reservieren. Es dauert im Schnitt ca. 10 min. bis dann Windows träge wird und keine Remote Verbindungen mehr aufgebaut werden können. Ebenfalls werden Powershell Sessions dann unterbrochen oder kommen nicht zustande. Einzige Möglichkeit ist es so schnell wie möglich reagieren zu können und den Prozess zu beenden. Taskkill war da bisher sehr hilfreich.

Wir möchten nun diesen Prozess überwachen und zwar so, dass wir sofort alarmiert werden, wenn dieser Prozess eine gewisse Menge an Speicher reserviert hat und evtl. wenn er länger als eine vorgegebene Zeit existiert. Die Überwachung des reservirten Speichers hat aber die höhere Priorität.

Wir haben auch schon ein VB-Skript welches Grundsätzlich in der Lage ist, den Speicherbedarf eines vorgegebenen Prozesse an PRTG zu übergeben. Ebenfalls ignoriert das Skript, wenn der Prozess nicht vorhanden ist. Dafür benötigen wir nämlich keine Warnung oder ein Rückgabewert an PRTG.

Das Problem entsteht dann, wenn der Prozess zwischen den Intervallen des Sensors erzeugt wird und schnell viel Speicher reserviert. Dann kommt es schonmal vor, dass die nächste Anfrage keinen Rückgabewert enthält. Keine n Rückgabewert erhält der Sensor aber auch, wenn der Prozess nicht vorhanden ist. In diesem Fall bekommen wir ein "0:OK" zurück mit 0 MB Speicherbedarf des Prozesses.

Wir suchen nun nach einer Möglichkeit zu garantieren, dass PRTG 100% die Information erhält, wenn der Prozess vorhanden ist und wieviel Speicher er reserviert.

Die Suche hier in der Paessler Knowledge Base ergab den Treffer für das Skript. Allerdings gab es leider keinen Trefferfür unser Proeblem. Nämlich das die Abfrage dadurch behindert wird, dass der Prozesse den Server quasi "lahmlegt" und der Server dem Skript nicht mehr Antwortet.

Daher habe ich gehofft, dass hier jemand Idee hat.

Danke im Voraus für jeden Tipp, Hinweis oder Hilfe.

Grüße Patrick

custom-script-exe custom-sensor process windows-server

Created on Jun 13, 2019 2:28:23 PM by  Patrick_ST (0) 1 1



6 Replies

Votes:

0

Your Vote:

Up

Down

Hi Patrick,

danke für deine Anfrage.

Das alles sollte ohne weiteres mit PRTG Boardmitteln machbar sein. Eine vorstellbare Lösung meines Erachtens wäre:

  • Überwachung des Prozesses mit dem Windows Process Sensor. Dieser überwacht im Kanal "Working Set" die Speicherauslastung in Bytes.
  • Einstellen eines Grenzwertes/Limits auf eben jenen Kanal, dass sich der Sensor-Status zu Down ändert, sobald eine gewisse Auslastung überschritten ist. Wie das funktioniert ist entweder hier im Manual oder hier im Video erklärt.
  • Notification Trigger des Sensors so anpassen, dass bei Down des Sensors eine Benachrichtigung ausgelöst wird, welche in ihren Einstellungen sowohl eine E-Mail zur Info versendet als auch ein Programm, in deinem Fall taskkill, auslöst.

Bei den WMI Sensoren empfehle ich kein geringeres Scanning Interval als 60 Sekunden einzustellen. Das sollte für gewöhnlich ausreichen. Sollte es zu Performance-Problemen, bspw. durch zu viele WMI Sensoren in einem zu kurzen Interval auf der Probe kommen, dann lege für dieses ganze Szenario eine eigene, dedizierte Remote Probe an.

Solltest du noch Frage oder Anmerkungen haben, melde dich ruhig.
Sebastian

Created on Jun 14, 2019 6:36:37 AM by  Sebastian Kniege [Paessler Support]

Last change on Jun 14, 2019 6:37:19 AM by  Sebastian Kniege [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hallo Sebastian,

den Windows Process Sensor zu nehmen war natürlich unsere erste Idee. Allerdings ist das Problem, das der Sensor in den Down Status geht, wenn der Prozess nicht existiert.

Genau darin liegt ja unser Problem. Der Prozess wird von einer Software auf dem Server erzeugt und sobald dieser Vorgang durchgelaufen ist, wird der Prozess idealerweise wieder beendet. Manchmal klappt das nicht und der Prozess bleibt und fängt an unaufhörlich Sepciher zu reservieren bis er gekillt wird. An dem Verhalten können wir leider auch nichts ändern.

Grüße Patrick

Created on Jun 14, 2019 7:20:19 AM by  Patrick_ST (0) 1 1



Votes:

0

Your Vote:

Up

Down

Hi Patrick,

Ja, das sehe ich ein und auch können wir beim Sensor kein anderes Verhalten einstellen. Aber wo genau besteht das Problem dabei?

Der Sensor ist down und unabhängig davon ob er nun läuft oder nicht, kann vorsorglich ja trotzdem mit taskkill gearbeitet werden. Im Hintergrund bekommt das Script (Programm) dann lediglich die Meldung, dass der Prozess nicht gefunden werden konnte.

Was den Down Status angeht, könnte überlegt werden, ob man den Sensor nach x Minuten automatisch bestätigt, das betrifft dann aber natürlich auch Zustände, bei denen der Sensor zurecht (zuviel Speichernutzung) down ist.

Grüße,
Sebastian

Created on Jun 14, 2019 9:08:44 AM by  Sebastian Kniege [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hallo Sebastian,

naja eine Sensor der im Down Status sich befindet löst ein Alarm aus. In unserer Infrastruktur mit PRTG nehmen wir Alarme ernst. Spass beiseite. Wir finden einen Sensor im Down Status der eine Alarm auslöst nicht gut und wie du bereits gesagt hast, das bestätigen nach x Minuten des Sensors führt wiederum dazu, dass eben auch andere Zustände, die den Sensor in den Down Status versetzen, bestätigt werden.

Ich hatte ja auch in meinem ersten Eintrag geschrieben, dass es problematisch sein kann, wenn der Prozess bereits mit der Speicherreservierung begonnen hat, dann noch eine vernünftige Antwort vom entsprechenden Server zu bekommen. Daher müssen wir eine Methode verwenden, bei der wir sicher sein können, dass im Normalzustand der Sensor keine Alarme auslöst, weil z.B. der Prozess noch nicht existiert. Erst dann können wir mit eine gewissen Sicherheit sagen, dass Alarme vom diesem Sensor ernt zu hemen sind. Genau in diesem Fall mit diesem Prozess ist das elementar wichtig, sich auf die Meldung des Sensors zu verlassen.

Deswegen versuche ich so ausführlich zu sein. Der Server ist ein vitales System und der Prozess, wenn nicht ordnungsgemäß beendet, kann dieses System erheblich stören. Deswegen suchen wir eine Lösung mit PRTG, um hier eine Hohe Zuverlässigkeit beim alarmieren zu haben.

Grüße Patrick

Created on Jun 14, 2019 11:24:40 AM by  Patrick_ST (0) 1 1



Votes:

0

Your Vote:

Up

Down

Hallo Patrick,

das verstehe ich natürlich nur leider kommen wir dann an die Grenzen des Sensors, da der Prozess laufen muss.

Du schriebst eingangs, dass Ihr bereits ein VB-Script erstellt habt, mit welchem die Überwachung möglich sei, es nur problematisch würde, wenn der Prozess "schnell viel Speicher" reserviert. Abhängig von der aktuellen Auslastung und abhängig von der Zeit für die Rückgabe des VB-Scripts, würde ich auch hier nicht empfehlen ein Scanning Interval unter 60 Sekunden zu wählen. Reicht denn das irgendwie aus?

Ich sehe hier in dem Fall sonst tatsächlich keine andere Lösung als einen Custom Sensor.

Grüße,
Sebastian

Created on Jun 17, 2019 7:23:07 AM by  Sebastian Kniege [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hallo Sebastian,

ja über ein Custom Sensor haben wir es mit dem VB Skript bereits "gelöst". Ich habe das Intervall jetzt auf 60 Sek. stehen und schaue mal, ob das ausreicht.

Vielen Dank für deine Hilfe und deine Tipps.

Grüße Patrick

Created on Jun 19, 2019 7:09:19 AM by  Patrick_ST (0) 1 1



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.