IT-ADMINISTRATOR.DE 08/2008. Im Test: Paessler PRTG7 Network Monitor. Verfügbarkeit von der Kür zur Pflicht. Sonderdruck für Paessler

Transkript

1 IT-ADMINISTRATOR.DE 08/2008 Im Test: Paessler PRTG7 Network Monitor Verfügbarkeit von der Kür zur Pflicht Sonderdruck für Paessler

2 Im Test: Paessler PRTG7 Network Monitor Verfügbarkeit von der Kür zur Pflicht von Sandro Lucifora Server und Netzwerkgeräte sind in großen Konzernen wie auch in kleinen Unternehmen zentrale Einheiten mit unternehmenskritischen Aufgaben. Um den Ausfall eines Geräts, einer Verbindung oder eines Serverdienstes zeitnah zu erkennen, ist der Einsatz einer Monitoring-Software unerlässlich. Mit PRTG7 liefert Paessler die aktuellste Version seiner Überwachungssoftware aus. Ob der Nachfolger von IPCheck 5 auch wirklich jeden Ausfall zuverlässig erkennt, hat IT-Administrator im Praxistest herausgefunden. eit Juni steht das Release der neuesten Version 7 mit dem Namen S PRTG 7 Network Monitor zur Verfügung. Dabei handelt es sich um eine Produktzusammenführung und Weiterentwicklung der Monitoring-Software IP- Check 5 und PRTG Traffic Grapher, einer Software zur Überwachung von Bandbreiten auf Basis von SNMP-Daten. Da die neue Version bei Erscheinen dieses Tests vom Hersteller bereits ausgeliefert werden soll, beziehen wir uns im Bericht bereits auf die aktuelle Version. Die Aufgabe von PRTG7 ist es, in einem konfigurierten Umfang jegliche Art von Netzwerkgeräten auf Erreichbarkeit und, je nach Dienst, auch auf Funktion zu überprüfen. Im Laufe der Testzeit hat sich bei uns das Kontingent an zu überwachenden Geräten und Serverdiensten stetig erweitert. Im Testzeitraum ließen wir in der Spitze acht Geräte mit insgesamt 126 unterschiedlichen Sensoren überwachen. Installation erlaubt Übernahme von Altdaten Die Installation der Software erfolgte im Labor auf einem Windows 2003 Server SP2, der als Member-Server in einer Domäne konfiguriert war. Das Setup verlief unkompliziert und führte uns problemlos zum Installationsziel. Laut Hersteller kann PRTG7 auch auf einem Windows- XP- oder Vista-Rechner betrieben werden. Linux steht als unterstützte Plattform nicht zur Verfügung. Nach dem Setup beginnt PRTG7 ohne Neustart mit der Arbeit. Automatisch scannt die Software im Installationsprozess den eigenen Server und richtet vorsorglich alle erkannten Dienste zur Überwachung ein.wer bisher IPCheck 5 Bild 1: Die Basiskonfiguration erfolgt über das Server Administator Tool eingesetzt hat, kann nach dem ersten Login die Daten aus der alten Datenbank übernehmen und spart sich so einige Teile der Neukonfiguration. Um das manuelle Nacharbeiten aller Sensoren kommt der Administrator jedoch nicht herum. Bei einer Erstinstallation steht dem Administrator hingegen ein kleiner Konfigurationsmarathon bevor das liegt aber in der Natur der umfangreichen Möglichkeiten. Bevor PRTG7 über das Netz 2 August

