Zabbix Webseiten ueberwachen

Webszenario

Zabbix bietet mit den sogenannten Webszenarios umfangreiche Möglichkeiten, die Verfügbarkeit und Geschwindigkeit von Webseiten zu messen. Dabei sind die Tests nicht auf das Aufrufen einzelner URLs beschränkt. Das Einloggen in geschützte Bereiche und das Akzeptieren von Cookies ist ebenso möglich wie das Abrufen von Anmelde- oder Bestellvorgängen über mehrere Seiten und Formulare hinweg.

Der Zabbix-Server verwendet zum Aufrufen von Webseiten libcurl. Während des Kompilierens des Zabbix-Servers oder Proxys müssen Sie die Option --with-libcurl angeben, sonst können Sie die Webszenarios nicht nutzen.

Die Webszenarios sind für viele Anforderungen ausreichend. Sie können testen, ob ein Webserver den richtigen Inhalt ausliefert, und Sie können messen, wie schnell dies geschieht. Die Messungen von Zabbix sind aber mit Vorsicht zu genießen. Zabbix lädt beim Aufrufen einer URL keine verknüpften Elemente wie Bilder, JavasSript oder CSS nach. Die gemessenen Downloadzeiten geben also nicht wieder, was ein Kunde erlebt, wenn dieser Ihre Webseite besucht. Der in einer Webseite enthaltene JavaScript-Code wird nicht ausgeführt. Gegebenenfalls asynchron nachladende Elemente können weder auf ihren Inhalt geprüft werden noch werden diese in der Messung der Geschwindigkeit berücksichtigt.
Zabbix fragt einen Webserver mit einem vorgefertigten HTTP-Request ab. Dabei wird nicht geprüft, ob ein entsprechender Request überhaupt zustande kommen könnte. Während Sie mit Zabbix zum Beispiel den HTTP-Post-Request eines Anmeldeformulars simulieren, kann einem Webentwickler ein Fehler im HTML-Code unterlaufen. Plötzlich fehlt unter dem Formular der Button zum Abschicken. Der Kunde hat also keine Chance, über seinen Browser einen Request zu erzeugen. Zabbix würde aber keine Fehler melden.

Wenn Sie also mehr Sicherheit beim Überwachen von Webseiten erreichen wollen, sollten Sie ggf. noch folgende Datenquellen in Zabbix einbinden:

  • Regression Test: Tests, die automatisiert von einem vollwertigen Browser ausgeführt werden. Seleniumhq, Sahi oder Watir sind einige Open-Source-Tools, die zur „Fernsteuerung“ eines Browsers eingesetzt werden können. Die kostenlosen Firefox-Plugins DéjàClick und iMacros leisten ebenfalls gute Dienste.
  • Beobachtung der KPIs: Identifizieren Sie die Kennwerte Ihrer Webseite (Key Performance Indicators), an denen Sie ablesen können, dass alles o.k. ist (Page Impressions, Anzahl der Bestellungen, Anzahl von internen Suchen etc.). Mit dem Database Monitor können Sie solche Werte zum Beispiel auf stündlicher Basis von Zabbix erfassen lassen. Wenn nun der oben erwähnte Button unter dem Bestellformular fehlt, werden die Bestellungen pro Stunde schlagartig abfallen. Auf diese Weise können Sie auch Fehler in Ihrer Webpräsenz feststellen. Das freie Webanalyse-Tool Piwik kann auch als Datenquelle für Zabbix verwendet werden. In Piwik können Sie sogenannte Conversion-Elemente definieren (Klicken von Links, Ausfüllen von Formularen etc.). Da Piwik die Daten in Echtzeit verarbeitet, kann Zabbix einen Alarm auslösen, sobald die Conversion Rate von einzelnen Elementen unter ein Limit fällt.

Webszenarios einrichten

Um eine Webseite mit Zabbix regelmäßig zu testen, müssen Sie über das Hauptmenü Configuration|Web ein neues Szenario mit dem Button oben rechts „Create Scenario“ anlegen. Über das Dropdown-Menü unter dem Button wählen Sie aus, für welchen Host die Webseitenüberwachung angelegt wird.

Einen Host auswählen

Die für einen Host hinterlegten Daten wie DNS-Name oder IP-Adresse werden für die Webszenarions per Standard nicht verwendet. Sie geben später komplette URLs an, welche immer über eine DNS-Abfrage aufgelöst werden. Über Makros können URLs dynamisch zusammengesetzt werden, so dass der konfigurierte Hostname Teil der URL ist.

