PRTG Sensorplanung

PRTG ist eine ganz einfach und überschaubare Software. Aber ohne etwas Planung und Konzeption wird man schnell den Überblick verlieren, besonders wenn Sie später einmal mehr also die 30 Sensoren der Freeware verwenden möchten. Ein Redesign ist insofern ungeschickt, da die bisherigen Werte der Sensoren nicht exportiert und wieder importiert werden können. Schauen wir uns daher die verschiedenen Aspekte einmal an:

Core und Probes

Wer PRTG erstmals auf einem Server installiert, wird am Ende zwei Dienste wiederfinden:

  • Core
    Der Core-Dienst hält die komplette Konfiguration, stellt einen Webserver für den Zugang per Browser bereit und speichert all die ermittelten Daten. Der Core kann hochverfügbar als Cluster ausgelegt werden. Aber der Core macht selbst keine aktiven Tests.
  • Probe
    Die eigentliche Arbeit der "Überprüfung" von Diensten ist bei den Probes angesiedelt. Die Probe auf dem Code überwacht per Default erst mal den Server selbst aber kann über das Netzwerk im Rahmen der Möglichkeiten (Protokolle, Erreichbarkeit, Berechtigungen) auch andere Server und Dienste überwachen.

Sie können aber in einer PRTG-Umgebung auch mehrere Probes installieren, die alle zum gleichen Core reporten. Eine Probe kann aber auch nur zu genau einem Core berichten.

Sie können in einem Netzwerk zwar mehrere CORE-Installationen im Rahmen der Lizenzen installieren, aber die haben dann nichts gemeinsam. Es sind autarke Systeme. Das kann sogar gewollt sein, wenn z.B. "die Netzwerker" mit PRTG ihre Switches, Router und Leitungen überwachen, während "die Windows Administratoren" mit PRTG eben ihre Server und Dienste kontrollieren. Eine Kopplung zwischen den Core-Installationen gibt es nicht, wenn Sie nicht selbst etwas in der Art wie PRTG Kaskade entwickeln. Nur mit der Windows Enterprise Console können sie in einer GUI mehrere Core-Server nebeneinander öffnen.

Die Konfiguration wird dabei auf dem CORE eingestellt und dann auf die Probe herunter geladen. Die Probe macht also die ganzen Checks auch wenn der CORE nicht erreichbar ist und sendet die Ergebnisse später wieder nach. Der Core kann aus der Ferne sogar ein Update der Probe durchführen. Leider werden aber eigene Sensoren (PRTG:Custom Sensor) nicht repliziert. Wer also eigene Skripte baut, muss diese manuell auf die Probe kopieren, die diese ausführen soll.

Root - Probe - Device -Sensor und die Gruppen

Auch bei der Hierarchie gibt es das ein oder andere zu beachten. Die "Root" ist vorgegeben und nicht zu ändern. Direkt unter der Root sind die Proben angesiedelt, die die Arbeit machen. Die Probe kommuniziert zum PRTG-Core über einen eigenen Port, d.h. die Probe baut den Kontakt zum Server auf. Damit kann die probe durchaus hinter einem NAT-Router stehen, d.h. Sie könnten im Rahmen ihrer Lizenzen eine zentrale PRTG-Instanz aufbauen und bei Kunden entsprechende Proben platzieren.

Unterhalb der Probe können Sie dann "Devices" anlegen. Das sind quasi Gruppierungselemente, die einen Namen oder eine IP-Adresse enthalten und von den darunter angelegten Sensoren genutzt werden. Sensoren sind die eigentliche Prüflogik, die ein oder mehrere Werte zurückliefern. Ein Sensor kann bis zu 50 Werte auf einmal liefern.

Wer etwas mehr strukturieren will, kann zusätzlich unter der Probe auch "Gruppen" anlegen und verschachteln, um darin dann die Devices abzulegen. Beachten Sie aber, dass ein Device damit immer einer Probe zugeordnet ist. Gruppen können aber auch dynamisch selbst nach Devices suchen und diese ins Monitoring aufnehmen. Ein durchaus leistungsfähiges Feature.

Eine Probe mit vielen Remote Skripten vs. viele Probes

Damit müssen wir uns mal Gedanken machen, wie man eigentlich eine PRTG-Installation skaliert. Windows Server können durchaus auch eine PRTG-Probe haben. Eine lokale Probe kann auch ohne Netzwerkverbindung prüfen, so dass Probleme dann nachgemeldet werden. Sie läuft auch als "LocalSystem" und kann damit ohne weitere Anmeldedaten auf dem lokalen Server arbeiten. Auf der anderen Seite wollen Sie vieleicht nicht auf jedem Server eine Probe installieren. Zudem gibt es Server, die keine Probe tragen können (z.B. Unix) und daher sowieso von einer Probe auf einem Windows Server mit überwacht werden. Damit wird aber ein Windows Server zu einer aktiven Komponente bei der Überwachen.