3 Bild 2: Die Automatic Device Identification erkennt automatisch die Sensoren und richtet sie ein erreichbar ist, bedarf es zunächst der Grundkonfiguration am Server. Die tägliche Bedienung erfolgt später mit dem Frontend über einen Internetbrowser. Im Server Administrator -Tool richteten wir den PRTG-eigenen Webserver ein. Da auf unserem Windows-Server bereits der IIS an Port 80 und 443 betrieben wird, legten wir für den Webzugriff auf PRTG einen anderen Port, in unserem Fall 8080, fest.wahlweise können Sie hier auch mehrere Ports angeben. Über die Maske spezifische IP binden Sie einzelne IPs separat an den PRTG-Webserver das wird notwendig, wenn der Server mit mehreren IPs eingerichtet ist, aber PRTG nicht auf allen erreichbar sein soll. Neben dem Administrator-Login und der Lizenz müssen Sie hier nichts weiter einstellen. Automatische Geräteerkennung erleichtert die Konfiguration Jede weitere Konfiguration erfolgt über den Webbrowser. Paessler unterstützt hier den Internet Explorer 7 und Firefox 2 unter Windows. Im Test haben wir auch mit Firefox 3 gearbeitet und konnten keine Fehlfunktionen feststellen. Mit Safari 3.1 Windows und MAC war die Nutzung jedoch nur eingeschränkt möglich.wir haben zwar die Sensorzustände eingesehen, doch die Konfiguration wollte an einigen Stellen nicht gelingen. Wir starteten das Setup mit den User Accounts und legten die Zugänge einzelner User und ihre Berechtigung sofern notwendig fest. Über Schedules, also die Kalender, definierten wir Zeiträume in Form von Stunden und Tagen. Die Software ordnet diesen Zeitfenstern später Sensoren zu, um so die Prüfzeiträume festzulegen. Das macht Sinn, um zum Beispiel in einem Schedule die Zeiten auszuklammern, zu denen ein Gerät regelmäßig gewartet wird und zu denen keine Fehler gemeldet werden sollen. PRTG7 kann im Fehlerfall User auf unterschiedliche Weise benachrichtigen. Dazu werden bei Notification zu Anfang die Absender und die mögliche Nachrichtenform für die verschiedenen Benachrichtigungstypen hinterlegt (siehe Kasten 2: Benachrichtigungstypen in PRTG ). Obwohl schon vielfältige Benachrichtigungen auch über Messenger möglich sind, haben wir Skype in der Auswahl vermisst. Darauf gehen wir später noch etwas genauer ein. Nach dem Setup richten die IT-Verantwortlichen die Geräte und Sensoren ein. Dazu legen sie Gerätegruppen an, denen sie die zu überwachenden Geräte zur besseren Übersicht und Klassifizierung zuordnen. Des Weiteren lassen sich in PRTG7 für eine ganze Gruppe Einstellungen vornehmen, die sich abwärts, auf Geräte bis hin zu Sensoren, vererben. In unserem Fall haben wir einer Gerätegruppe einen Zeitplan zugeordnet, der später für jedes in der Gruppe konfigurierte Gerät und jeden Sensor galt. Es ist aber auch möglich, einzelne Geräte und Sensoren separat individuell anzupassen. In unserem Test waren Geräte in die Gruppe des internen und externen Netzwerks unterteilt. Sie kön- PING Sendet Standard-Ping PORT Überprüft, ob der Server eine Verbindung zur angegeben Portnummer akzeptiert. HTTP Einfache HTTP/HTTPS-Anfrage HTTP Advanced Advanced HTTP Sensor (Content-Check, Proxy-, und Authentifizierungseinstellungen) HTTP Transaction Überprüft mehrere Seiten in Folge (zum Beispiel Warenkorb) DNS Überprüft DNS-Server SMTP Überprüft SMTP-Mailserver POP3 Überprüft POP3-Mailserver FTP Überprüft FTP-Dateiserver SNMP Liest beliebige SNMP-Werte (OIDs) eines Geräts SNMP Traffic Überwacht den Bandbreitenbedarf von Servern, Routern, Switches et cetera via SNMP. FILE Überwacht eine Datei auf einer lokalen Festplatte oder einem Netzlaufwerk. Hierbei wird überpüft, ob die Datei existiert, ob die Größe in einer vorgegebenen Bandbreite liegt oder ob die Datei verändert worden ist. NT Service Sensor Jeder NT-Service des lokalen Rechners oder eines Computers in einem Netzwerk kann auf Verfügbarkeit überwacht werden. Bei einem Ausfall kann der Service auch neu gestartet werden. DISKSPACE Überwacht den freien Speicherplatz auf einem lokalen Laufwerk oder einem Netzlaufwerk. SQL Überwachung von MS SQL, Oracle SQL und MySQL Datenbankservern CUSTOM Kundenspezifische Sensoren (etwa Skripte et cetera mit diesem Sensor können Sie Ihre eigenen Sensoren erstellen) Kasten 1: Verfügbare Sensorentypen August