Beachten Sie, dass wenn ein Host von einem Proxy überwacht wird, auch die HTTP-Requests der Webszenarios vom Proxy ausgeführt werden.

Oft ist es sinnvoll, die überwachten Domains als eigene Hosts anzulegen und das Webszenario nicht für den Host anzulegen, der den Webserver beherbergt. Legen Sie zum Beispiel websrv01.example.local und www.example.com als getrennte Hosts in Zabbix an. Das gibt Ihnen die Möglichkeit, die Webtests von einem externen Proxy außerhalb des Firmennetzes durchzuführen, während der Zabbix-Server sich im internen Netz zusammen mit dem Webserver befindet. Wenn Sie Webseiten „von innen“ überwachen, bleiben Probleme beim Routing oder DNS oft unbemerkt. Die gemessene Webseitengeschwindigkeit ist dann auch meistens unrealistisch.

Nachdem Sie sich für einen geeigneten Host entschieden haben, klicken Sie in der Übersicht der Hosts oder Templates auf den Link Web in der Zeile des Hosts. Über den Link Create Scenario oben rechts legen Sie einen neuen Webtest an. Alle vom Test gesammelten Daten werden wie gewohnt als Items in der Datenbank gespeichert. Um die Auswahl und Benennung von Item-Keys müssen Sie sich aber nicht kümmern. Das macht Zabbix im Hintergrund automatisch. Sie müssen sich aber, wie bei jedem Item, entscheiden, unter welcher Application (Item-Gruppierung) die Messwerte später zu finden sein sollen. Wählen Sie eine vorhandene Application aus oder legen Sie eine neue an, zum Beispiel Webtest.

Anlegen eines Webseitentests, genannt Webszenario

Test anlegen

Im Feld „Name“ geben Sie dem Test einen Namen. Unter diesem Namen finden Sie den Test später unter Monitoring|Latest Data, Monitoring|Web und bei der Einrichtung von Triggern wieder.

Über das Dropdown-Menü Basic authentication können Sie eine Anmeldung mit Benutzernamen und Passwort für passwortgeschützte Webseiten einrichten. Verwenden Sie diese Option, wenn der Webserver die Anmeldung durchführt, das heißt, der Webserver erzwingt die Eingabe von Benutzernamen und Passwort durch Senden des Headers „401 Authorization Required“. Verwenden Sie diese Option nicht, wenn die Anmeldung auf einer Webseite durch ein HTML-Formular erfolgt.

Über das Update-Intervall legen Sie wie gewohnt fest, wie häufig der Test durchgeführt werden soll.

Über das Dropdown-Menü Agent können Sie auswählen, als welcher Browser sich Zabbix tarnen soll. Wenn Sie „other“ auswählen, können Sie auch eine beliebige Wortfolge als User Agent eingeben. Wenn Sie zum Beispiel Zabbix als Agent eintragen, können Sie später Ihre Statistiken einfacher bereinigen, indem Sie alle Anfragen von diesem Browser bei den Auswertungen der Logfiles ignorieren. Wenn Sie Tools wie Google Analytics oder Piwik verwenden, brauchen Sie sich keine Sorgen wegen eventuell verfälschter Statistiken machen. Beide Tools messen Webseitenaufrufe mit JavaScript, welches Zabbix nicht ausführt. Die Tests von Zabbix werden nicht als Page Impression gezählt.

Im Eingabefeld Variablen können Sie Werte hinterlegen, die bei allen Requests des Tests gebraucht werden. Zum Beispiel einen Benutzernamen, eine Session-ID oder Artikelnummern. Auf den Wert der Variablen können Sie später in POST Request zugreifen. Geben Sie nur solche Werte als Variablen an, die in mehreren Requests verwendet werden. Wenn Sie auf den Inhalt einer Variablen zurückgreifen wollen, geben Sie die Variable inklusive der geschweiften Klammer ein. Die Variablen werden im folgenden Format definiert:

{var1}=value1
{username}=hans
{password}=geheim
{article}=59767

Im Feld Header können Sie manuell HTTP-Header setzen. Das ist besonders nützlich, wenn Sie alle Webserver eines Verbundes hinter einem Loadbalancer testen wollen. Sie können den Webserver gezielt per IP-Adresse ansprechen. Damit der richtige Inhalt ausgeliefert wird, setzen Sie den HTTP-Header mit dem Hostnamen manuell. Die Webseite www.daserste.de wird in der Regel von drei Webservern oder Loadbalancern ausgeliefert, die per DNS-Round-Robin per Zufall ausgewählt werden, wie ein DNS-Lookup zeigt.

