PRTG Plattform

PRTG ist einfach aber eine kurze Einführung hilft bei der Planung der Installation und Konfiguration. Ich nutze diese Seite und die Bilder um Kunden und interessenden ganz schnell einen Überblick in PRTG zu geben und die Grenzen aufzuzeigen.

Diese Seite ersetzt nicht das Handbuch, die sehr gute KB von Paessler und deren Videos.

PRTG Tutorial: A Quick Overview of Our Monitoring Solution
https://www.youtube.com/watch?v=iT5y44h8Lng

Was ist PRTG.. Und was nicht

PRTG ist eine überschaubare (im positiven Sinne) Software, mit der man Server, Netzwerkgeräte und Dienste überwachen und numerisch erfassen kann. Es gibt eine ganze Menge ähnlicher Produkte (WhatsUp, HostMon, ServersAlive, Nagios, Cacti, etc.) die ähnliche Bereiche abdecken aber aus meiner Sicht hat PRTG einige besondere Funktionen. PRTG macht es einfach Netzwerkswitches per SNMP zu überwachen und hat für mich besonders wichtig auch QoS-Sensoren, NetFlow/SFlow und viele vordefinierte Tools. Eine offene API erlaubt es mir ganz einfach eigene Werte nachzurüsten. Dass PRTG eine reine Windows Software ist, ist für mich eher ein Vorteil, da ich so mit PowerShell, VBScript, WMI anstelle von RCMD, PHP und Perl arbeiten kann. In einer Welt fühlt man sich eben wohler, auch wenn die andere Welt (Siehe Arduino oder RaspberryPI) durchaus auch kenne.

Für das Verständnis ist es aber auch wichtig zu wissen, was PRTG nicht ist:

  • PRTG kann Netzwerke überwachen aber ..
    ...es ist kein Netzwerkmanagement im klassischen Sinne. Sie können zwar "Maps" erstellen und Switches samt Port darin abbilden aber vergleichen Sie PRTG nicht mit einem OpenView, CiscoWorks oder anderem System eines Herstellers, mit dem Netzwerkkomponenten sehr viel tiefer überwacht und auch konfiguriert werden können. Gerade KMUs sind aber schon froh, wenn Sie die Auslastung von Ports und NetFlow-Diagramme erhalten können.
  • PRTG kann Events überwachen aber..
    ...es ist kein Eventlog Management oder gar SIEM-System. Zwar können Events per SYSLOG eingeliefert werden aber eine Knowledgebase wie SCOM kann kaum ein anderer Hersteller liefern. für Logmanagement gibt es andere Spezialisten und diese sollten Sie dazu auch einbeziehen.
  • PRTG ist kein Hardwaremanagement, aber..
    es kann natürlich Alarme und Kennzahlen von Fujitsu ServerView, Dell OpenManage, HP Insight und anderen auslesen und basierend darauf alarmieren.

Sie sehen also, dass es für viele Dinge passende Spezialprogramme gibt und ein Tool allein gar nicht alles abbilden kann. Die Stärke von PRTG ist, dass es in vielen Umgebungen mit geringem Aufwand, geringen Kosten und wenig Anpassung sehr schnell eine Überwachung ermöglichen kann.

Es gibt eine Freeware mit bis zu 30 Sensoren. Ideal für erste Gehversuche und sich selbst klar zu werden, welchen Grad einer Überwachung sie brauchen. Was hilft ihnen das große Paket, wenn Sie es nie an den Start bekommen ?

Ich nutze PRTG sehr gerne z.B. Um bei einer Exchange Migration die Zielserver während des Projekts zu überwachen oder im Vorlauf eines Lync Projects z.B. WAN-Leitungen auszumessen. Das geht auch wunderbar mit der Freeware mit bis zu 30 Sensoren. Es würde mich nicht wundern, wenn einige dieser PRTG-Pilotinstallation von mir unbemerkt mittlerweile lizenziert wurden.

Die Komponenten von PRTG

Was bedeutet aber 30 Sensoren für "Free" und was ist der Core, eine Probe, ein Device, ein Sensor und ein Kanal ?. Kommen wir zu einem kurzen Überblick der PRTG-Komponenten:

  • Der Core
    Das Herz des PRTG-Systems ist der zentrale Management Service, welcher die eigene proprietäre Datenbank betreibt, die Konfiguration vorhält und den Zugang für die Verwaltung bereit stellt. Der Core selbst überwacht aber nicht selbst, sondern überlässt dies den Probes. Zudem versendet der PRTG Core Alarme per SMTP, SYSLOG, SNMP, Skript etc. versendet.

  • Probe
    Per Default wird auf dem Server, der den Core betreibt auch immer eine Probe mit installiert. Damit ist dieser einzelne Server schon komplett funktionstüchtig und kann sich selbst aber auch andere Server mit überwachen. Das ist die kleinste Installationsart von PRTG

  • Überwachte Systeme
    Die Probe selbst führt dann Sensoren gegen sich oder andere Systeme im Netzwerk aus. Die einfachste Abfrage erfolgt per SNMP aber auch WBEM, WMI ist ebenso möglich wie Portprüfungen, NetFlow/SFlow, eigene Skripte, SSH, und viele andere Dinge.

  • Client Zugriff
    Nutzer von PRTG können auf vielfältige Weise auf die Plattform zugreifen. Es gibt den leistungsfähigen Zugang per Browser, einen reduzierten Zugriff per Mobile Browser, eine Windows GUI und die verschiedenen Apps für IOS; Android, Windows Phone. Die Windows Enterprise Console kann sogar mehrere Core-System zeitgleich verwalten.

  • Remote Probe
    Wenn das Netzwerk größer ist, kann eine einzelne Probe vielleicht nicht mehr alles überwachen. (-> Performance). PRTG kann aber auch entfernte Netzwerke überwachen, die nicht komplett erreichbar sind. Eine Remote Probe vor Ort führt die dortigen Tests aus und meldet die Ergebnisse über einen Port an den Core zurück. Wenn die WAN-Verbindung unterbrochen ist, puffert die Probe die Ergebnisse (bis zu 500.000) und liefert diese nach der Wiederherstellung der Verbindung an den Core. Eine Remote Probe ist also ideal für verteilte Netzwerke oder zur Überwachung von Kundennetzwerken als Service.

