Thorsten Kramm

Am 22.10.2012 um 19.00 Uhr findet in Berlin ein informeller Austausch über Zabbix statt. Die Teilnahme ist kostenlos.

Eingeladen sind Zabbix-Benutzer und solche, die Zabbix kennen lernen wollen. Themen sind:

• Wie leistungsfähig ist Zabbix?
• Was unterscheidet Zabbix von anderen Monitoring Lösungen?
• Wie steigt man einfach aber erfolgreich ein oder um?

Ich werde einen kurzen Vortrag über die Leistungsfähigkeit von Zabbix halten. Danach offenes Gespräch, Fragen stellen, Austausch. Für Getränke und ein paar Snacks ist gesorgt.

Das ganze findet statt bei:
Semigator AG
Am Treptower Park 75 (S-Bahn Treptower Park)
12435 Berlin
Bitte Eck-Eingang beim Hörakustiker nutzen, nicht Nebeneingang mit Hausnummer 75.
Dann über Treppenhaus (nicht Aufzug) ins 5. OG zur Semigator AG
Wer es nicht findet oder im Gebäude verloren geht, bitte anrufen: 030/609856742.

There is a nice feature in Zabbix called “Database Monitoring”. It allows you to query any database and store the result as an item value in Zabbix as any other item. Now you can put a trigger on that item to raise alarms.

Unfortunately the so called function “Database Monitor” is not very well documented. Many people are asking in forums how to get it working. The installation of UnixODBC is sometimes tricky, because some distributions ship old versions of UnixODBC.

I’ve done some research and many trails and errors.

If you are interested in Database Monitoring read my new howto. There is an english version and a german version.

Feeedback is welcome.

Egal ob man nur eine Hand voll oder hunderte Server mit Zabbix überwacht; immer wieder kommt es vor, dass Daten (Items) nicht gesammelt werden können.

Dafür gibt es viele Gründe:

• Unterschiedliche Voraussetzungen im Betriebssystem
• Fehlende Rechte (Sudo-Regeln)
• Externe Skripte (User Parameter) fehlen
• Skripte laufen zu lange
• etc

Items, für die Zabbix keine Daten sammeln kann, werden stillschweigend ignoriert. Da Trigger erst in dem Moment ausgelöst werden, in dem die Daten des Items in der Datenbank ankommen, lösen Trigger für fehlerhafte Items niemals aus.

Eine Lösung ist, für jedes Items einen Trigger mit der Funktion “nodata()” einzurichten. Dieser Trigger löst aus, wenn für das Item keine Updates in der Datenbank erfolgen.

Bei mehreren Dutzend Triggern kann das zu einer mühseligen Aufgabe werden.

Zabbix bietet ein internes Item, welches die Anzahl alle fehlerhaften Items zurück liefert. Bei einer kleinen Anzahl von Host vielleicht eine Lösung, um Fehlerhafte Items zu korrigieren.

Im Wiki findet Ihr nun eine Lösung, welches für jeden Host ein neues Item hinzufügt, in dem Anzahl und Bezeichnung der fehlerhaften Items gespeichert sind. Nun kann man bei der Fehlerbehung sehr zielgerichtet vorgehen. Fehler im Zabbix Monitoring sofort erkennen ganzen Artikel lesen

Soeben habe ich eine Umfassende Anleitung zur Überwachung von ESX und ESXi Servern mit Zabbix fertig gestellt.

Dabei wird nicht SNMP sondern CIM verwendet.

CIM bedeutet “Common Information Model”. Sowohl der ESX als auch der ESXi Server ermöglichen über eine HTTP-API die Abfrage aller Objekte im ESX Server.

Der Zabbix-Server kann den ESX oder ESXi Server auf dieselbe Weise abfragen, wie der vSphere-Client.

Über ein kurzes Python-Script wird die CIM-API nach dem sogenannten HealthState der Hardware abgefragt. Der HealthState wird dann als numerischer Wert an Zabbix übergeben und kann dort wie jedes andere Item weiterverarbeitet werden.