[root@localhost ~]# host -a www.daserste.de
Trying "www.daserste.de"
ANSWER SECTION:
www.daserste.de.  3484  IN  CNAME  cdn.ard.com.c.footprint.net.
cdn.ard.com.c.footprint.net. 80  IN  A  198.78.208.254
cdn.ard.com.c.footprint.net. 80  IN  A  207.123.56.126
cdn.ard.com.c.footprint.net. 80  IN  A  8.12.207.254

Wenn Sie nun alle drei einzeln prüfen wollen, müssen Sie die DNS-Namensauflösung umgehen. Ein direkter Aufruf des Webservers per IP-Adresse bringt nicht das gewünschte Ergebnis, denn der Webserver weiß nicht, welche Domain angefordert wird. Erst durch manuelles Setzen des sogenannten Host-Headers gelingt der Test.

curl -H "Host:www.daserste.de" http://198.78.208.254
Anlegen einer neuen Webseitenüberwachung

Schritte (URLs) hinzufügen

Mit dem Button Add geben Sie die einzelnen URLs an, welche innerhalb des Tests aufgerufen werden. Dabei müssen Sie jeder URL einen Namen geben. Über diesen Namen finden Sie die URL später in den Auswertungen der Download-Geschwindigkeit und der fehlgeschlagenen Aufrufe wieder.

Bevor Sie nun einen einzelnen umfangreichen Test anlegen, der in vielen Requests Ihre komplette Webseite durchtestet, bedenken Sie Folgendes: Beim Einrichten der Trigger können Sie nur auswerten, ob ein Schritt in der Kette fehlgeschlagen ist. Welche URL in diesem Schritt aufgerufen wurde, kann nicht ausgewertet werden. Sie können letztendlich pro Szenario nur zwei sinnvolle Trigger anlegen. Einer wertet aus, ob es Fehler oder keine gab. Der zweite wertet die Download-Geschwindigkeit aus. Es gibt keine Möglichkeit, in einer Aktion (Mail, SMS) den genauen Schritt zu benennen, an dem der Test fehlgeschlagen ist. Wenn Sie ein großes Szenario mit vielen Schritten anlegen, erhalten Sie später immer nur eine Nachricht: „Im Szenario X ist ein Fehler aufgetreten.“ Wenn Sie in einer Nachricht genau wissen wollen, auf welcher URL ein Fehler festgestellt wurde, sollten Sie besser mehrere Szenarios mit nur wenigen Schritten anlegen.

Im Feld URL geben Sie die URL inklusive Protokoll und GET-Parameter ein. Zum Beispiel http://www.google.de/search?q=zabbix. Wenn Sie ein Webszenario in einem Template anlegen, können Sie die URL auch mit Makro {HOST.CONN} eintragen. Sobald Sie das Template auf einen Host anwenden, werden die Verbindungsdaten in die URL eingesetzt. Wenn Sie zum Beispiel über ein Template die Startseiten verschiedener Domains testen wollen, können Sie als globales Makro {$START_PAGE} = / setzen. Pro Host können Sie nun eine abweichende Startseite definieren. Als URL im Webszenario würden Sie dann http://{HOST.CONN}{$START_PAGE} eintragen.

Die Verwendung der Macros {HOST.CONN1-9} ist in den Steps der Webscenarios nicht möglich. Verwenden Sie nur {HOST.CONN} ohne Angabe einer Nummer.

Sobald Sie im Feld Post Werte eintragen, wird der HTTP-Request als POST-Request ausgeführt. Welche Post-Requests ein Formular erzeugt, können Sie zum Beispiel mit dem Firefox-Plugin Firebug herausfinden.

Wenn Sie die Option Retrieve only headers aktivieren, werden nur die HTTP-Header heruntergeladen und überprüft. Dies ist bei besonders umfangreichen Webseiten ratsam, wenn Sie nur den HTTP-Statuscode prüfen wollen. Eine Inhaltsprüfung ist nicht möglich, wenn der Zabbix-Server nur die Header herunterlädt. Der Aufruf entspricht ungefähr einem Curl-Aufruf mit der Option -I.

[root@localhost ~]# curl -I http://lab4.org
HTTP/1.1 200 OK
Date: Mon, 28 Jul 2014 16:36:56 GMT
Server: Apache/2.2.22 (Debian)
Last-Modified: Wed, 01 Sep 2010 14:33:25 GMT
ETag: "40a1e-0-48f339489b740"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Type: text/html

