Im Test: Monitoring-Lösung PRTG 20.1.55.1775
Neben der von uns getesteten On-Premise-Variante von PRTG steht übrigens unter https://my-prtg.com noch eine Cloud-Version der Software zur Verfügung. Darüber hinaus bietet Paessler mit “PRTG PLUS” noch eine spezielle Lösung für große Umgebungen an. Eine Cluster-Failover-Funktion zum Realisieren von Hochverfügbarkeits-Szenarios gehört ohne Aufpreis zum Leistungsumfang der Software.
Was die Systemanforderungen für die On-Premise-Variante angeht, so empfiehlt Paessler, die Software auf Systemen zu installieren, die unter Windows 10 oder Windows Server 2012 R2 und neuer laufen. Bei Windows 10 sollte es sich um die 64-Bit-Variante handeln und das .Net-Framework 4.7.2 sollte außerdem auf den betroffenen Rechnern installiert sein. Im Test übersahen wir diesen Punkt und spielten die Lösung auf einer Virtuellen Maschine unter ESXi 6.7 Update 3 ein, die unter Windows Server 2016 lief und auf der kein .Net-Framework 4.7.2 vorhanden war. Daraufhin meldeten diverse Sensoren nach dem Einrichten, dass sie auf das .NET-Framework 4.7.2 angewiesen seien. Das verwirrte uns zunächst, da wir annahmen, damit sei ein .NET-Framework auf den zu überwachenden Clients gemeint. Erst eine Recherche im Internet brachte uns darauf, dass das Framework auf dem PRTG-Server selbst vorhanden sein musste. Hier könnte Paessler die Fehlermeldung etwas klarer formulieren. Nachdem wir auf unserem Testsystem die entsprechende Variante des .Net-Frameworks installiert hatten, funktionierte aber alles wie erwartet.
PRTG lässt sich übrigens modular im Netz verteilen, damit die Last nicht auf ein einzelnes System beschränkt bleibt. Dazu kommen so genannte Remote Probes zum Einsatz, die auf entfernten Rechnern laufen, dort die Daten der dazugehörigen Sensoren sammeln und diese dann an den zentralen PRTG-Server schicken. Die Einrichtung solcher Remote Probes ergibt vor allem in großen und verteilten Netzwerkumgebungen Sinn. In unserem Testnetz kamen wir nach der PRTG-Konfiguration auf knapp unter 800 Sensoren, so dass ein zentrales Monitoring-System ausreichte.
Was die Hardware-Anforderungen angeht, so empfiehlt Paessler für Installationen mit bis zu 1000 Sensoren zwei CPU-Cores, drei GByte RAM und 250 GByte Festplattenplatz zur Verfügung zu stellen. Bei 1000 bis 2500 Sensoren sind es drei Cores und fünf GByte RAM sowie 500 GByte Festplattenplatz, bei 2500 bis 5000 Sensoren fünf Cores und acht GByte RAM bei einem TByte HDD-Speicher. Bei bis zu 10.000 Sensoren sollten die Administratoren schließlich acht CPU-Cores, 16 GByte RAM und zwei TByte Festplattenplatz vorhalten. Bei so großen Umgebungen empfiehlt der Hersteller zudem, PRTG nicht in einer virtuellen Umgebung laufen zu lassen, sondern auf einer dedizierten Hardware.
In unserer Testinstallation verfügte die verwendete VM über vier CPU-Kerne (Intel i5-Prozessoren mit 3,2 GHz Taktfrequenz), acht GByte RAM und 300 GByte Festplattenplatz. Dabei traten keinerlei Probleme auf.
Die eigentliche Installation des Produkts läuft verhältnismäßig einfach ab. Es reicht, die Setup-Datei aufzurufen, die Lizenz zu bestätigen und eine E-Mail-Adresse anzugeben, an die das System Alerts schicken soll, danach läuft das Setup durch und die Arbeit kann beginnen.
Ein Wizard hilft bei der Erstkonfiguration
Nach dem Abschluss der Installation landet der Benutzer direkt im Standardbrowser des Systems, der versucht, auf das Management-Interface von PRTG zuzugreifen. Das führt leider auf Server-Systemen, auf denen der Internet Explorer mit der verstärkten Sicherheitskonfiguration aktiv ist, zu diversen Fehlermeldungen. Anwender von Windows 10 haben dieses Problem nicht, Benutzer von Windows-Server-Systemen sollten besser einen anderen Standard-Browser einspielen. Es wäre schön, wenn Paessler im Rahmen des Setups auf dieses Problem hinweisen würde.
Nach der Anmeldung beim Konfigurations-Interface mit den Standard-Credentials „prtgadmin/prtgadmin“ macht das System die Nutzer zunächst einmal auf ein paar unbedingt zu erledigende Aufgaben aufmerksam. Dazu gehören das Ändern des Standard-Kennworts, das Aktivieren der SSL-Verschlüsselung für das Verwaltungswerkzeug und das Konfigurieren des E-Mail-Versands für die Alerts. Gleichzeitig läuft auch eine automatische Hintergrundsuche los, die die im Netz vorhandenen Geräte auffinden soll.
Im Test folgten wir der PRTG-Empfehlung und versuchten zunächst, ein neues Passwort für das prtgadmin-Konto einzurichten. Dabei setzten wir auf einen Chrome-Browser unter Windows 10 mit einer Display-Auflösung von 1920 mal 1080 Punkten. Von dieser Auflösung ließen wir am rechten Bildschirmrand etwa 250 Punkte für ein zweites Fenster frei, ansonsten füllte der Browser den ganzen Bildschirm aus. Nachdem wir unser neues Passwort eingegeben hatten, stellten wir fest, dass wir es nirgendwo speichern konnten. Erst später, nach mehreren Versuchen, kamen wir darauf, dass die Fenster mit den gerade erwähnten Hinweisen auf die zu erledigenden Aufgaben auf unserem Display den Speichern-Knopf für das neue Passwort überdeckten. Wenn man diese Fenster schließt, kann man das Passwort folglich direkt speichern, dabei sind aber auch die Links, die zu den nächsten Aufgaben führen, weg. Das Ganze ist folglich ein wenig unglücklich gelöst.
Im Anschluss wechselten wir in die Geräteübersicht, um zu sehen, welche Netzwerkkomponenten PRTG bereits gefunden hatte. Dadurch starteten wir einen Wizard, der mit Portraits diverser Paessler-Mitarbeiter gestaltet wurde, die uns durch die Erstkonfiguration der Lösung führen sollten.
Dieser Wizard verlangte zunächst einmal nach den Zugangsdaten zu den im Netz vorhandenen Windows-, Linux- und Vmware-Systemen sowie nach Informationen zu SMTP, Datenbanken, MQTT und ähnlichem, damit sich die Software bei den Netzwerkkomponenten authentifizieren und Informationen einholen konnte. Nachdem wir diese Angaben gemacht hatten, startete PRTG die Netzwerksuche neu. Es wäre sicher sinnvoll, die Suche nicht direkt nach der Installation automatisch zu starten, sondern damit zu warten, bis die Anwender die entsprechende Stelle des Wizards erreicht haben.
Im nächsten Schritt fragte der Assistent nach der lokalen Adresse, damit das System in die Lage versetzt wird, die gefundenen Netzwerkkomponenten korrekt im zur Geräteübersicht gehörenden Geo-Maps-Eintrag anzuzeigen. Zum Schluss leitete der Assistent uns nochmals dabei an, das Administrator-Passwort zu ändern und die E-Mail-Konfiguration für den Alert-Versand vorzunehmen. Diese Schritte sind eigentlich überflüssig, da wir sie schon aufgrund der Warneinblendungen zu Beginn auf dem Schirm hatten. Der Hersteller sollte folglich die Erstkonfiguration nochmals überarbeiten und glätten.
Einrichtung mit Video-Tutorials, kostenlosen Tools und einer umfangreichen Knowledge Base
Nach dem Abschluss der Einrichtung warteten wir erst einmal ab, bis der automatische Suchlauf für unser Netz abgeschlossen war. Danach nahmen wir uns die Geräteübersicht vor und sahen nach, ob das System wirklich alle Komponenten gefunden hatte. Das war bei uns der Fall. PRTG hatte zu diesem Zeitpunkt auch schon etliche Sensoren eingerichtet, die die Lösung für die gefundenen Geräte als sinnvoll erachtete. Einige funktionierten nicht, was mit der mangelhaften Konfiguration unserer Netzwerkkomponenten zusammenhing. Deswegen machten wir uns zunächst einmal daran, auf allen zu überwachenden Systemen die Dienste für SNMP, WinRM und WMI so zu konfigurieren, dass sie durch die Firewalls kommunizieren konnten und Daten bereitstellten. Damit verschwanden schon mal eine Vielzahl der Fehlermeldungen der Sensoren. In diesem Zusammenhang ist es positiv zu vermerken, dass sich in der Paessler-Knowledge-Base sehr viele Artikel finden, die genau beschreiben, wie die Konfiguration von SNMP, WMI und ähnlichem abläuft, so dass es bei der Arbeit kaum zu Problemen kommt.
Paessler stellt sogar eine Reihe kostenloser Tools zur Verfügung, mit denen sich die richtige Konfiguration der zu überwachenden Client-Systeme überprüfen lässt. Dabei handelt es sich unter anderem um NetFlow-, sFlow-, SNMP- und WMI-Tester, die nicht nur in Zusammenarbeit mit PRTG nützlich sind.