4 Sehr hilfreich ist der Dependency Type die Festlegung von Abhängigkeiten. Grundsätzlich ist es so, dass PRTG7 für jeden erkannten Fehler oder eine Warnung eine Fehlermeldung versendet. Sie haben zum Beispiel für ein Gerät 20 Sensoren konfiguriert, die bei einem Fehler jeweils eine SMS senden: In kleinen oder großen Rechenzentren werden oft mehrere Switche eingesetzt. Nun fällt der Switch aus, an dem das Gerät angeschlossen ist. Dieser Switch wird natürlich auch mit PRTG7 überwacht. Die Monitoring-Software stellt nun fest, dass der Switch ausgefallen ist und erkennt zudem weitere Fehler, weil das angeschlossene Gerät nicht mehr zu erreichen ist. In diesem Fall werden 21 Fehlermeldungen versendet, obwohl nur ein Gerät wirklich ausgefallen ist. Bild 3: Vorsicht: Wenn sich ein Überwachungswert ungewöhnlich verändert, zeigt PRTG7 das schon als Warnung an nen so aber auch Filialen, Stockwerke oder Kunden gruppieren. Im nächsten Schritt richteten wir die eigentliche Überwachung ein; wir konfigurierten zunächst die Geräte, dann die Sensoren. Ein Sensor ist die eigentliche Überwachungsfunktion. Er prüft auf das Eintreten eines zuvor definierten Ereignisses und reagiert entsprechend der Konfiguration. Um nicht jeden Sensor einzeln einrichten zu müssen, bietet PRTG7 neu die Automatic Device Identification (ADI). Diese Funktion scannt das zu überwachende Gerät, erkennt die möglichen Sensoren und richtet sie automatisch ein. Obwohl die ADI nicht jeden Dienst zur Überwachung erkannte, ist die Scan-Funktion eine enorme Erleichterung bei der Grundüberwachung von Geräten.Wahlweise kann ADI auch so konfiguriert werden, dass PRTG7 in einem definierten Turnus automatisch nach neuen überwachungswürdigen Standard- Diensten auf dem Gerät scannt und sie der Überwachung hinzufügt. Der Wermutstropfen: Die ADI funktioniert vollends nur auf einem Windows- Gerät. Serverseitige Dienste auf Linux- Servern werden darüber nicht erkannt. In diesem Fall scannt PRTG7 übliche Ports wie HTTP, POP3, FTP et cetera und kann so rudimentär die Verfügbarkeit von Diensten erkennen. Ausgewogenes Monitoring einrichten Nach dem automatischen Vor-Einrichten mittels ADI folgt das Feintuning. Hierbei haben wir Sensoren aus der automatisch erkannten Überwachung teilweise entfernt und spezielle Dienste des Servers mittels WMI-Sensoren und Diensteüberwachung hinzugefügt. Wichtig ist, dass nicht jeder mögliche Sensor verwendet wird. Jede Prüfung verursacht Bandbreite und CPU-Last, vor allem auf dem überwachten Gerät. Eine Ausgewogenheit zwischen Sensoren und Prüfintervall ist wichtig. Um diese zu erreichen, haben wir neben dem Prüfintervall auch verschiedene Sensorabhängigkeiten gesetzt. So ist es ausreichend, den verfügbaren Festplattenplatz alle 60 Minuten oder zwei Stunden zu prüfen, der CPU-Sensor muss jedoch minütlich nach dem Rechten schauen. Um der Flut an falschen Meldungen vorzubeugen, setzen wir den Sensor, oder wahlweise das Gerät, in Abhängigkeit zum Sensor des Switch. Meldet nun der Switch einen Fehler, gehen die in Abhängigkeit gestellten Sensoren auf Pause und es wird nur eine Eskalationsmeldung versendet die für den Switch. Applikationsserver gezielt überwachen Die Sensoren PING, PORT und HTTP liefern Ihnen Erkenntnisse über die Erreichbarkeit eines Geräts auf der Basis der entsprechend benannten Technologie. Ist aber der PING-Request wie an unserem Router abgeschaltet, kann dieser Sensor nicht mehr helfen. Um dennoch die Erreichbarkeit des Geräts zu prüfen, nutzten wir den erweiterten HTTP Transaction- Sensor. Dieser prüft nicht nur den HTTP-Request, sondern ist auch in der Lage, URL-Sequenzen wie bei Logins und Shoppingcards abzuarbeiten und das Ergebnis auszuwerten. Wir bedienen damit Sensoren können in Abhängig zu den Fehlerereignissen anderer Sensoren gesetzt werden. Ist ein Gerät einmal komplett nicht erreichbar, werden für jeden Dienst auf dem Gerät, der dadurch Fehler meldet, entsprechende Nachrichten versendet. Um nicht jeden Dienst in Abhängigkeit eines anderen erreichbaren Dienstes konfigurieren zu müssen, sollten Sie die komplette Gruppe in Abhängigkeit etwa eines PING-Sensors setzen. Dieser PING-Sensor muss dazu jedoch außerhalb der Gruppe konfiguriert sein. Sind in einer Gruppe 30 Sensoren konfiguriert und ist die Gruppe in Abhängigkeit der Erreichbarkeit des Geräts eingestellt, pausieren alle Sensoren und senden damit keine Fehlermeldung, wenn das Gerät selber nicht erreichbar ist zum Beispiel durch einen einfachen Ping oder wenn ein Switch ausfällt. Tipp: Abhängigkeiten definieren 4 August