Über den Wert Timeout legen Sie fest, wie viele Sekunden Zabbix auf eine Antwort warten soll. Wird diese Zeit überschritten, wird der Schritt als „failed“ deklariert und abgebrochen.

Im Feld Required string tragen Sie ein, welche Wörter in der angeforderten Webseite enthalten sein müssen. Werden diese Wörter nicht gefunden, wird der Schritt ebenfalls als „failed“ deklariert. Die hinterlegten Wörter werden im gesamten HTML-Quellcode gesucht. Sie können also auch nach Wörtern in Kommentaren oder CSS-Anweisungen suchen. Die Groß- und Kleinschreibung wird beachtet.

Über das Feld Required Status Code können Sie festlegen, welchen HTTP-Status die Webseite senden muss. Wenn Sie keinen Status eingeben, werden alle Status akzeptiert. Wenn Sie zum Beispiel sicherstellen wollen, dass auf einer URL immer eine Weiterleitung zu einer anderen Seite gesendet wird, dann tragen Sie als Status-code „301“ ein. Wenn Sie prüfen wollen, ob eine Webseite einen „normalen“ Inhalt ausgibt, tragen Sie „200“ ein.

Hinzufügen eines Schrittes innerhalb eines Webszenarios

POST-Daten verwenden

Sie haben die Möglichkeit, bei den einzelnen Schritten eines Webszenarios den Seitenabruf als HTTP-POST-Request zum Webserver zu schicken. Damit simuliert der Zabbix-Server das Abschicken eines Formulars. So können Sie zum Beispiel Logins oder Bestell- und Anmeldevorgänge testen. Die Möglichkeiten von Zabbix sind dabei aber beschränkt. Viele Webseiten verlangen zum Beispiel die Existenz einer Session-ID, ohne die Login-Daten eines Formulars nicht akzeptiert werden. Ebenfalls kann das Absenden von POST-Requests nicht zum gewünschten Resultat führen, weil Zabbix kein JavaScript ausführt.

Zahlreiche Firefox-Addons, zum Beispiel Tamper Data und Firebug, können die von einem Formular verschickten POST-Daten anzeigen.

Firebug zeigt die POST-Daten eines Formulars an.

Die POST-Daten tragen Sie dann im Eingabefeld „POST“ eines Webszenario-Schritts ein. Mehrere Werte werden mit einem Kaufmanns-Und getrennt und dürfen keinen Zeilenumbruch enthalten. Beispiel:

username=Thorsten&password=geheim&sender_site=www.example.com

Wenn Sie auf Variablen zurückgreifen wollen, welche Sie für alle Schritte eines Szenarios definiert haben, geben Sie diese in geschweiften Klammern an. Beispiel:

username={username}&password={password}
Senden von POST-Daten in einem Webszenario

Ergebnisse der Webtests auswerten

Die Ergebnisse der Webtests können Sie an zwei Stellen ablesen. Über das Hauptmenü Monitoring|Web sehen Sie ein zusammengefasstes Endergebnis der einzelnen Tests. Hinter einem Test ist entweder „OK“ vermerkt, wenn alle Schritte erfolgreich getestet wurden, oder Sie finden einen Hinweis wie zum Beispiel „Failed on Zweite Seite [2 of 2] Error: Page did not match“.
Wenn Sie in der linken Spalte auf den Namen eines Webszenarios klicken, erhalten Sie einen spontanen Graphen mit den Download-Geschwindigkeiten aller Schritte innerhalb der letzten Stunde.

Die zusammengefassten Ergebnisse eines Webtests

Über das Hauptmenü Monitoring|Latest Data können Sie ebenfalls die Ergebnisse der Webtests ablesen. An dieser Stelle erhalten Sie eine detaillierte Auskunft über die Webtests. Der Wert „Response time for step X“ gibt an, wie lange der Download der Seite gedauert hat. Gemessen wird die Zeit, die von der Anfrage bis zur Beendigung der Verbindung nach dem Download verstrichen ist.
Der Wert „Failed step of scenario X“ gibt immer den ersten fehlgeschlagenen Schritt an. Wenn mehrere Schritte fehlschlagen, wird trotzdem nur der erste fehlgeschlagene Schritt vermerkt. Wenn alle Schritte erfolgreich getestet wurden, wird 0 angezeigt.

