Diesmal mal wieder ein Artikel etwas außerhalb der Microsoft Welt. Es gibt einen Ausflug in Monitoring und die Überwachung von Webservern unter Linux. Einige kennen das, nichts ist schlechter, als wenn die Webseite die man besuchen möchte nicht erreichbar ist. Dies ist bei mir 2 mal in 2 Tagen passiert ist. Der Webserver hats sic aufgehangen und ich habe den Fehler nicht finden können. Also musste was getan werden.
Ich habe mich an PRTG erinnert. Das schöne ist, die kostenlose Version kann 100 Sensoren, das reicht für ein paar Webseiten. Die weitere Sensoren kann ich dann für meine Umgebung zu Hause verwenden, da gibt es ja genug das man Überwachen kann. Zum Beispiel WLAN Access Points, die Firewall oder meine Windows Server.
PRTG Installieren
Da PRTG auf Windows basiert ist die Installation sehr einfach. Das Ganze ist selbsterklärend. PRTG€ bringt seinen eigenen Webserver mit, der auch auf SSL umgestellt werden kann. Dies ist für manche Funktionen erforderlich, aber sehr einfach. Mehr dazu im nächsten Kapitel.
Wer auf Nummer sicher gehen möchte, für Installation gibt es How-Tos und Videos bei dem PRTG Hersteller Paessler auf der Seite. Auch gibt es einen Umfangreiches How-To wie man große Webserver Umgebungen überwachen kann und bis in welche Tiefe hinunter. Das ist aber um festzustellen ob und wie schnell ihr diesen Artikel lesen könnt, etwas übertrieben. Trotzdem möchte ich euch den Link nicht vorenthalten.
Einrichten von PRTG
Ich habe PRTG bei mir auf HTTPS umgestellt. Wichtig dafür, dass man den PRTG Certificate Importer mit den installierten Computer Zertifikaten verwenden kann, ist das der Private Schlüssel exportierbar ist. Wenn das nicht möglich ist oder Ihr den privaten Schlüssel nicht noch in einer Datei liegen habt, dann müsst ihr ein anderes Zertifikat nehmen. Ich nutze intern Webserver Zertifikate die ich mit meiner Active Directory Zertifizierungsstelle ausstelle.
Da PRTG alles überwachen soll, ist ein geeigneter Server auszuwählen. Ich persönlich würde dafür einen eigenen aufzusetzen, da je nachdem welche und wie viele Sensoren man benutzt. Diese schonmal das System ziemlich beschäftigen können. Eine kleine Virtuelle Maschine ist dafür aber in den meisten Fällen ausreichend.
Wenn man entsprechende Zugangsdaten eingegeben hat, schaut PRTG erstmal was er findet und richtet alles ein. Da eine neue Installation mit einer 30 Tage Testversion startet, ist das auch kein Problem. Wichtig, er kann im Standard sehr viele Sensoren selber einrichten, so dass schonmal bei einem 24 Port Switch über 70 Sensoren zusammen kommen können. Oder an die 100 bei einem Hyper-V Server. Es lohnt sich also nach der Automatischen Erkennung bei den Systemen und den Sensoren aufzuräumen. Zum Beispiel brauche ich nicht jede Windows 10 Test VM im Monitoring, das 15 Geräte mit über 10 Sensoren, die ich mir sparen kann. Auch möchte ich auf meinen SSD keine IO-Performance überwachen, das benötige ich bei mir nicht. Das nötigste in meiner Umgebung sind aktuell 173 Sensoren. Da muss ich in 28 Tagen mal etwas aufräumen.
Da die Lizenzierung auf der Zahl der Sensoren beruht, muss man sich überlegen wie genau man es haben möchte. Wer sich PRTG€ mal anschauen möchte, kann gerne die Links in diesem Artikel verwenden. Ich bekomme dann bei einem Kauf eine kleine Provision, die mir hilft diese Seite zu betreiben.
Sensoren für Webserver
Es gibt verschiedene Arten von Sensoren, eine wichtige Unterscheidung ist die Authentifizierung und die Verbindungsart.
HTTP Sensoren
Bei den HTTP Sensoren gibt es verschiedene. Diese funktionieren ohne Authentifizierung, bei Passwortgeschützten Webseiten müssen die Zugangsdaten in die URL integriert werden oder ein Sensor mit passender Unterstützung gewählt werden.
Die aus meiner Sicht interessantesten Sensoren um Websiten überwachen sind:
HTTP
Einfacher Sensor der eine einzelne GET, POST oder HEAD Anfrage an eine URL sendet. Das ist ausreichend, um zu schauen ob der Webserver antwortet. Auch spart das Ressourcen, so dass dieser Test öfters ausgeführt werden kann, ohne den PRTG€ Server oder den Webserver zu stressen.
HTTP (Erweitert)
Dieser erweiterte Sensor unterstützt unter anderem Authentifizierung. Zusätzlich kann er aber noch weiteres zum Beispiel einen eigenen Header angeben, den User Agent auswählen oder bei Inhaltsänderungen Alarmieren. Der eigene Header kann helfen, wenn man gerne die Zugriffe des Monitorings nicht mit in der Statistik haben möchte.
Cloud HTTP
Ähnlich wie der einfachere HTTP Sensor, nur das die Zugriffe auf der Cloud erfolgen. Hier werden Systeme von Paessler genutzt die in Tokio, Ireland, Nord Virginia und Oregon stehen.
HTTP (Komplette Webseite)
Für mich aus Performance Sicht der wichtigste Sensor um die Webseiten zu überwachen ist der, der mir die Komplette Ladezeit überwacht. Da dieser Sensor aber deutliche mehr last verursacht, sollte der nicht mit den Standardwert von 60 Sekunden laufen. Ich persönlich verwende bei meinen Blogs 60 Minuten, mir geht es eher um schleichende Veränderungen oder Probleme nach Software Updates. Wichtige Blogs überwache ich alle 5-10 Minuten. Ich kombiniere diesen Sensor mit einen normalen HTTP Sensor, der die Erreichbarkeit des Dienstes prüft. Die Browser, die der Sensor verwenden kann ist Chromium, PhantomJS oder den Internet Explorer. Alle drei bieten verschiedene Option und nicht funktioniert. Hier ist also etwas testen angesagt.
HTTP (Inhalt)
Dieser Sensor liefert einem Numerischen Wert aus HTTP-Anfrage zurück. Beispiel, eine Software gibt ihren Status auf einen HTML-Request als „[37]“ zurück, dann liefert der Sensor den Wert 37.
SSL-Zertifikat
Prüft das Zertifikat einer Verbindung. So kann man überwachen das ein gültiges Zertifikat verwendet wird.
SSL Security Check
Dieser Sensor prüft die Sicherheit der SSL Verbindung. Hier wird unter anderem auf SSL3.0, TLS 1.0, TLS1.1 und TLS 1.2 getestet.
SSH Sensoren
Wichtig ist jedoch nicht nur die Webseiten überwachen, sondern auch den ganzen Web Server. Wenn dieser Probleme hat, wird es auch die Webseite betreffen.
SSH Sensoren setzen Authentifizierung voraus. Diese kann über Benutzername und Kennwort oder mit SSH-Keys funktionieren. Wer das mit den SSH testen möchte, kann dafür Putty benutzen. Alternativ kann bei Windows 10 auch der SSH Client benutzt werden.
SSH Speicherinfo
Dieser Sensor überwacht den Speicherverbrauch eines Systems.
SSH Laufwerkskapazität
Auch wichtig ist die Laufwerkskapazität der einzelnen oder ausgewählten Mount Points. Wenn der Datenbankserver oder der Webseiten Cache keinen platz haben, kommt es auch zu Ausfällen.
SSH Durchschnittl. Last
Ähnlich ist es mit der Auslastung, der Sensor überwacht die durchschnittliche Last auf dem System.
SSH-Skript und SSH-Skript (Erweitert)
Diese Sensoren führen ein Skript auf dem System über SSH aus. Das Skript, das ausgeführt wird, muss einen numerischen Wert oder beim erweiterten Sensor einen XML oder JSON Ergebnis zurückgeben. Somit kann im Prinzip fast alles ausgelesen werden.
Weitere Sinnvolle Sensoren
Wenn der Server wie so oft kein reiner Webserver ist, sondern auch Mail, DNS und Datenbank Server ist, gibt es noch ein paar weitere Sensoren die Sinnvoll sein könnten. Zum Beispiel:
- IMAP: Überwacht einen IMAP Mail-Server
- POP3: Überwacht einen POP3 Mail-Server
- SMTP: Überwacht einen SMTP Mail-Server
- SMTP&IMAP-Übermittelung: Dieser Sensor überwacht den Round Trip, also das Senden über SMTP und empfangen über IMAP
- SMTP&POP3-Übermittelung: Dieser Sensor überwacht den Round Trip, also das Senden über SMTP und empfangen über POP3
- DNS: Dieser Sensor überwacht den DNS-Server auf einem System
- IP auf Schwarzer Liste des DNS: Dieser Sensor überwacht ob eine IP auf einer der Schwarzen Listen (z.B: SpamCop) steht. Dies kann zum Beispiel durch Spammen passieren, oder durch gehackte Webseiten, die missbraucht werden.
- SFTP Secure File Transfer Protocol: Dieser Sensor überwacht die Erreichbarkeit des SFTP, also FTP mit SSL, Server. Dies sollte statt FTP genutzt werden, damit die Zugangsdaten nicht im Klartext übermittelt werden. Ich bevorzuge aber SCP, eine Datenverbindung durch einen SSH-Tunnel.
Weitere Möglichkeiten wären noch Webbasierte Verwaltungskonsolen, hierfür können die HTTP Sensoren verwendet werden. Für Datenbanken wird das etwas schwerer, da diese aus Sicherheitsgründen meistens nur lokal erreichbar sind. Die Lösung ist hier ein Skript, das über SSH ausgeführt wird und entsprechende Werte zurückliefert.
Fazit
Dies Lösung ist interessant für Blogger die ihre Webseiten überwachen möchten. Aber auch für Agenturen, die Vielleicht in Performance Reporting oder SLA mit ihren Kunden oder Hostern vereinbaren möchten.
Wer es gerne Übersichtlich mag, kann sich seine eigene Monitoring Übersicht anpassen, diese Funktions wird als „Maps“ bezeichnet. Maps können ganz individuell gestaltet werden und auch öffentlich, ohne Anmeldung am PRTG zur Verfügung gestellt werden. Natürlich nur wenn man das möchte.
Hier mal mein persönliches 5 minuten Beispiel. Nicht schön, aber alles drauf was mich interessiert.
Schreibe einen Kommentar