Die Überwachung per CIM-API hat den Vorteil, dass sie sowohl unter ESX als auch ESXi funktioniert. Der kostenlose ESXi Server verfügt ja über keine volle SNMP-Unterstützung und kann nicht aktiv per SNMP überwacht werden.

Hier stellt CIM ein gute Alternative dar.

Alle Details, das Python-Skript und die komplette Anleitung findet man im Wiki.

Festplatten sind die Teile eines Server, die am häufigsten ausfallen.
Zum Glück gibt es Raids, die Daten auf verschiedene Festplatten ausfallsicher verteilen.
Dumm nur, wenn man nicht mitbekommt, dass in einem Verbund von Festplatten eine oder mehrere bereits ausgefallen sind.
Deshalb sollte man immer die Status seiner Raid-Verbünde überwachen. Alle Hersteller von Raid-Controllern für den professionellen Einsatz stellen Werkzeuge für die Kommandozeile zur Verfügung mit denen Zabbix den Status der Raid-Verbünde und der einzelnen Festplatten überwachen kann.
Einige Kontroller, wie z.B. die des Herstellers LSI geben Auskunft über die sogenannten “Media Errors”. Media Errors sind nicht kritisch, weil alle Daten geschrieben werden können. Aber das Auftauchen von Mediaerrors ist oft ein Anzeichen dafür, das bald Schlimmeres mit der Festplatte passieren kann.
Der Hardwarehersteller Dell tauscht Festplatten übrigens sofort aus, sobald ein Media Error auftaucht.
Anleitungen für das Überwachen von Raidcontrollern der Hersteller LSI, 3ware, Adaptec und Areca findet man im Wiki in der denen Kategorie Hardwareüberwachung.

In vielen Situationen reichen die integrierten “Simple Checks” von Zabbix nicht aus, um  die Verfügbarkeit eines Dienstes zu testen.

Leider sind die “Simple Checks” nur einfache Portscanner, die prüfen, ob ein Port offen ist. Wer oder was da antwortet, wird nicht berücksichtigt. Ein HTTP-Check auf Port 22 liefert auch zurück, dass der HTTP-Port offen ist.

Doch zum Glück können wir Zabbix ja schnell und einfach mit externen Checks erweitern.

Mit Curl teste ich jetzt, ob auf einem Port auch wirklich ein Webserver und kein SSH-Daemon antwortet.

curl --silent --head $URL|head -n1|grep -c "HTTP"

gibt 1 zurück, wenn ein Webserver antwortet, andernfalls 0.

Das Zabbix-Handbuch wurde aus diesem Anlass um zwei Seiten erweitert.

Zabbix erweitern mit externen Checks und dazu einige Beispiele.

Seit Wochen doktore ich mit dem Zabbix Proxy herum.

Der zentral im Frankfurter Rechenzentrum installierte Zabbix Server soll auch das Intranet in zwei Büros überwachen. In einem Büro hatte ich einen passiven Zabbix-Proxy installiert, der über ein Portforwarding vom Zabbix Server aus erreichbar ist.

Das zweite Büro wurde mit einem aktiven Proxy versorgt, weil keine Änderungen an der Firewall vorgenommen werden sollte.

Fazit: Nur der passive Proxy funktioniert zuverlässig. Der aktive Proxy verbindet sich zwar mit dem Zabbix Server und ruft die Konfiguration ab, aber die Daten (Item Values) kommen nicht zuverlässig auf dem Server an.

In der Datenbank des Proxies konnte ich beobachten, dass alle Daten der Agents abgerufen werden und in der Proxy-Datenbank stets aktuell vorlagen. Nur wurden diese Daten erratisch, gar nicht oder mit Verzögerung an den Zabbix Server geschickt. Da Ändern der Sender Frequenz brachte auch keine Lösung.