Die detaillierten Ergebnisse eines Webtests

Trigger für Webszenarios einrichten

Die Trigger für Webszenarios richten Sie wie jeden anderen Trigger ein. Über das Hauptmenü Configuration|Host wählen Sie den Host aus, für den das Webszenario eingerichtet wurde. Klicken Sie in der Spalte hinter dem Hostnamen auf Trigger und oben rechts auf „Create Trigger“.

Sie können nun einen Trigger einrichten, der alarmiert, wenn ein Schritt im Szenario fehlgeschlagen ist. Zum Beispiel {lab4.org:web.test.fail[Lab4.org Webtest].last(0)}>0.

Auswerten eines Webszenarios mit einem Trigger

Die Response Time oder die Response Status der einzelnen Schritte können Sie ebenfalls von Triggern auswerten lassen.

Beachten Sie, dass sich nur das Item web.test.fail auf das Gesamtresultat eines kompletten Szenarios bezieht. Wenn Sie einzelne Schritte von einem Trigger auswerten lassen, müssen Sie die Trigger anpassen oder einen neuen hinzufügen, sobald Sie Schritte ändern oder hinzufügen.

Alternativen zu Webszenarios

Wenn Sie viele Webseiten überwachen müssen, ist das Anlegen und Pflegen von Webszenarios aufwendig und zeitraubend. Vor der Zabbix-Version 2.2 war die fehlende Möglichkeit, Webszenarios in Templates anzulegen, ein echtes Problem. Wenn Sie viele URLs nur auf Verfügbarkeit und ausgelieferten Inhalt prüfen wollen, dann sind selbst angelegte Tests in Form von Shell- oder Perl-Skripten vielleicht effektiver. Siehe auch Kapitel Zabbix_erweitern_mit_External_Checks.

Die nachfolgenden Skripte und Beispiele gehen davon aus, dass Sie die Domains, auf denen die Webseiten geprüft werden, als Hosts angelegt haben. Wenn Sie zum Beispiel den Inhalt von http://lin4.de/blog prüfen wollen, legen Sie lin4.de zuerst als Host an. Anders als bei den Webszenarios müssen Sie die Domain nicht noch einmal für den Check eintragen. Diese wird immer aus dem Host gebildet.

Webtest mit Bash und Curl

In vielen Fällen ist ein Zabbix-Webszenario „oversized“, wenn man zum Beispiel nur testen möchte, mit welchem HTTP-Status ein Webserver antwortet.

Nachfolgend finden Sie ein Beispiel für einen einfachen Webseitentest, den Sie als External-Skript auf dem Zabbix-Server oder Proxy anlegen. Beachten Sie die allgemeine Vorgehensweise zum Einbinden externer Skripte im Kapitel Zabbix-Server mit eigenen Datenquellen erweitern.

Das Skript verwendet die in der Hostkonfiguration angelegten Verbindungsdaten (IP oder DNS-Name), so dass Sie ein entsprechendes Item auch in einem Template anlegen können.

#!/bin/bash
if [ $3 ]; then
        PROTO=$3
else
        PROTO=http
fi

if [ $2 ]; then
        URL=$PROTO://${1}${2}
else
        URL=$PROTO://$1
fi
curl -s -m 20 -i $URL|head -n1|awk '{print $2}'

Nennen Sie das zuvor genannte Skript zum Beispiel http.status und machen Sie es mit chmod +x http.status ausführbar.
Nun können Sie ein Item vom Typ „external Check“ nach dem Muster http.status[{HOST.CONN},<PATH>,<PROTOCOLL>] anlegen. Sie erhalten als Item-Value den HTTP-Statuscode, mit dem der Webserver antwortet.

Item zum „einfachen“ Abfragen des HTTP-Status

Legen Sie das nachfolgende Skript unter dem Namen http.grep an. Sie können es dazu nutzen, Webseiten nach einem Stichwort zu durchsuchen. Sie erhalten als Rückgabe die Anzahl der Fundstellen. Das Item legen Sie nach dem Muster http.grep[{HOST.CONN},<SEARCH>,<PATH>,<PROTOCOLL>] an.

#!/bin/bash
if [ $2 ];then
        SEARCH=$2
else
        echo "-1"
        exit 1
fi

if [ $4 ]; then
        PROTO=$4
else
        PROTO=http
fi

if [ $3 ]; then
        URL=$PROTO://${1}${3}
else
        URL=$PROTO://$1
fi
curl -s -m 20 $URL|grep -c $SEARCH