Zabbix ist ein großartiges Produkt für Administratoren großer Software- und Hardwaresysteme. Es ist so gut, dass es nicht nur von Großunternehmen, sondern auch von mittelständischen Unternehmen und sogar in einem pet . Im Allgemeinen habe ich wenig Erfahrung mit Zabbix und kann es ohne Bedenken zur Verwendung empfehlen.
Natürlich kann ich nicht sagen, dass ich die „ Zabbix-Philosophie “ verstehe. Trotz der umfangreichen detaillierten Dokumentation in russischer Sprache war es für mich schwierig, in die Welt von Zabbix einzutauchen - ich hatte das Gefühl, dass die Entwickler und ich die gleichen Dinge bei unterschiedlichen Namen nannten. Vielleicht, weil Zabbix von Admins für Admins erstellt wurde, aber ich bin immer noch ein Entwickler und ein Benutzer.
Um Zabbix auszuführen und die wichtigsten Parameter von Computersystemen (Prozessor, Speicher usw.) zu überwachen, sind jedoch die Fähigkeiten eines normalen Linux-Benutzers ausreichend. Es gibt eine große Anzahl von Plug-Ins von Drittanbietern, die die Funktionen von Zabbix erweitern. Für meine Bedürfnisse musste ich die Überwachung des Redis-Servers konfigurieren. Ich habe ein wenig im Code der verfügbaren Plug-Ins gestöbert und anhand ihres Beispiels herausgefunden, dass die Architektur von Zabbix es Ihnen ermöglicht, einfach eine Verbindung zur Überwachung aller Parameter von Informationssystemen herzustellen, die in numerischer Form ausgedrückt werden können.
Unter der Katze - ein Beispiel für ein Zabbix-Plugin mit meiner Erklärung der Zabbix-Terminologie. Für einige wird dieses Beispiel naiv erscheinen, für andere wird es einfacher sein, sich mit Konzepten vertraut zu machen. In jedem Fall ist Zabbix groß genug , um es aus verschiedenen Blickwinkeln zu fühlen.
Grundlegende Konzepte
Kurz über einige der in Zabbix verwendeten Konzepte: Agenten , Elemente , Trigger , Aktionen , Benachrichtigungen , Vorlagen .
Server und Agenten
Aus Sicht des Benutzers ist Zabbix in zwei große Teile unterteilt: Server und Agenten. Der Server befindet sich auf einem Computer, auf dem statistische Daten erfasst und gespeichert werden, und Agenten auf den Computern, auf denen Daten erfasst werden:
Überwachungsoptionen
Jede Menge, die in numerischer Form oder als Zeichenfolge ausgedrückt werden kann, wird in der Terminologie von Zabbix - einem Datenelement (Element) - aufgerufen. Jedem Element ist ein eindeutiger Schlüssel (Name) zugeordnet. Hier sind Beispiele für Datenelemente:
- system.cpu.load [percpu, avg1] : 0.1167
- system.uname : "Linux supru 4.15.0-50-generic # 54-Ubuntu SMP Mo 6. Mai 18:46:08 UTC 2019 x86_64"
Die Werte dieser Datenelemente (Überwachungsparameter) werden an die Zeit angehängt, die Historie der Parameterwerte wird in der Serverdatenbank gespeichert.
Ereignisse
Wenn ein Ereignis in Zabbix eintritt, wird ein Trigger ausgelöst. Zum Beispiel
- {system.cpu.load [percpu, avg1] .avg (5m)}> 10 - Der Durchschnittswert des Parameters in den letzten 5 Minuten hat "10" überschritten.
- {system.uname.diff (0)}> 0 - Der aktuelle Wert des Parameters entspricht nicht dem vorherigen Wert
Tatsächlich sind Trigger Formeln, in denen die Überwachungsparameter (aktuell und gespeichert) als Variablen fungieren und die am Ausgang true / false ergeben.
Aktionen und Warnungen
Im Ereignisfall (Trigger) kann der Server eine Aktion ausführen. Senden Sie beispielsweise eine E-Mail-Benachrichtigung an eine bestimmte Adresse (" Problem: Host ist 5 Minuten lang nicht erreichbar "). Eine Aktion kann auch ausgeführt werden, wenn der Trigger in seinen ursprünglichen Zustand zurückkehrt (" Behoben: Host ist 5 Minuten lang nicht erreichbar "). Alle Ereignisse (Trigger Switching) werden serverseitig protokolliert.
Muster
Mit Zabbix können Sie Überwachungsregeln für einen einzelnen Host konfigurieren und eine Regelvorlage (Template) erstellen, die auf verschiedene Hosts angewendet werden kann:
Das Beispiel zeigt, dass die Vorlage "Template App SSH Service" eine Anwendung (Applications), einen Überwachungsparameter (Items) und einen Trigger (Trigger) beschreibt. Beschreibungen für Diagramme, Bildschirme, Erkennungsregeln und Webskripts sind ebenfalls verfügbar.
Festlegen der Aufgabe für das Plugin
Ausgangsposition
Zabbix selbst bietet ein eigenes Plugin zur Überwachung des Status von Redis an, aber auf meiner Serverversion (4.2.8) konnte ich es nicht verwenden (Plugin für Version 4.4 und höher). Es werden auch Lösungen von Drittanbietern angeboten (etwa ein Dutzend Optionen für verschiedene Versionen von Zabbix, es gibt nur die ersten drei auf dem Bild):
Jeder von ihnen hatte seine eigenen Vor- und Nachteile, musste hineinschauen, um zu wählen. Das Beste war meiner Meinung nach das Plugin Shakeeljaveed / zabbix-redis-userparamaters , das aus zwei Dateien bestand:
- README.md
- redis-userparameter.conf
Ich musste ein wenig "Stifte" arbeiten, aber an seinem Beispiel wurde etwas klarer, wie die Daten vom Agenten zum Server gelangen. Auf Vorschlag des Autors Javeed Shakeel wurde der Status von Redis alle 2 Minuten von der Krone auf die /tmp/redismetric :
*/2 * * * * /usr/bin/redis-cli info > /tmp/redismetric
Anschließend wurde jeder Überwachungsparameter vom Agenten mit den Tools des Betriebssystems selbst aus der /tmp/redismetric extrahiert. Anweisungen hierzu wurden in der Konfiguration des Zabbix-Agenten /etc/zabbix/zabbix_agent.conf.d/userparameter_redis.conf . So sieht beispielsweise die Anweisung zum Abrufen des Parameters used_memory (Speicherbelegung durch den Redis-Server) aus:
UserParameter=used_memory,grep -w 'used_memory' /tmp/redismetric | cut -d: -f2
Das heißt, in der /tmp/redismetric mit der Ausgabe von redis-cli INFO wird der String ( grep -w ... ) vom used_memory Schlüssel gesucht
used_memory:7153216
welches dann durch das Trennzeichen ":" in Spalten aufgeteilt wird ( cut -d: -f2 ). Am Ausgang erhält der Agent die Nummer 7153216 und weist sie dem Parameter used_memory .
Der Server muss weiterhin über die webbasierte Schnittstelle so konfiguriert werden, dass er regelmäßig Anforderungen an den Agenten sendet, um Daten mithilfe des Parameters used_memory zu empfangen. used_memory werden die Daten auf den in der Datenbank gespeicherten Server übertragen. Sie können damit Diagramme erstellen und Trigger erstellen, die auf Änderungen an diesem Parameter reagieren.
Zweck
Die Aufgabe der Statusüberwachung eines Systems besteht nicht nur in der Erfassung von Statistiken, sondern auch in der Warnung vor dem Auftreten von Situationen, die menschliches Eingreifen erfordern. Da ich mit Redis als unerfahrener Benutzer arbeite, musste ich nach Informationen suchen, auf welche "Gesundheits" -Parameter ich achten sollte und was sie bedeuten. Der würdigste Artikel lautete " 6 wichtige Redis-Überwachungsmetriken, die Sie beobachten müssen ". Nachdem ich es analysiert hatte, kam ich zu dem Schluss, dass ich, um vollkommen glücklich zu sein, Daten sammeln muss, um die folgenden Ereignisse zu erkennen:
- Speicherfragmentierung: used_memory_rss / used_memory> 1.5
- Niedrige Cachetrefferquote: (keyspace_hits) / (keyspace_hits + keyspace_misses) <0.8
- Abgelehnte Verbindungen: reject_connections> 0
- Ausgeschlossene Schlüssel: evicted_keys> 0
Ich wollte auch Statistiken über zusätzliche Parameter (Redis-Version, Betriebszeit usw.) sammeln. Wenn Sie eine allgemeine Vorstellung davon haben, wie die Daten vom Agenten erfasst und an den Server übertragen werden, kann Wishlist stark eingeschränkt sein. Als Ergebnis haben wir eine Liste von Parametern für die Überwachung von 12 Positionen erhalten.
Erstelle dein eigenes Plugin
Überwachungsoptionen
Das von mir analysierte Plugin ging von der Ausführung eines separaten Befehls aus, um einen separaten Parameter (Datenelement, Element) zu erhalten:
grep -w 'used_memory' /tmp/redismetric | cut -d: -f2
Das heißt, um Daten zu 12 Parametern zu erhalten, muss der Agent 12-mal verschiedene Befehlssätze ausführen. Und wenn ich Parameter überwachen muss, die mit einer Befehlskette schwer zu extrahieren sind und ein separates Shell-Skript oder ein vollwertiges Programm schreiben müssen? Für eine solche "Wunschliste" bietet Zabbix eine Variante mit abhängigen Datenelementen an. Im Wesentlichen bildet das Skript auf der Agentenseite einen Datensatz (z. B. im JSON-Format), der als Zeichenfolgenparameter an den Server übertragen wird. Dann werden auf der Serverseite die empfangenen Daten analysiert und einzelne Elementarparameter daraus extrahiert.
Hauptdatenelement
Ich habe das Hauptdatenelement redis.info Zeichenfolgentyps mit einer Aktualisierungsdauer von 1 Minute beschrieben, ohne den Änderungsverlauf zu speichern:
Vermutlich sollte auf der Agentenseite der folgende JSON generiert werden:
{ "version": "4.0.9", "uptime": 1897336, "used_memory": 1054943416, "used_memory_rss": 1138159616, "keyspace_hits": 75810274, "keyspace_misses": 13545949, "connected_clients": 15, "rdb_last_save_time": 1580126954, "total_connections_received": 1258614, "rejected_connections": 0, "expired_keys": 60270, "evicted_keys": 0 }
redis.info soll dieser Text als redis.info Datenelement an den Server redis.info , aber nicht gespeichert werden, sondern als Basis für andere Datenelemente (Überwachungsparameter) dienen.
Abhängiges Datenelement
Der redis.info.version hängt von redis.info und speichert seine Werte 90 Tage lang in der Datenbank. Die Häufigkeit der Parameterüberwachung ist abhängig vom Basiselement ( redis.info ):
Der redis.info.version Parameters " redis.info wird mithilfe von JSONPath-Anweisungen aus dem Wert "redis.info" abgerufen:
Ein ähnliches Schema beschreibt die übrigen abhängigen Datenelemente (Überwachungsparameter), die in Form von JSON übertragen werden. Hier ist ein Beispiel für die Beschreibung des numerischen Parameters redis.info.used_memory :
Alles ist ziemlich transparent, mit Ausnahme der Units und der Trend storage period . Ich habe den zweiten Punkt nicht verstanden, habe ihn standardmäßig verlassen und die Maßeinheiten werden in der Dokumentation erläutert. In diesem Fall wird der Wert von redis.info.used_memory in Bytes gemessen und im Webinterface auf Kilo / Mega / Giga /...-Bytes minimiert.
Die Formel zum Extrahieren eines Werts aus JSON lautet: JSONPath = $.used_memory
Berechnetes Datenelement
Um die Fragmentierung des Speichers zu berechnen, wird die Beziehung used_memory_rss / used_memory verwendet. Auf dieser Grundlage wird ein Auslöser bestimmt, der ausgelöst wird, wenn das Verhältnis 1,5 überschreitet. Zabbix hat einen berechneten Datenelementtyp:
Der Wert für den Parameter redis.info.used_memory_ratio jede Minute basierend auf den letzten Werten von zwei anderen Parametern ( redis.info.used_memory_rss und redis.info.used_memory ) redis.info.used_memory_rss und 90 Tage in der Datenbank gespeichert.
Auslöser
Hier ist ein Beispiel für einen Trigger, der ausgelöst wird, wenn der Speicher zu fragmentiert ist:
Nichts Ungewöhnliches außer dem Ausdrucksformat, das in der Änderungsformel für den Triggerstatus verwendet wird. Zabbix verfügt über einen Formularkonstruktor, den Sie verwenden oder in der Dokumentation / den Beispielen nachlesen können (die Liste der Trigger finden Sie über die Weboberfläche unter " Konfiguration / Vorlagen / $ {Vorlagenname} / Trigger ").
Ein Trigger kann auf beliebigen Datenelementen (Elementen) basieren, unabhängig von ihrem Typ (Haupt, Abhängig, Berechnet).
Agent-Setup
JSON-Generation
Um die Werte der Überwachungsparameter und die Bildung von JSON abzurufen, verwende ich dieses Shell-Skript:
Ich habe dieses Skript in der Datei /var/lib/zabbix/user_parameter/redis/get_info.sh auf dem Server mit Redis /var/lib/zabbix/user_parameter/redis/get_info.sh auf dem der Zabbix-Agent bereits installiert ist. Der Benutzer, unter dem der Zabbix-Agent zabbix (normalerweise zabbix ), muss über die Berechtigung verfügen, die Datei get_info.sh auszuführen.
userparameter_XXX.conf Datei
Auf der Agentenseite werden zusätzliche Überwachungsparameter in die userparameter_*.conf im Verzeichnis userparameter_*.conf . Daher habe ich die Datei /etc/zabbix/zabbix_agentd.d/userparameter_redis.conf mit folgendem Inhalt erstellt, damit der Agent herausfinden kann, wie Daten für den Parameter /etc/zabbix/zabbix_agentd.d/userparameter_redis.conf werden müssen:
UserParameter=redis.info,/var/lib/zabbix/user_parameter/redis/get_info.sh
Das heißt, um Daten zum Parameter redis.info muss redis.info Agent das Skript /var/lib/zabbix/user_parameter/redis/get_info.sh und das Ergebnis der Ausführung auf den Server übertragen.
Nach dem Neustart des Zabbix-Agenten ( sudo service zabbix-agent restart ) können Daten für den Parameter redis.info und an den Server gesendet werden.
Zusammenfassung
Zabbix zu verstehen, fiel mir (und kommt immer noch) ziemlich schwer. Trotzdem halte ich es für ein großartiges Werkzeug, besonders nachdem ich mir die Möglichkeit erarbeitet habe, einfach meine eigenen Überwachungsparameter (Datenelemente) hinzuzufügen. Im Großen und Ganzen fügen Sie dem Server mit dem Agenten ( userparameter_XXX.conf ) nur eine Datei hinzu, und userparameter_XXX.conf mit einem Shell-Befehl, um Daten zu erfassen und den Zabbix-Server so zu konfigurieren, dass er diese Daten über die Weboberfläche empfängt. Und das war's - Sie können Daten sammeln, Diagramme erstellen, Änderungen analysieren und einen Auslöser erstellen, der auf diese Änderungen reagiert.
Der Code für die Vorlage, die Datei userparameter_redis.conf und das Skript get_info.sh können im Projekt flancer32 / zabbix_plugin_redis angezeigt werden .
Vielen Dank an alle, die bis zum Ende gelesen haben und vor allem an diejenigen, die in der Publikation etwas Nützliches für sich gefunden haben.