5 die kennwortgeschützte HTTP-Seite des Routers so, dass der Login mit den zuvor hinterlegten Werten simuliert wird. Ist das erfolgreich abgearbeitet, weiß der Sensor, dass der Router aktiv ist. Auch bei den Mailservern wir überwachten im Test einen Linux-Mailserver,Tobit David!zehn und Exchange Server 2003 reichte uns nicht nur das ja/nein der Erreichbarkeit. Über das SMTP-Protokoll simuliert PRTG7 das Versenden einer . Ob der POP3- Server auch wirklich funktioniert, erfährt der Prüfling, indem ein POP3- Konto abgerufen wird; dasselbe gilt für IMAP. Für den Dienst des Exchange Servers 2003 nutzt PRTG7 den speziellen WMI-Sensor. PRTG kann Anwender auf verschiedene Arten benachrichtigen. Dies sind: - - Network-Broadcast - ICQ-Message - MSN-Message - Yahoo-Message - AIM-Message - SMS/Pager-Message - Ausführen einer HTTP-Aktion - Ausführen eines Programms - Abspielen eines Tons Kasten 2: Benachrichtigungstypen in PRTG Eine weitere Spezialität ist die Überwachung der Erreichbarkeit einer SQL- Datenbank.Wir haben im Test feststellen lassen, ob ein MS-SQL- und ein MySQL-Datenbankdienst nicht nur ihre Arbeit verrichten, sondern auch, ob und welche RESULTS eine definierte SQL-Abfrage liefert. Mit diesem Sensor lässt sich so zum Beispiel auch der Inhalt einer Tabelle abfragen und darauf reagieren. So kann man auch herausfinden, ob zu viele oder zu wenige Einträge vorhanden sind. Neben den dienstspezifischen Angaben hat der Administrator noch einige weitere Möglichkeiten der Feineinstellung. Außer den Basic-Angaben und der Priorität kann zum Beispiel für Windows- Dienste festgelegt werden, dass PRTG7 versucht, diesen wieder zu starten, wenn er ausgefallen ist. Das Prüfintervall kann wahlweise zwischen einer Sekunde und einem Tag liegen. Der bereits angesprochene Kalender (Schedule) legt fest, zu welcher Zeit der Sensor auf Fehler prüfen soll. Die Liste von Mehr als nur da oder nicht da-sensoren hat sich gegenüber der Vorgängerversion enorm erweitert. PRTG7 verfügt mittlerweile über 37 spezifizierte Sensoren. Darunter, wie schon angesprochen,wmi-sensoren und solche, die auf der Basis von SNMP Daten auswerten. Ein weiteres Schmankerl ist der NetFlow- Sensor für Cisco-Switches. Benachrichtigung Tritt der Fall ein, dass ein Prüfsensor eine Unregelmäßigkeit bemerkt, greift die zuvor eingerichtete Eskalationskette.Wie häufig bei PRTG7 ist auch hier die Feineinstellung sehr wichtig. Die Einstellungen für die Benachrichtigungen lassen sich in der Hierarchie von der Gruppe über das Gerät bis zum Sensor vererben. Oft ist es sinnvoll, einige Einstellungen zumindest gruppenweise zu vereinheitlichen. Über die Konfiguration Notification legen IT-Verantwortliche fest, welche Notification-Group bei den Statusänderungen Warning, Down oder Unusual nach welcher (Ausfall-)Zeit benachrichtigt wird. Da andere Sensortypen auch Zeiten oder Volumen messen, werden jeweils spezifizierte Einstellungen vorgenommen. Die Notification-Group kann mehrere Benachrichtigungstypen wie in unserem Test , ICQ und MSN und Empfänger beinhalten. Um die Benachrichtigungen gezielt zu prüfen, haben wir im Test einzelne Dienste ein- und ausgeschaltet bzw. Fehlfunktionen simuliert. Bild 4: Der Zustand der Sensoren lässt sich in der Übersicht an verschiedenen Farben ablesen Überwachung verteilter Standorte Um ein Netzwerk an Überwachungen zu etablieren, ist es nicht notwendig, auf vielen Servern jeweils die Monitoring- Lösung zu betreiben. PRTG7 ist unterteilt in die Server-Applikation und die Probes, die Sonden. Ein Probe lässt sich unabhängig von PRTG auf einem Server August