Also könnte man versucht sein, mit vielleicht genau einer Probe zu arbeiten, die ganz viele Devices mit den entsprechenden Sensoren trägt und die Daten "remote abfragt". Dann müssen Sie aber die Skalierung betrachten, denn die Probe kann dann ganz schön viel zu tun bekommen. Zudem muss sie z.B. für Abfragen von Performance Countern, Eventlogs etc. aus der Ferne über entsprechende Anmeldedaten verfügen. Die können Sie in PRTG hinterlegen aber viele nutzen dazu einfach einen Domänen Admin. Das funktioniert natürlich aber stellt ein Risiko dar. Wer auch immer in PRTG damit ein eigenes "Überwachungsskript" ändern kann, hätte so eine Hintertür.

Hinzu kommt, dass bestimmte Sensoren wie z.B. QoS Sensor nur zwischen zwei Probes genutzt werden können. Wer also z.B. sein WAN "ausmessen" will, wird auch im entfernten Netzwerk eine Probe platzieren. Aber das dürfte eh der Regelfall sein, denn eine Überwachung von Servern über WAN ist nicht optimal.

Eine Firma mit mehreren Standorten wird in der Regel an jedem Standort mit Servern auch eine Probe installieren. Dennoch ist es meist der richtige Ansatz mit wenigen Probes zu arbeiten um möglichst wenig Agenten auf Servern zu installieren. Kleine Firmen nutzen also die Probe auf dem Core-Server einfach mit, während große Firmen eigene Probe-Server installieren.

Sensoren und Channel

Das Blatt in einem Baum sind in der PRTG-Welt die Sensoren unter den Devices. Ein Sensor kann im einfachsten Fall einfach einen Wert zurück liefern. So macht das z.B. ein "PING"-Sensor. Es gibt aber auch Sensoren bei PRTG, die mehrere Werte zurückliefern, z.B. der QoS Sensor. Allerdings beziehen sich diese Werte immer auf das gleiche Device unter dem diese Sensor angelegt ist und mehr als 50 Channels sind pro Sensor nicht möglich.

Technisch gibt es hier aber keine Restriktion. Wenn Sie z.B. einen eigenen Sensor bauen (Siehe auch PRTG:Custom Sensor), dann können Sie per Skript Werte von vielen Servern zusammen fassen und als einzelne Channel ausgeben. Allerdings passen diese Daten dann nicht mehr unbedingt zu dem "Device", unter dem der Sensor eingeordnet ist.

Server oder Service Monitoring

Ein Device ist rein von der Übersetzung her ein Gerät. Aber es gibt ja auch "virtuelle Server", z.B. ein Exchange CAS-Array, hinter denen kein einzelner realer Server steht. Hier ist aber zumindest eine virtuelle IP-Adresse vorhanden, die man bei dem Device hinterlegen kann, auch wenn Zugriffe über einen Loadbalancer doch bei einem realen Server landen. Es gibt aber auch Quelle, die gar nicht auf einen Computer angewendet werden können, sondern etwas in der Luft schweben. Wenn ich z.B. aus den Exchange Datenbanken eine Information über die Postfachgrößen ermittle, dann kann ich die nicht einem Device oder einer DAG zuweisen.

Worauf ich hinaus will, ist die Überlegung welche Sensoren sie wo anbinden. Sie können in PRTG problemlos ein Device anlegen und eine nicht vorhandene IP-Adresse oder einen Namen geben, aber keiner der Sensoren nutzt diese Information. Sensoren können leider nicht direkt unter einer Gruppe angelegt werden. Wer also Device-übergreifende Sensoren in einer eigenen Gruppe zusammenfassen will, muss ein Dummy-Device anlegen, unter dem die Sensoren hängen.

PRTG kenn aber noch mit dem "Fabric Sensor" einen besonderen Sensor. Sie können nämlich durchaus klassische mit einem Sensor unter einem Device all die Daten und Werte passend zu dem Device erfassen und dann die Daten von mehreren Devices in so einem virtuellen Sensor zusammenfassen.

Ein Beispiel: Sie haben mehrere Exchange Server mit CAS-Rolle und haben für jeden CAS-Server ein Device mit der IP-Adresse des Servers angelegt. Zudem haben sie einen Sensor, der z.B. den Performance Counter für die MAPI-Verbindungen ermittelt. Ziel ist nun in einem eigenen Sensor die Anzahl der MAPI-Verbindungen aller CAS-Server in einem Diagramm anzuzeigen. Da sind wichtige Daten um die Gleichverteilung der Last und damit die Funktion der Server zu kontrollieren. Das funktioniert z.B. mit dem Fabric Sensor.

Allerdings könnten Sie natürlich auch sagen, dass sie die "CAS-Funktion" überwachen wollen. Also legen Sie ein Device mit der IP-Adresse des CAS-Servers an und addieren hier einen Sensor, der die Performance Counter der Server abfragt und als einen Sensor liefert. Ab dem Moment ist das aber kein "Servermonitoring" oder "Dienstmonitoring" mehr, sondern ein Service-Monitoring. Der selbst gebaute Sensor muss entsprechend konfiguriert werden oder alleine die Backend-Systeme ermitteln. Vorsicht hierbei: So ein Sensor mit vielen Channels ist relativ statisch, d.h. ein einmal angelegter Kanal kann nur noch gelöscht werden, indem der komplette Sensor und mait auch die anderen Kanäle und historischen Daten entfernt werden.

