Zabbix bietet uns von Hause aus die Möglichkeit ein Web Monitoring zu konfigurieren. Dabei ist es möglich ein Webszenario inklusive Unterstützung für Cookies, HTTP Basic Auth, Proxy und POST Daten zu konfigurieren. Für jeden Schritt in diesem Szenario können wir auch noch den HTTP Status Code des Webservers prüfen oder die ausgelieferte Seite mit einem regulären Ausdruck durchsuchen. Am interessantesten dabei: Die Aufstellung der Antwortzeiten.

Soweit ist das Web Monitoring welches uns Zabbix hier bietet eine schöne Sache mit vielen Möglichkeiten, es gibt aber einen Pferdefuß bei diesem Setup: Es ist bei schlechter Performance nicht möglich zu sagen ob das Problem wirklich bei der geprüften Website liegt oder möglicherweise bei unserem Zabbix Server.

Seriöse Anbieter von Webmonitoring Lösungen umgehen dieses Problem dadurch dass die Website von vielen verschiedenen Systemen an unterschiedlichen Standorten geprüft wird. Die Summe der Daten wird dann entsprechend bereinigt und kann sogar geographisch gruppiert werden.

Mit genau diesem Ansatz können wir auch bei Zabbix arbeiten. Die Lösung? Der Zabbix Proxy! Idealerweise haben wir schon Proxys an verschiedenen Firmenstandorten im Einsatz. Wir können nun auf diese Proxys zurückgreifen um zusätzliche Daten zu erfassen und das Webmonitoring somit von Fehlern zu bereinigen. Je mehr Proxys wir haben um so genauer wird unser Monitoring.

Folgend erkläre ich die grundlegenden Schritte am Beispiel eines einfachen Web Monitorings von zwei Systemen aus.

Das Webszenario

Als erstes legen wir für die zu monitorende Website ein neues Template an. In unserem Template konfigurieren wir nun wie gewohnt unser Web Szenario.

Die “Probes”

Als zweite Zutat kommen unsere “Probes” – also die Systeme von denen geprüft wird dazu. Als erstes legen wir eine neue Hostgroup an. Dieser fügen wir nun einen neuen Host hinzu.

Das erste System welches unsere Website Prüfen kann ist natürlich der Zabbix Server selber. Dazu legen wir einfach einen neuen Host hinzu, nennen diesen Beispielsweise “Probe-1″ und Speichern diesen ab. Als zweites System verwenden wir einen unserer Zabbix Proxys, dazu gehen wir genau so vor wie schon bei unserem “Probe-1″. nur dass wir dieses mal bei der Hostkonfiguration einen Proxy für den Host auswählen.

Daten sammeln und bereinigen

Nun wird es interessant – wir verpassen unseren beiden “Probes” das im ersten Schritt angelegte Template welches das Webszenario beinhaltet. Nachdem wir das getan haben erstellen wir einen dritten Host. Dieser darf, muss aber nicht, in unserer neuen Hostgroup sein. Zweck dieses Hosts ist es als “Anlaufstelle” zu dienen. Hier legen wir gleich unsere Daten ab und aggregieren diese.

Zum jetzigen Zeitpunkt sollten wir auf den Hosts “Probe-1″ und “Probe-2″ jeweils ein funktionierendes Webmonitoring haben. Eines repräsentiert die Performance von unserem Zabbix Server, das andere die vom Standort des Proxys.

Diese wollen wir nun sinnvoll zusammenführen. Dazu verwenden wir die “Aggregated Items” von Zabbix. Mit diesen Items ist es möglich Items einer Hostgruppe zu aggregieren, die offizielle Zabbix Dokumentation sagt uns dazu alles Wissenswerte inklusive einiger Beispiele.

Für unseren Fall am interessantesten ist die Gruppenfunktion grpmin die immer nur den kleinsten Itemwert innerhalb der Gruppe speichert. Bei mehr als 2 “Probes” wäre sicherlich auch die grpavg Funktion brauchbar.

Wir legen nun auf unserem dritten Host – ich habe ihn “Webmonitoring-Aggregated” genannt – ein neues Item an.

Unbenannt

Der Item Key erwartet als Parameter einmal die Hostgruppe in welcher die Daten aggregiert werden sollen, diese habe ich in diesem Beispiel einfach “Pascal” genannt, den Key der aggregiert werden soll – hier die response Time unseres Web Monitorings, und die zu verwendende Itemfunktion mit Parameter. In meinem Fall kommt man zu dem Key grpmin[„Pascal“,“web.test.time[DistributedWebmonitoringTest,Main,resp]“,last,0]

Das “resp” Item des Webmonitorings verwendet die SI Basiseinheit der Zeit: “Sekunden”, also “s”. Diesen geben wir auch so an damit Zabbix automatisch in die für uns interessanten “ms” umrechnen kann.

Dieses neue Item repräsentiert nun immer die kleinste Responsetime innerhalb unserer Probe-Gruppe, somit müssen wir nicht mehr mit Fehlern rechnen wenn zum Beispiel auf unserem Zabbix Server gerade das tägliche Backup auf die Performance schlägt oder einfach nur der Provider Probleme hat. Durch hinzufügen mehrerer “Probes” kann man hier die Fehleranfälligkeit so weit senken bis man ein vertrauenswürdiges Webmonitoring erhält. Das anlegen von Graphen und Triggern mit unseren bereinigten Daten ist nurnoch eine Fingerübung.

Unbenannt

Markiert in:     

Schreibe einen Kommentar

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