6 installieren. Dieser dient dann als Lieferant für die Messergebnisse. Einen solchen Remote-Probe haben wir im Test auf einem Server in den USA installiert und damit wiederum die Zugriffszeit auf einen Webserver in den USA überwacht. Damit haben wir Engpässen über das Überseekabel vorgebeugt und konnten so realistische Zugriffszeit des USA-Servers aus den USA überwachen. Ein weiterer Einsatz für die Remote- Probes, die sich im Übrigen lizenzfrei unbegrenzt installieren lassen, ist der Packet- Sniffer-Sensor. Dieser benötigt einen Probe auf dem jeweiligen Gerät. Dann kann der Packet-Sniffer auch die Datenpakete des Geräts erfassen und auswerten zum Beispiel ungewöhnlich hohen Traffic melden. Fazit Während des Tests konnten wir absolut keine Ausfälle der Server-Überwachungssoftware feststellen. Dies gilt sowohl für IPCheck 5 als auch in der letzten vorliegenden Version von PRTG7. Nach einem mehrwöchigen Feintuning hat sich bei uns die Auslastung des Test- Systems mit Prüfungen pro Stunde eingependelt und ist vergleichsweise minimal.während der gesamten Testphase haben IPCheck und PRTG7 sowohl gezielt herbeigeführte Ausfälle als auch unvorhergesehene realistische Fehler im Betrieb von Geräten erkannt und gemäß den Regeln gemeldet. Lediglich das Konfigurieren der Benachrichtigung hat zu Anfang Nerven gekostet, bis die Abhängigkeiten so eingestellt wurden, dass wirklich nur noch dann und von dort Fehler gemeldet wurden, wo auch wirklich Fehler waren. Kettenreaktionen bei den Meldungen konnten wir nahezu ausschalten. Ein Makel in diesem guten Zeugnis: Obwohl Linux-basierte Geräte verbreitet Einsatz in Unternehmen finden und auch auf diesen wichtige Dienste wie Workgroup- Lösungen,Virenscanner, Web-, File- und Datenbankserver betrieben werden, ist PRTG7 keine Alternative, um auch dort Dienste zu prüfen. Lediglich einen auf Linux betriebenen MySQL-Dienst konnten wir über die SQL-Abfrage überwachen. Das Preismodell von Paessler macht PRTG7 auch für die kleinsten Netzwerke hochinteressant.trotz der komplexen Materie ist die Handhabung und die Einrichtung des Systems schnell zu lernen und durchzuführen. Dazu trägt nicht zuletzt die Automatic Device Identification bei. (jp) Produkt Software zur Überwachung von Rechnern und Netzwerkkomponenten. Hersteller Paessler GmbH Preis ab 195,00 EUR für 100 Sensoren; bis EUR für unlimitierte Sensoren und Installationen; Upgrade von IPCheck 5 mit 25 auf 100 Sensoren im Wartungsvertrag kostenlos; Freeware/Testversion mit 10 Sensoren. Technische Daten So urteilt IT-Administrator (max. 10 Punkte) Konfiguration Zeitinvestition bis zum ersten Einsatz Zuverlässigkeit Genauigkeit der Meldungen Umfang der Sensoren Dieses Produkt eignet sich optimal für die Überwachung komplexer Netzwerkstrukturen und Abhängigkeiten der Geräte untereinander. gut für Betriebe, die eine Verfügbarkeit Ihrer Netzwerkgeräte sichern müssen. Dabei spielt die Unternehmensgröße keine Rolle. nicht für Unternehmen, die keine Windows-Server einsetzen. PRTG7 Network Monitor August