Unser Team freut sich sehr, die Nachricht zu teilen, dass das Open-Source-Monitoringsystem veröffentlicht wurde. !
Ist Version 4.2 die Antwort auf die große Frage nach dem Leben, dem Universum und dem Monitoring insgesamt? Lassen Sie uns das herausfinden!
Zur Erinnerung: Zabbix ist ein vielseitiges System zur Überwachung der Leistung und Verfügbarkeit von Servern, Netzwerk- und Ingenieurausrüstung, Anwendungen, Datenbanken, Virtualisierungssystemen, Containern, IT-Diensten und Webdiensten.
Zabbix implementiert den vollständigen Zyklus von der Datensammlung über deren Verarbeitung und Analyse bis hin zur Speicherung dieser Daten, der Visualisierung und dem Versand von Benachrichtigungen unter Verwendung von Eskalationsregeln. Das System bietet auch flexible Erweiterungsmöglichkeiten für die Datensammlung und Benachrichtigung sowie Automatisierungsmöglichkeiten über die API. Eine einheitliche Web-Oberfläche ermöglicht eine zentrale Verwaltung der Monitoring-Konfigurationen und die Zuweisung von Zugriffsrechten an verschiedene Benutzergruppen. Der Code des Projekts wird unter Lizenz frei verteilt. .
Zabbix 4.2 ist die neue nicht LTS-Version mit einer verkürzten Unterstützung. Für Nutzer, die einen längeren Lebenszyklus von Softwareprodukten anstreben, empfehlen wir die LTS-Versionen wie 3.0 und 4.0.
Lassen Sie uns also über die Neuheiten und wesentlichen Verbesserungen der Version 4.2 sprechen:
Mehr offizielle Plattformen
Zusätzlich zu den bereits bestehenden offiziellen Paketen bieten wir auch neue Builds für an:
- RaspberryPi, Mac OS/X, SUSE Enterprise Linux Server 12
- MSI für den Windows-Agenten
- Docker-Images
Integrierte Unterstützung von Prometheus zur Anwendungsüberwachung
Zabbix kann Daten auf verschiedene Arten (Push/Pull) aus unterschiedlichen Datenquellen sammeln. Dazu gehören JMX, SNMP, WMI, HTTP/HTTPS, RestAPI, XML Soap, SSH, Telnet, Agenten und Skripte sowie andere Quellen. Und jetzt freuen wir uns über die Unterstützung von Prometheus!
Genauer gesagt war das Sammeln von Daten aus Prometheus-Exportern bereits vorher möglich, dank des Datentyp-Elements HTTP/HTTPS und regulären Ausdrücken.
Die neue Version ermöglicht die maximale Effizienz im Umgang mit Prometheus dank der integrierten Unterstützung der Abfragesprache PromQL. Die Verwendung von abhängigen Metriken erlaubt es, Daten besonders effizient zu sammeln und zu verarbeiten: Man fragt einmal die Daten ab und verteilt sie anschließend auf die benötigten Metriken.
Wir erhalten den Wert einer bestimmten Metrik.
Es ist wichtig zu beachten, dass die niedrigstufige Erkennung jetzt gesammelte Daten verwenden kann, um Metriken automatisch zu erstellen. In diesem Fall wandelt Zabbix die gesammelten Daten in das JSON-Format um, mit dem sich sehr komfortabel arbeiten lässt.
Wir finden Metriken mit einem Filter in der Abfragesprache PromQL.
Derzeit gibt es mehr als von Drittanbieterdiensten und -anwendungen mit Hilfe von Zabbix. Die Unterstützung von Prometheus wird es ermöglichen, eine Vielzahl von Anwendungen hinzuzufügen, die offizielle oder von der Gemeinschaft unterstützte Prometheus-Exporter haben. Dies umfasst die Überwachung beliebter Dienste, Container und Cloud-Ressourcen.
Effektives Hochfrequenz-Monitoring
Wollen wir Probleme so schnell wie möglich erkennen? Natürlich, keine Frage! Oft führt dieser Ansatz dazu, dass wir die Geräte zu häufig abfragen und Daten sammeln müssen, was die Überwachungssysteme stärker belasten kann. Wie können wir das vermeiden?
Wir haben einen Throttling-Mechanismus in den Vorverarbeitungsregeln implementiert. Throttling ermöglicht es uns im Wesentlichen, wiederholte Werte zu überspringen.
Angenommen, wir überwachen den Zustand einer kritischen Anwendung. Jede Sekunde überprüfen wir, ob unsere Anwendung funktioniert oder nicht. Dabei fließt ein kontinuierlicher Datenstrom aus 1 (funktionsfähig) und 0 (nicht funktionsfähig) in Zabbix ein. Beispielsweise: 1111111111110001111111111111…
Wenn in unserer Anwendung alles in Ordnung ist, erfolgt im Zabbix ein Datenstrom aus lauter Einsen. Müssen diese verarbeitet werden? Eigentlich nicht, denn uns interessiert nur der Zustandswechsel der Anwendung. Wir wollen nicht so viele Daten sammeln und speichern. Mit Throttling können wir Werte überspringen, wenn sie identisch mit dem vorherigen sind. Am Ende erhalten wir nur Daten über Zustandsänderungen, wie 01010101… Das ist ausreichend, um Probleme zu erkennen!
Übersehene Werte ignoriert Zabbix einfach, sie werden nicht in der Historie aufgezeichnet und beeinflussen die Trigger nicht. Aus der Sicht von Zabbix existieren übersehene Werte nicht.
Wiederholte Werte ignorieren
Super! Jetzt können wir Geräte sehr häufig abfragen und Probleme sofort erkennen, ohne unnötige Informationen in der Datenbank zu speichern.
Und wie steht es mit den Grafiken? Die werden doch leer sein aufgrund der fehlenden Daten! Und wie kann man feststellen, ob Zabbix Daten sammelt, wenn die meisten dieser Daten übersehen werden?
Darüber haben wir auch nachgedacht! Zabbix bietet eine weitere Art des Throttlings an, das Throttling mit Kontrollpunkten (throttling with heartbeat).
Wir überprüfen jede Minute, ob die Metrik aktiv ist.
In diesem Fall wird Zabbix, trotz des kontinuierlichen Datenflusses, mindestens einen Wert im angegebenen Zeitintervall speichern. Wenn die Daten einmal pro Sekunde gesammelt werden und das Intervall auf eine Minute eingestellt ist, verwandelt Zabbix den sekündlichen Datenstrom in einen minutenbasierten. Es ist leicht zu erkennen, dass dies zu einer 60-fachen Verdichtung der gesammelten Daten führt.
Jetzt sind wir sicher, dass die Daten gesammelt werden, die Funktion des Triggers nodata() funktioniert und die Grafiken in Ordnung sind!
Validierung der gesammelten Daten und Fehlerbehandlung
Keiner von uns möchte fehlerhafte oder unzuverlässige Daten sammeln. Beispielsweise wissen wir, dass der Temperatursensor Daten im Bereich von 0°C bis 100°C zurückgeben sollte, und alle anderen Werte sollten als fehlerhaft betrachtet und/oder ignoriert werden.
Jetzt ist dies möglich durch die in die Vorverarbeitung integrierten Validierungsregeln, die die Übereinstimmung oder Nichtübereinstimmung mit regulären Ausdrücken, Wertbereichen, JSONPath und XMLPath überprüfen.
Jetzt können wir die Fehlerreaktion steuern. Wenn die Temperatur außerhalb des Bereichs liegt, können wir diesen Wert einfach ignorieren, einen Standardwert festlegen (zum Beispiel 0 °C) oder eine eigene Fehlermeldung definieren, wie „Sensor defekt“ oder „Batterie wechseln“.
Die Temperatur muss zwischen 0 und 100 liegen, alles andere wird ignoriert.
Ein gutes Beispiel für die Nutzung von Validierung ist die Möglichkeit, Eingabedaten auf das Vorhandensein einer Fehlermeldung zu überprüfen und diesen Fehler für die gesamte Metrik festzulegen. Diese Funktionalität ist sehr nützlich, wenn Daten von externen APIs abgerufen werden.
Jegliche Datentransformation mit JavaScript.
Wenn uns die integrierten Preprocessing-Regeln nicht ausreichen, bieten wir jetzt die volle Freiheit mit der Verwendung beliebiger Skripte in JavaScript!
Nur eine Zeile Code, um Fahrenheit in Celsius umzuwandeln.
Dies eröffnet unbegrenzte Möglichkeiten zur Verarbeitung eingehender Daten. Der praktische Nutzen dieser Funktionalität besteht darin, dass wir jetzt keine externen Skripte mehr benötigen, die wir für Datenoperationen verwendet haben. Jetzt kann alles mit JavaScript erledigt werden.
Jetzt sind Datenumwandlungen, Aggregationen, Filter, arithmetische und logische Operationen und vieles mehr möglich!
Wir extrahieren nützliche Informationen aus dem Output von Apache mod_status!
Wir testen die Vorverarbeitung
Jetzt müssen wir nicht mehr raten, wie unsere komplexen Vorverarbeitungsszenarien funktionieren. Es gibt eine praktische Überprüfung der Funktionsweise der Vorverarbeitung direkt aus der Benutzeroberfläche!
Wir verarbeiten Millionen von Metriken pro Sekunde!
Bis Zabbix 4.2 wurde die Vorverarbeitung ausschließlich vom Zabbix-Server durchgeführt, was die Möglichkeiten der Verwendung von Proxys zur Lastverteilung einschränkte.
Seit Version Zabbix 4.2 erhalten wir eine unglaublich effiziente Lastskalierung durch die Unterstützung der Vorverarbeitung auf Proxy-Seite. Jetzt übernehmen die Proxys diese Aufgabe!
In Kombination mit Throttling ermöglicht dieser Ansatz ein hochfrequentes, skalierbares Monitoring und Millionen von Prüfungen pro Sekunde, ohne den zentralen Zabbix-Server zu belasten. Proxys verarbeiten riesige Datenmengen, wobei nur ein kleiner Teil durch Throttling zum Zabbix-Server gelangt, der um ein bis zwei Größenordnungen geringer ist.
Einfacheres Low-Level-Discovery
Wir erinnern daran, dass das Low-Level-Discovery (LLD) ein äußerst leistungsstarker Mechanismus zur automatischen Erkennung jeglicher Ressourcen für das Monitoring (Dateisysteme, Prozesse, Anwendungen, Dienste usw.) ist und auf deren Basis automatisch Datenelemente, Trigger, Netzwerknodes und andere Objekte erstellt. Dies spart unglaublich viel Zeit, vereinfacht die Konfiguration und ermöglicht die Verwendung einer Vorlage für Netzwerknodes mit unterschiedlichen Ressourcen zur Überwachung.
Das Low-Level-Discovery erforderte zuvor einen speziell formatierten JSON-Input. Damit ist jetzt Schluss!
Zabbix 4.2 ermöglicht die Nutzung von beliebig gestalteten JSON-Daten für Low-Level Discovery (LLD). Warum ist das wichtig? Es erlaubt, ohne Skripte z.B. mit externen APIs zu kommunizieren und die erhaltenen Informationen zur automatischen Erstellung von Netzwerknoten, Datenelementen und Triggern zu verwenden.
In Kombination mit der Unterstützung von JavaScript eröffnet dies fantastische Möglichkeiten zur Erstellung von Vorlagen für den Umgang mit verschiedenen Datenquellen wie z.B. Cloud-APIs, Anwendungs-APIs, Daten im XML-, CSV-Format und vielen weiteren Formaten.
Verknüpfung von JSON mit Prozessinformationen aus LLD
Die Möglichkeiten sind wirklich grenzenlos!
Unterstützung für TimescaleDB
Was ist TimescaleDB? Es handelt sich um ein gewöhnliches PostgreSQL plus ein Erweiterungsmodul von der TimescaleDB-Entwicklergruppe. TimescaleDB verspricht eine bessere Leistung durch effizientere Algorithmen und Datenstrukturen.
Ein weiterer Vorteil von TimescaleDB ist die automatische Partitionierung von Historientabellen. TimescaleDB steht für Geschwindigkeit und einfache Wartung! Allerdings muss ich anmerken, dass unser Team bisher noch keinen ernsthaften Leistungsvergleich mit herkömmlichem PostgreSQL durchgeführt hat.
Derzeit ist TimescaleDB ein relativ junges und schnell wachsendes Produkt. Bitte vorsichtig verwenden!
Einfaches Tag-Management
Während Tags früher nur auf Trigger-Ebene verwaltet werden konnten, ist das Tag-Management jetzt viel flexibler. Zabbix unterstützt Tags für Vorlagen und Netzwerkgeräte!
Alle gefundenen Probleme erhalten Tags nicht nur für den Trigger, sondern auch für das Netzwerkgerät sowie für die Vorlagen dieses Netzwerkgeräts.
Tags für Netzwerkgeräte festlegen
Flexiblere automatische Registrierung
Zabbix 4.2 ermöglicht das Filtern von Netzwerkgeräten nach Namen mithilfe von regulären Ausdrücken. Dies ermöglicht die Erstellung verschiedener Entdeckungs-Szenarien für unterschiedliche Gruppen von Netzwerkgeräten. Besonders nützlich, wenn komplexe Benennungsregeln für Geräte verwendet werden.
Flexiblere Netzwerkerkennung
Eine weitere Verbesserung betrifft die Benennung von Netzwerkgeräten. Es gibt jetzt die Möglichkeit, Gerätenamen bei der Netzwerkerkennung zu steuern und den Gerätenamen aus dem Wert einer Metrik abzuleiten.
Diese Funktionalität ist besonders wichtig, insbesondere bei der Netzwerkerkennung mit SNMP und dem Zabbix-Agent.
Automatisch zugewiesener Hostname des Netzwerks als sichtbarer Name
Überprüfung der Funktionsfähigkeit von Benachrichtigungsmethoden
Jetzt können Sie direkt über die Web-Oberfläche eine Testnachricht an sich selbst senden, um zu überprüfen, ob die Benachrichtigungsmethode funktioniert. Diese Funktionalität ist besonders nützlich zur Überprüfung von Zabbix-Integrationen mit verschiedenen Benachrufungs-, Aufgaben- und anderen externen Programmen sowie APIs.
Fernüberwachung von Infrastrukturkomponenten in Zabbix
Die Möglichkeit zur Fernüberwachung interner Metriken des Zabbix-Servers und -Proxys (Leistungs- und Funktionsmetriken der Zabbix-Komponenten) wurde hinzugefügt.
Wozu dient das? Diese Funktionalität ermöglicht es, die internen Metriken von Servern und Proxys aus der Ferne zu überwachen. So können Probleme schnell erkannt und gemeldet werden, selbst wenn die Komponenten überlastet sind oder beispielsweise der Proxy eine große Menge an nicht gesendeten Daten hat.
Unterstützung des HTML-Formats für E-Mail-Nachrichten
Jetzt sind wir nicht mehr auf einfachen Text beschränkt und können schöne E-Mail-Nachrichten gestalten dank der Unterstützung des HTML-Formats. Es ist Zeit, HTML + CSS zu lernen!
Nachrichten sind selbst bei minimalem Einsatz von HTML leichter zu erfassen.
Zugriff auf externe Systeme über Netzwerkkarten.
Es gibt jetzt Unterstützung für eine Reihe neuer Makros in benutzerdefinierten URLs, um die Integration von Karten mit externen Systemen zu verbessern. Damit können Sie mit einem oder zwei Klicks auf das Netzwerknoten-Icon beispielsweise ein Ticket im Task-System öffnen.
Mit einem Klick öffnen wir ein Ticket in Jira.
Die Erkennungsregel kann ein abhängiges Datenelement sein.
Warum ist das wichtig, fragen Sie sich? Es ermöglicht die Nutzung von Daten der Hauptmetrik sowohl für die Erkennung als auch für die direkte Datensammlung. Beispielsweise wird im Fall der Datensammlung über den Prometheus-Exporter ein HTTP-Abfrage gesendet, und Zabbix nutzt sofort die erhaltenen Informationen für alle abhängigen Datenelemente: die Metrikwerte und die Regeln für die grundlegende Erkennung.
Neue Methode zur Visualisierung von Problemen auf Karten.
Es gibt Unterstützung für animierte GIFs auf Karten zur besseren Sichtbarkeit von Problemen.
Problematische Geräte sind deutlicher erkannt worden.
Wir extrahieren Daten aus HTTP-Headern im Web-Monitoring.
Im Web-Monitoring gibt es jetzt die Möglichkeit, Daten aus dem empfangenen HTTP-Header auszuwählen.
Dies ermöglicht die Erstellung von mehrstufigen Szenarien für das Web-Monitoring oder das Monitoring von Drittanbieter-APIs unter Verwendung des in einem der Schritte erhaltenen Authentifizierungstokens.
Wir extrahieren AuthID aus dem HTTP-Header.
Zabbix Sender nutzt alle IP-Adressen.
Zabbix Sender sendet jetzt Daten über alle IP-Adressen aus dem Parameter ServerActive der Konfigurationsdatei des Agents.
Neuer praktischer Filter in der Trigger-Konfiguration.
Die Seite zur Konfiguration von Triggern verfügt jetzt über einen erweiterten Filter, um Trigger einfach und schnell nach festgelegten Kriterien auszuwählen.
Wir wählen Trigger aus, die zum K8S-Service gehören.
Wir zeigen die exakte Zeit an.
Hier ist alles einfach: Jetzt zeigt Zabbix die genaue Zeit an, wenn Sie mit der Maus über das Diagramm fahren.
Weitere Neuerungen.
- Ein vorhersehbarerer Algorithmus zur Änderung der Anordnung von Widgets im Dashboard wurde implementiert.
- Die Möglichkeit, Parameter von Prototypen von Datenelementen massenhaft zu ändern.
- IPv6-Unterstützung für DNS-Prüfungen: „net.dns“ und „new.dns.record“.
- Der Parameter „skip“ wurde für die Prüfungen „vmware.eventlog“ hinzugefügt.
- Der Fehler beim Ausführen des Preprocessing-Schrittes umfasst die Schritt-Nummer.
Wie kann ich ein Update durchführen?
Für den Wechsel von früheren Versionen ist lediglich die Installation (Server und Proxys) sowie einer neuen Benutzeroberfläche erforderlich. Zabbix wird das Upgrade der Datenbank automatisch durchführen. Es ist keine Installation neuer Agenten erforderlich.
Wir bieten kostenlose Webinare für diejenigen an, die mehr über Zabbix 4.2 erfahren und Fragen an das Zabbix-Team stellen möchten.
Vergessen wir nicht den beliebten der Zabbix-Community, wo man jederzeit Beratung und Antworten auf Fragen in russischer Sprache von erfahreneren Kollegen erhalten kann – und manchmal sogar direkt von den Zabbix-Entwicklern. Für Anfänger empfehlen wir die .
Nützliche Links
—
—
—
Quelle: habr.com
