Website-Monitoring: Downtime oder Performanceproblem?

In unserem Thema des Monats Juni stellen wir Möglichkeiten vor, mittels verschiedener SaaS-Anbieter (Software as a Service) Websites und Server auf ihre Erreichbarkeit hin zu überwachen.
Die dort getroffenen Aussagen sollen an dieser Stelle in keiner Weise widerrufen, vielmehr um einen wichtigen Hinweis ergänzt werden. Viele dieser Anbieter, beispielsweise das ausführlicher vorgestellte „UptimeRobot“, aber auch „Pingdom“, unterstützen ein Feature nicht, das mitunter von besonderer Bedeutung sein kann: Die Test-Intervalle lassen sich zwar je nach Anbieter und bezahltem Funktionsumfang individuell einrichten, etwa von fünfminütigem Erreichbarkeitstest in der kostenlosen UptimeRobot-Version bis hin zu minütlichen Versuchen in der kostenpflichtigen Variante. Was diese Anbieter allerdings nicht bieten, ist ein einstellbarer Threshold, also der Grenzwert, nach dessen Überschreiten ein Alarm ausgegeben wird. Das bedeutet, dass der voreingestellte Wert des Anbieters zwangsweise darüber entscheidet, wie lange eine Seite zum „Antworten“ benötigen darf, bevor sie als nicht erreichbar deklariert wird.
Liegt dieser Wert beispielsweise bei 20 Sekunden, wird ein Alarm ausgelöst, wenn die überwachte Seite nicht innerhalb dieses Zeitraums bis zu einem gewissen Teil geladen ist. Nun sind freilich Fälle denkbar, in denen ein deutlich niedriger oder aber auch ein höherer Wert gewünscht ist.

Timeout/Threshold: 6 Sek.

Für Betreiber von Websites, deren Angebot sich in erster Linie an Benutzer auf Mobilgeräten richtet oder aus diversen Gründen möglichst schnell geladen sein muss, könnte eine Ladezeit von knapp unter 20 Sekunden bereits als nicht hinnehmbar erscheinen – ohne dass sie hierüber vom Monitoring-Tool informiert werden würden. Eine effektive Überwachung würde in diesem Fall voraussetzen, bereits ab einer Ladezeit von mehr als 5 oder von mehr als 10 Sekunden informiert zu werden.
In anderen Szenarien geht es unter Umständen viel weniger um die effektive Ladezeit als darum, komplexe Inhalte, die vielleicht dynamisch aus verschiedenen Quellen bezogen und erstellt werden, vollständig und eventuell auch in der exakten Reihenfolge zu laden. Hier wäre im Beispiel denkbar, dass eine Ladezeit von bis zu 25 Sekunden unter der Last vieler Besucher zwar nicht ideal, aber durchaus hinnehmbar sein könnte. Dies würde vom Monitoring-Tool allerdings jedes mal mit einem Alarm quittiert, wenn die Ladezeit die fest eingestellten 20 Sekunden überschreitet.
Denkbar sind natürlich auch Szenarien, in denen etwa die Startseite oder eine Landingpage nicht mehr als 5 Sekunden benötigen darf, einer oder mehrerer Unterseiten, Webapps oder dergleichen aber eine Ladezeit von bis zu 15 Sekunden eingeräumt werden soll. Das würde die Einrichtung mehrerer Monitore sowie individueller Timeouts/Thresholds bedeuten.
Um dies beispielhaft aufzuzeigen:
Anhand dieser Messwerte wird schnell ersichtlich, wie sich verschiedene Timeout-Settings in den ausgegebenen Alerts niederschlagen. Wird der Timeout auf den Wert am unteren Rand des hier roten Bereichs gesetzt, wäre im betrachteten Zeitraum lediglich ein Alert ausgelöst worden. Ist hingegen der Wert auf den unteren Wert des orangenen Bereichs eingestellt, wären es bereits sechs Alerts gewesen, und eine weitere Herabsetzung des Timeouts (gelb) hätte eine siebte „Spitze“ zur Downtime deklariert.
Je nach Anwendungszweck kann es also vorkommen, dass zu wenige oder zu viele Alerts generiert werden, die – wie dieses Beispiel zeigt – nicht grundsätzlich „echte“ Downtimes der Seite oder des Servers bedeuten. Stattdessen können solche Werte ganz andere Ursachen haben, von der hohen Auslastung durch mehrere Nutzer gleichzeitig bis hin zu fehlerhafter, zumindest problematischer Website-Programmierung, Einbettung (zu) zahlreicher Scripts usw.
Deshalb darf nicht unerwähnt bleiben, dass Monitoring mittels HTTP(S)-Requests natürlich keine Performanceanalyse ganzer Website beziehungsweise derer genauen Ladezeiten (Full Page Load) liefert. Allerdings können individuell passend eingestellte Monitore auf Fälle hinweisen, in denen eine detaillierte Analyse der Site-Performance nötig wäre. Auf Debugging von Websites, Performanceanalysen und Fehlersuche und -bereinigung wollen wir aber an dieser Stelle nicht weiter eingehen – hierzu folgt demnächst ein ausführlicherer Artikel.
Stattdessen wollen wir abschliessend zumindest ein Tool nennen, das ergänzend zu den bereits vorgestellten Anbietern auch oben genannte Anforderung erfüllt, also Website-Monitoring mit individuell einstellbarem Timeout/Threshold ermöglicht. Nodeping.com liegt mit mindestens $ 8/Monat preislich im Rahmen der anderen Anbieter, allerdings ergänzte um die für jeden Monitor separat konfigurierbaren Timeouts. Eine dauerhaft kostenlose Variante wird hier nicht geboten, stattdessen kann für zwei Wochen die günstigste Bezahlvariante kostenfrei und in vollem Umfang getestet werden.
Eine weitere Möglichkeit, neben Servern auch einzelne Websites, Onlinedienste et cetera auf ihre Verfügbarkeit hin zu überwachen und dabei möglichst zahlreiche Parameter beachten und konfigurieren zu können, stellen Lösungen wie etwa die Nutzung von Nagios dar. Ob sich dessen Einsatz allerdings lohnt, „nur“ um die Verfügbarkeit der eigenen Website im Auge zu behalten, lässt sich natürlich nicht pauschal beantworten und kommt immer auf die Rahmenbedingungen an.
Wünschen Sie zusätzliche Informationen oder wollen uns über weitere Möglichkeiten zum Website-Monitoring in Kenntnis setzen? Zögern Sie nicht, Kontakt mit uns aufzunehmen!

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.