Diese Service-Überwachung wird noch kniffliger, wenn die Quelle des Kanals auch noch den Host wechselt. Ein Beispiel: Sie betreiben eine HyperV-Farm mit mehreren Host-Servern, auf denen VMs laufen. Die VMs sind aber nicht zwingend an den "Host" gebunden sondern können ja auch umziehen und wechseln. Ein Sensor, der nun pro Host die VMs als einzelne Kanäle erfasst, wird hier an seine Grenzen stoßen. Wenn eine VM den Host wechselt, hat der alte Sensor keine Daten für diesem Channel mehr, der Zielhost aber erkennt einen neuen Channel.

Sie sehen schon, dass man hier erst etwas Überlegung und Planung an den Tag legen sollte, ehe man mal eben schnell eine Device und einen Sensor anlegt.

Es gibt einen wichtigen Grund, warum sie immer auch die Dienste auf den einzelnen Servern überwachen sollten: Wenn mehrere Server als Cluster oder Farm die gleiche Funktionalität hochverfügbar bereit stellen, dann müssen Sie als Betreiber aber sehr wohl wissen, welche Server ein Problem haben. Eine reine Überwachung des Service ist daher nur eine Teilmiete.

Insofern kann es sinnvoll sein, wenn man den Status eines "Service" aus den Einzelstatusmeldungen und Werten der gerätebezogenen Daten ermittelt.

Templates

Nehmen wir mal an, sie legen zu jeder IP-Adresse auch ein Device an, hinter dem sich entsprechende Sensoren verbergen, dann kann die Pflege der Sensoren per Autodiscover oder manuell erfolgen. Mit PRTG ist es aber auch möglich die Kollektion von Sensoren eines Geräts als Template zu speichern und an andere Geräte anzuwenden. Wenn Sie also einmal einen Exchange Server mit den gewünschten Sensoren überwachen, müssen Sie beim nächsten Exchange Server nur noch das gleiche Template auswählen und es sind genau diese Sensoren für diesen Server hinterlegt. Natürlich funktioniert das nur sinnvoll für Sensoren, die auch auf das Device ausgerichtet sind.

Monitoring pausieren oder nur Alarmierung unterdrücken?

Auch 24x7 Server haben irgendwann eine Auszeit, z.B. wenn Software aktualisiert oder Patches eingespielt werden. Neben der geplanten Auszeit gibt es natürlich auch noch richtige Ausfälle. Ein Monitoring hat aber nicht nur die Aufgabe Ausfälle zu erkennen und Betriebsdaten zu erfassen, sondern ist aus meiner Sicht auch ein wichtiger Indikator um die Wiederherstellung einer Funktion nach einem Ausfall oder einer geplanten Unterbrechung wieder zu verifizieren.

Ich halte daher nichts davon, wenn ein Administrator das Monitoring eines Servers oder eines Dienstes "pausiert", damit PRTG keinen Fehler meldet. Viel besser finde ich, wenn das Monitoring sehr wohl auch den Ausfall eines Dienstes erkennt. Allerdings sollten im "geplanten Fall" natürlich keine korrigierenden Maßnahmen oder Alarme generiert werden oder gar ein Esklationsprogramm durchlaufen. Einen Server oder ein System "in Wartung" zu versetzen sollte aus meiner Sicht einfach nur die Alarme zu unterdrücken.

Wenn Sie in PRTG einen Sensor, ein Device o.ä. auf "Pause" setzen, dann schalten Sie aber nicht nur die Alarme sondern eben auch die komplette Überwachung ab. Wenn Sie einen Server wieder "repariert" haben, dann kann ihnen PRTG in dem Zustand das nicht zeigen. Sie müssen selbst die Funktion prüfen oder die Überwachung fortsetzen. Wenn es dann noch einen Fehler gibt, verraten Sie sich doch wieder über den Alarm.

Sie können bei PRTG bei dem Device oder dem Sensor auch ein "Maintenance Window" definieren. In der Zeit überwacht PRTG weiter aber sendet eben keine Alarme. Leider gibt es sich in der Version 14 und früher noch keine einfache Option, adHoc ein Maintenance-Fenster wie bei Pause zu starten.

Nebenbei bleibt damit auch das Monitoring eine gute Quelle auch die geplanten Unterbrechungen zu dokumentieren. Bezogen aus den einzelnen Server ist das ja durchaus eine "Ausfallzeit", auch wenn der Anwender vielleicht das gar nicht mitbekommen hat. Die Verfügbarkeit des Servers kann sich ja wieder über die Erreichbarkeit eine Mindestanzahl Server ermitteln lassen. Da wirkt sich die Verfügbarkeit eines einzelnen Servers nicht mehr auf die Gesamtverfügbarkeit aus.

Weitere Links