Ende vom Lied: Beide Proxies arbeiten jetzt im passiven Modus. Ein Proxy stellt dazu per autossh einen rückwärtigen Tunnel zum Zabbix Server her. Nicht optimal, aber es funktioniert!

Nachdem ich ca. 1,5 Jahre immer mal wieder an einem Deutschen Zabbix Handbuch geschrieben habe, ist nun die erste Version online.

In Form eine Wikis (Mediawiki) kann nun jeder kostenlos lesen, wie man Zabbix installiert, einrichtet und damit professionell Arbeitet. Neben dem Basiswissen werden viele Tipps aus der Praxis gegeben, die größtenteils aus meiner täglichen Arbeit stammen.

Also, reinschauen und weitersagen.

http://lab4.org/wiki/Zabbix_Handbuch_Inhaltsverzeichnis

Auch wenn MySQL die Datenbankreplikation offiziell nicht als Lösung für Hochverfügbarkeit deklariert, nutzen trotzdem viele User die Replikation zu diesem Zweck.

Hinter eine Master-Datenbank läuft eine Slave-Datenbank permanent mit. Fällt der Master aus, arbeitet die Aplikation mit dem Slave weiter. Solange dieses Konstrukt aus nur zwei Komponenten besteht, einem Master und einem Slave, ist die Handhabung relativ einfach.

Kompliziertet wird es, wie in meinem Fall, wenn hinter der Masterdatenbank mehrere Slaves arbeiten und diese von der Applikation für Suchanfragen auch permanent benutzt werden.

Würde mir die Master-DB ausfallen, könnte ich zwar einen Slave als neuen Master deklarieren, aber die verbleibenden Slaves blieben dann ohne Updates, weil sie diese immer noch auf dem ausgefallenen Master suchen. Die Aplikation würde dann Suchen auf veralteten Tabellen durchführen. Und die Aplikation nur noch mit einer Datenbank betrieben kommt auch nicht in Frage, weil eine Datenbank unter der Last der Anfragen zusammenbrechen würde.

Fällt also meine Master-Datenbank aus, wird ein Slave zum Master gemacht und alle anderen Slaves müssen sich mit dem neuen Master “verheiraten” und dessen Tabellen replizieren.

Downtime MySQL Replikation per FTP-Server Initialisieren ganzen Artikel lesen

In zich Foren und Howto-Sammlungen wird über den Aufbau eines XenClusters geschrieben. Den vielen Fragen nach zu urteilen, besteht hier Bedarf. Und mal ehrlich, wer hätte sie nicht gerne, die vollredundante hochverfügbare Virtualisierungumgebung, so dass die virtuellen Maschinen immer online sind.

Meine Recherchen und praktischen Versuchen kann ich wie folgt zusammenfassen:

Knackpunkt der Hochverfügbarkeit ist das Storage-System, also der Teil des Systems, der den VMs die virtuellen Festplatten zur Verfügung stellt.
Ein redundantes und hochverfügbares Storage-System mit OpenSourcemitteln zu bauen, dass per iSCCI oder FC Luns o.Ä. den Xenhosts verfügbar macht, halte ich mittlerweile für utopisch.
Wer sich ein kommerzielles SAN kauft, ist schneller am Ziel. (Dazu bald mehr, wenn mein Infortrend SAN geliefert wurde.)
An die SAN-Kisten kommen die Xenhosts, und die Storage ist auf allen Maschinen verfügbar, so dass jede Dom0 auch jede DomU starten kann. Soweit ganz einfach.

Für den Anfang kann man aus zwei Servern mit Hartbeat und DRBD einen NFS-Server bauen. Auf die daraus entstehende hochverfügbare Freigabe legen die Xenhosts ihre die Loopback-Files ab. Ob das performant ist, hängt von der IO-Last der VMs ab. Mythos XenCluster, kann man es wirklich schaffen? ganzen Artikel lesen