Wichtiger Hinweis: Eine Probe gehorcht immer nur einem Core, d.h. wenn Sie eine Probe beim Kunden vor Ort installieren und dieser auch PRTG einsetzen will, dann müssen dies getrennte Probe-Server sein. Auch ist es nicht möglich eine Core-Installation als Slave einer anderen Installation zu betreiben. Man kann aber eine PRTG-Installation bei einem Kunden aber mit einem Custom Sensor abfragen (Siehe PRTG Kaskade)

  • HTTPPush-Sensoren
    Eine Sonderrolle nehmen eigene Skripte und Lösungen ein, die nicht direkt von PRTG kontrolliert werden. PRTG hat seit einiger Zeit die Möglichkeit, dass per HTTP/HTTPS eigene Lösungen ihre Werte zu PRTG aktiv senden. PRTG speichert diese Ergebnisse und erlaubt ihnen diese zu visualisieren und Alarme zu generieren.. Siehe auch PRTG - HTTP Push-Sensoren

  • Sensoren
    Die "Sensoren" sind die Programme und Skripte, die sich mit einem Gerät verbinden und letztlich einen oder mehrere numerische Werte als "Channel" zurück geben. Die werden von der Probe auf dem Probe-Device selbst gestartet und ausgewertet.
    Wer also eigene Skripte entwickelt, muss dafür sorgen, dass diese auf der Probe auch vorliefen. Einen "Updatemechanismus" um Skripte von einem Repository auf dem Core zu allen Probes zu replizieren, gibt es leider (noch) nicht. Die Sensoren sind aber der Trumpf von PRTG, da es zum einen sehr viele vordefinierte Sensoren gibt und über die Funktion Custom Sensor quasi jedes System angesprochen werden kann. Selbst einen "Factory Sensor" gibt es, mit dem man Werte verschiedener Sensoren zusammenfassen kann.
  • Verfügbarkeit
    Die Probe selbst kann bis zu 500.000 Werte puffern, wenn der Core nicht erreichbar ist. Aber ohne Core wären sie Blind. Daher können Sie in PRTG bis zu 4 Server als "Cluster" verschalten, die alle die gleiche Konfiguration gemeinsam nutzen. Ein Server ist dabei der Master, auf dem auch KonfigurationsÄnderungen durchgeführt werden können, während alle anderen zwar aktiv überwachen aber nur bei einem Ausfall des Masters aktiv werden.

Das große Bild

Wenn dann alle Komponenten zusammen gesetzt werden, dann ergibt sich etwa folgendes umfangreiches Bild für eine einzelne Installation aus einem Core (optional als Cluster) mit einer Remote-Probe:

Die Größe einer PRTG Installation ist einmal durch die gekaufte Lizenz beschränkt, die sich auf die Anzahl der Sensoren bezieht. Aber viel wichtiger sind die zu erwartenden Sensoren und deren Einfluss auf die Systemleistung. Eine einfache SNMP-Abfrage oder ein TCP-Port-Test ist deutlich sparsamer als eine WMI-Abfrage oder gar umfangreiche Skripte, die z.B. eine Remote PowerShell starten. Aber diese Last kann auf mehrere Proben verteilt werden. Sie sollten aber nicht nun jeden Server mit einer Probe ausstatten, damit die Checks alle jeweils lokal ablaufen. Lizenzrechtlich ist das problemlos und viele Sensoren könnten als "LocalSystem" arbeiten um Dienstkonten zu sparen aber viele Proben müssen auch aktualisiert werden und stehen in der Hierarchie ganz oben. Zur Hierarchie kommen wir im folgenden Kapitel.

PRTG Hierarchie

Wenn das Basissystem einmal steht, müssen Sie ausgehend von der Wurzel nur noch die Probes installieren, darunter ggfls. in Gruppen die Devices mit den gewünschten Sensoren anlegen. PRTG organisiert alle Objekte in dieser Hierarchie. Hier ein unverfänglicher Auszug einer PRTG-Installation

Unter der Root befindet sich die Probe "NAWPRTG", die als erstes Device erst mal sich selbst mit überwacht. Dann wurde eine Gruppe "NAW Netzwerk" angelegt, unter der drei Switches als Device angelegt sind. hier wird als Sensor genau ein Port (der Uplink) überwacht.

Das bedeutet aber nicht, dass sie nicht doch noch über eigene Ansichten, Maps, Filter sich einen produktspezifische oder persönliche Ansicht erstellen können. Die komplette Liste aller Probes, Gruppen, Devices und Sensoren sieht in der Regel nur der "Administrator" und es ist dessen Aufgabe, entsprechende Ansichten für die Fachabteilungen anzulegen. Das erfolgt aber meist nur bei größeren Firmen bei denen es verteilte Zuständigkeiten gibt.

PRTG - Monitoring verteilter Standorte
http://www.de.paessler.com/support/videos/prtg-basics/distributed_monitoring

Weitere Links