Eine Software-Update-Prüfung wird jetzt standardmäßig zu neuen und bestehenden Installationen hinzugefügt - das Zabbix Frontend kommuniziert mit dem öffentlichen Zabbix-Endpunkt, um nach Updates zu suchen.

Die Informationen über verfügbare Zabbix-Softwareupdates werden in Reports -> System information und optional im System Information-Dashboard-Widget angezeigt.

Sie können die Software-Update-Prüfung deaktivieren, indem Sie AllowSoftwareUpdateCheck=0 in der Server-Konfiguration setzen.

Asynchrone Poller

Neue Poller-Prozesse wurden hinzugefügt, die mehrere Prüfungen gleichzeitig ausführen können:

agent poller
http agent poller
snmp poller (für walk[OID]- und get[OID]-Datenpunkte)

Diese Poller sind asynchron - sie können neue Prüfungen starten, ohne auf eine Antwort warten zu müssen, wobei die Parallelität bis zu 1000 gleichzeitige Prüfungen konfigurierbar ist.

Asynchrone Poller wurden entwickelt, weil synchrone Poller-Prozesse im Vergleich dazu immer nur eine Prüfung gleichzeitig ausführen können und die meiste Zeit mit dem Warten auf die Antwort verbringen. Dadurch konnte die Effizienz gesteigert werden, indem während des Wartens auf die Netzwerkantwort neue parallele Prüfungen gestartet werden, und genau das tun die neuen Poller.

Sie können asynchrone Agent-Poller starten, indem Sie den Wert von StartAgentPollers ändern - ein neuer Server/Proxy-Parameter. HTTP-Agent-Poller können entsprechend durch Ändern von StartHTTPAgentPollers gestartet werden. SNMP-Poller können entsprechend durch Ändern von StartSNMPPollers gestartet werden.

Die maximale Parallelität für asynchrone Poller (Agent, HTTP-Agent und SNMP) wird durch MaxConcurrentChecksPerPoller definiert.

Beachten Sie, dass nach dem Upgrade alle Agent-, HTTP-Agent- und SNMP-walk[OID]-Prüfungen zu asynchronen Pollern verschoben werden.

Im Rahmen der Entwicklung wurde die cURL-Funktion für persistente Verbindungen zu HTTP-Agent-Prüfungen hinzugefügt.

Browser monitoring

Ein neuer Datentyp - Browser item - wurde zu Zabbix hinzugefügt und ermöglicht die Überwachung komplexer Websites und Webanwendungen mithilfe eines Browsers. Browser items ermöglichen die Ausführung von benutzerdefiniertem JavaScript-Code, um browserbezogene Aktionen wie Klicken, Texteingabe, Navigieren durch Webseiten usw. zu simulieren.

Dieser Datenpunkt erfasst Daten über HTTP/HTTPS und implementiert teilweise den W3C-WebDriver-Standard mit Selenium Server oder einem einfachen WebDriver (z. B. ChromeDriver) als Test-Endpunkt.

Beachten Sie, dass die Unterstützung von Browser items derzeit experimentell ist.

Darüber hinaus fügt diese Funktion die Vorlage Website by Browser sowie neue Elemente zu Konfigurations-Export/Import, Zabbix Server/Proxy-Konfigurationsdateien, Timeouts und dem Befehlszeilen-Dienstprogramm zabbix_js hinzu. Weitere Informationen finden Sie unter Upgrade-Hinweise zu 7.0.0.

Proxy-Lastverteilung und Hochverfügbarkeit

Die Proxy-Lastverteilung wird in Zabbix durch die Einführung von Proxy-Gruppen implementiert. Proxy-Gruppen ermöglichen die automatische Verteilung von Hosts auf Proxies, die Neuausbalancierung der Proxy-Lastverteilung und Hochverfügbarkeit - wenn ein Proxy offline geht, werden seine Hosts sofort auf die anderen Proxies in der Gruppe verteilt.

Weitere Informationen finden Sie unter Proxy-Lastverteilung und Hochverfügbarkeit.

Proxy-Speicherpuffer

Für den Zabbix Proxy wurde ein Speicherpuffer entwickelt. Der Speicherpuffer ermöglicht es, neue Daten (Datenpunktwerte, Netzwerkerkennung, Host-Autoregistrierung) im Puffer zu speichern und an den Zabbix Server hochzuladen, ohne auf die Datenbank zuzugreifen.

In Installationen vor Zabbix 7.0 wurden die gesammelten Daten vor dem Hochladen an den Zabbix Server in der Datenbank gespeichert. Für diese Installationen bleibt dieses Verhalten nach dem Upgrade standardmäßig erhalten.

Für eine optimierte Leistung wird empfohlen, die Verwendung des Speicherpuffers auf dem Proxy zu konfigurieren. Dies ist möglich, indem der Wert von ProxyBufferMode von "disk" (fest codierter Standardwert für bestehende Installationen) auf "hybrid" (empfohlen) oder "memory" geändert wird. Außerdem muss die Größe des Speicherpuffers festgelegt werden (ProxyMemoryBufferSize-Parameter).

Im Hybridmodus ist der Puffer vor Datenverlust geschützt, indem nicht gesendete Daten in die Datenbank geschrieben werden, wenn der Proxy gestoppt wird, der Puffer voll ist oder die Daten zu alt sind. Sobald alle Werte in die Datenbank geschrieben wurden, verwendet der Proxy wieder den Speicherpuffer.

Im Speichermodus wird der Speicherpuffer verwendet, es gibt jedoch keinen Schutz vor Datenverlust. Wenn der Proxy gestoppt wird oder der Speicher überläuft, werden die nicht gesendeten Daten verworfen.

Der Hybridmodus (ProxyBufferMode=hybrid) wird seit Zabbix 7.0 für alle neuen Installationen verwendet.

Zusätzliche Parameter wie ProxyMemoryBufferSize und ProxyMemoryBufferAge definieren die Größe des Speicherpuffers bzw. das maximale Alter der Daten im Puffer.

Neue interne Datenpunkte wurden hinzugefügt, um den Speicherpuffer des Proxys zu überwachen.

JIT-Benutzerbereitstellung

Zuvor bereitgestellte Benutzer waren nur auf die während der Bereitstellung erstellten Medien beschränkt, ohne die Flexibilität, Eigenschaften wie Arbeitszeiten oder Schweregrade zu bearbeiten.

Jetzt steht für bereitgestellte Benutzer in Zabbix mehr Flexibilität zur Verfügung:

bereitgestellte Benutzermedien können deaktiviert/aktiviert werden;
bereitgestellte Medienfelder des Benutzers wie When active, Use if severity und Enabled können manuell bearbeitet werden;
zusätzliche Benutzermedien können für bereitgestellte Benutzer manuell hinzugefügt werden (zum Beispiel zusätzliche E-Mail-Adressen);
manuell hinzugefügte Benutzermedien können gelöscht werden (bereitgestellte Benutzermedien können nicht gelöscht werden).

Zusätzlich sind bei der Konfiguration der Zuordnung von Benutzermedien für die Bereitstellung nun Felder wie When active, Use if severity und Enabled verfügbar. Beachten Sie, dass Änderungen am Zuordnungsformular für den Benutzermedientyp nur für neue Medien wirksam werden, die während der Bereitstellung erstellt werden.

Konfigurierbare Timeouts pro Datenpunkt

Die Timeout-Konfiguration pro Datenpunkt ist jetzt für weitere Datenpunkt-Typen verfügbar (siehe unterstützte Datenpunkt-Typen). Zusätzlich zur Festlegung der Timeout-Werte auf Datenpunkt-Ebene ist es möglich, globale und Proxy-Timeouts für verschiedene Datenpunkt-Typen zu definieren.

Auf Datenpunkt-Ebene konfigurierte Timeouts haben die höchste Priorität. Standardmäßig werden globale Timeouts auf alle Datenpunkte angewendet; wenn jedoch Proxy-Timeouts festgelegt sind, überschreiben diese die globalen Timeouts.

Oracle DB veraltet

Die Unterstützung für Oracle als Backend-Datenbank wurde veraltet und wird voraussichtlich in zukünftigen Versionen vollständig entfernt.

JSON-Protokoll für passive Agent-Prüfungen

Ein JSON-basiertes Protokoll für passive Agent-Prüfungen wurde implementiert.

Zur Kompatibilität mit älteren Agenten wurde ein Fallback auf das alte Klartextprotokoll hinzugefügt. Wenn der Agent "ZBX_NOTSUPPORTED" zurückgibt, speichert Zabbix die Schnittstelle als altes Protokoll im Cache und wiederholt die Prüfung, indem nur der Klartext-Datenpunkt-Schlüssel gesendet wird.

Zabbix get kann jetzt mit einer neuen Option -P --protocol <value> ausgeführt werden, wobei "value" entweder ist:

auto - Verbindung über JSON-Protokoll herstellen, bei Bedarf auf Klartextprotokoll zurückfallen und erneut versuchen (Standard);
json - Verbindung über JSON-Protokoll-Schlüssel herstellen;
plaintext - Verbindung über Klartextprotokoll herstellen, wobei nur der Datenpunkt-Schlüssel gesendet wird.

Wenn ein Datenpunkt-Schlüssel nicht unterstützt wird, gibt Zabbix get den Exit-Code 1 zurück.

Vereinheitlichte Unified agent/agent2-Protokolle

Die Protokolle von Zabbix Agent und Agent 2 wurden vereinheitlicht, indem Zabbix Agent auf das Protokoll von Zabbix Agent 2 umgestellt wurde. Der Unterschied zwischen den Anfragen und Antworten von Zabbix Agent und Zabbix Agent 2 wird durch den Wert des Tags "variant" ausgedrückt ("1" - Zabbix Agent, "2" - Zabbix Agent 2).

Siehe auch: Passive und aktive Agent-Prüfungen.

Unterstützung flexibler/geplanter Intervalle in aktiven Prüfungen

Flexible/geplante Intervalle werden jetzt bei aktiven Prüfungen sowohl vom Zabbix Agent als auch vom Zabbix Agent 2 unterstützt (zuvor nur vom Zabbix Agent 2).

Automatisches Deaktivieren verlorener Ressourcen

Ressourcen, die durch die Low-Level-Discovery nicht mehr erkannt werden, können jetzt automatisch deaktiviert werden. Sie können sofort, nach einem festgelegten Zeitraum oder nie deaktiviert werden (siehe den neuen Parameter Verlorene Ressourcen deaktivieren in der Konfiguration der Erkennungsregel).

Verlorene Ressourcen (Hosts, Datenpunkte, Auslöser) werden durch ein Symbol in der Info-Spalte gekennzeichnet. Der Tooltip-Text enthält Details zu ihrem Status.

Im selben Zuge wurde der Parameter Aufbewahrungszeitraum für verlorene Ressourcen in Verlorene Ressourcen löschen umbenannt, mit den Optionen sofort löschen, nach einem festgelegten Zeitraum oder nie.

Senden von Daten an den Zabbix-Server über die Zabbix API

Bisher war das Senden bestimmter Daten an den Zabbix-Server mit dem Dienstprogramm Zabbix sender oder durch die Implementierung eines benutzerdefinierten JSON-basierten Kommunikationsprotokolls möglich, das dem in Zabbix sender verwendeten ähnelt.

Jetzt ist es auch möglich, Daten über das HTTP-Protokoll mithilfe der API-Methode history.push an den Zabbix-Server zu senden. Beachten Sie, dass der Empfang gesendeter Daten einen konfigurierten Trapper-Datenpunkt oder einen HTTP-Agent-Datenpunkt (mit aktiviertem Trapping) erfordert.

Darüber hinaus werden korrekte history.push-Operationen in Reports → Audit log protokolliert, das zusätzliche Filteroptionen bietet (eine neue Aktion Push und die Ressource History), und die API-Methode history.push ist bei der Konfiguration einer Benutzerrolle auch in der Allow/Deny list der API-Methoden verfügbar.

Skripte

Skriptausführung auf aktiven Agents

Es ist jetzt möglich, Skripte auf Agents auszuführen, die im aktiven Modus betrieben werden. Sobald die Skriptausführung durch eine Aktions-Operation oder eine manuelle Skriptausführung ausgelöst wird, wird der Befehl in die Konfiguration der aktiven Prüfungen aufgenommen und ausgeführt, sobald der aktive Agent ihn empfängt.

Manuelle Skripte werden zusammen mit dem Server-/Proxy-Timeout für die Skriptausführung an den aktiven Agent gesendet. Bitte erhöhen Sie das Standard-Timeout für die Skriptausführung auf dem Server/Proxy. Das Timeout muss höher sein als die Aktualisierungsfrequenz der aktiven Prüfung, andernfalls ist das Timeout bereits überschritten, bevor der aktive Agent das Skript empfängt und das Ergebnis zurückgeben kann.

Beachten Sie, dass ältere aktive Agents alle Remote-Befehle ignorieren, die in der Konfiguration der aktiven Prüfungen enthalten sind. Weitere Informationen finden Sie unter Passive and active agent checks.

Manuelle Benutzereingabe für Skripte

Die manuelle Benutzereingabe für Frontend-Skripte ermöglicht es, bei jeder Ausführung des Skripts einen benutzerdefinierten Parameter anzugeben. Dadurch entfällt die Notwendigkeit, mehrere ähnliche Benutzerskripte zu erstellen, die sich nur in einem einzelnen Parameter unterscheiden.

Beispielsweise möchten Sie während der Ausführung dem Skript eine andere Ganzzahl oder eine andere URL-Adresse übergeben.

So aktivieren Sie die manuelle Benutzereingabe:

verwenden Sie das Makro {MANUALINPUT} im Skript (Befehle, Skript, Skriptparameter), wo erforderlich; oder im URL-Feld von URL-Skripten;
aktivieren Sie in erweiterter Skriptkonfiguration die manuelle Benutzereingabe und konfigurieren Sie die Eingabeoptionen:

Wenn die Benutzereingabe aktiviert ist, wird vor der Skriptausführung ein Popup Manuelle Eingabe angezeigt, in dem der Benutzer aufgefordert wird, einen benutzerdefinierten Wert anzugeben. Der angegebene Wert ersetzt {MANUALINPUT} im Skript.

Je nach Konfiguration wird der Benutzer aufgefordert, einen Zeichenfolgenwert einzugeben oder den Wert aus einer Dropdown-Liste mit vordefinierten Optionen auszuwählen.

Leistung

Schnellere Reaktion auf Aktualisierungen des Host-Wartungszeitraums

Bisher wurden Wartungen nur jede Minute neu berechnet, was zu einer möglichen Verzögerung von bis zu 60 Sekunden beim Starten oder Beenden eines Wartungszeitraums führen konnte.

Jetzt werden Wartungen weiterhin jede Minute neu berechnet oder sofort, wenn der Konfigurationscache neu geladen wird und sich Änderungen am Wartungszeitraum ergeben haben.

Jede Sekunde prüft der Timer-Prozess, ob Wartungen basierend darauf gestartet oder beendet werden müssen, ob es nach der Konfigurationsaktualisierung Änderungen an den Wartungszeiträumen gibt. Die Geschwindigkeit beim Starten/Beenden von Wartungszeiträumen hängt daher vom Aktualisierungsintervall der Konfiguration ab (standardmäßig 10 Sekunden). Beachten Sie, dass Änderungen an Wartungszeiträumen die Einstellungen Aktiv seit/Aktiv bis nicht einschließen. Wenn außerdem ein Host/eine Hostgruppe zu einem bereits aktiven Wartungszeitraum hinzugefügt wird, werden die Änderungen erst vom Timer-Prozess zu Beginn der nächsten Minute aktiviert.

Schnellere Berechtigungsprüfungen

Berechtigungsprüfungen wurden durch die Einführung mehrerer Zwischentabellen zur Prüfung der Berechtigungen nicht privilegierter Benutzer erheblich beschleunigt.

Diese Tabellen speichern Hashes (SHA-256) von Benutzergruppen-Sets und Hostgruppen-Sets jeweils für jeden Benutzer/Host. Zusätzlich gibt es eine Berechtigungstabelle, die nur die zugänglichen Kombinationen von Benutzern und Hosts speichert, angegeben durch die Hash-IDs.

Diese Verbesserung beschleunigt das Laden von Frontend-Seiten mit vielen Berechtigungen (d. h. Hosts, Probleme) erheblich. Beachten Sie, dass Hashes und Berechtigungen für Super-Admin-Benutzer nicht berechnet werden.

Schnellere Ausführung von Auslöser-Aktionen

Die Ausführung von Operationen für Trigger action, Wiederherstellungsoperationen und Aktualisierungsoperationen auf dem Zabbix-Server erfolgt nun sofort (weniger als 100 Millisekunden) nach einer Änderung des Auslöserstatus, während Benutzer zuvor eine Latenz von bis zu 4 Sekunden erleben konnten.

Die Verringerung der Latenz wird durch die Implementierung von Mechanismen zur Interprozesskommunikation (IPC) zwischen mehreren processes ermöglicht (escalator und sein escalation-dispatch-Modul, escalator und alerter, preprocessing manager und history syncer).

Widgets

In der neuen Version wurden mehrere neue Widgets hinzugefügt, während die verfügbaren Funktionen anderer erweitert wurden. Darüber hinaus können Dashboard-Widgets jetzt miteinander verbunden werden und miteinander kommunizieren, wodurch Widgets und Dashboards dynamischer werden.

Gauge

Ein Gauge-Widget wurde zu den Dashboard-Widgets hinzugefügt und ermöglicht die Anzeige des Werts eines einzelnen Datenpunkts als Gauge. Weitere Informationen finden Sie unter Gauge.

Kreisdiagramm

Ein Pie chart-Widget wurde zu den Dashboard-Widgets hinzugefügt und ermöglicht die Anzeige von Werten ausgewählter Datenpunkte als:

Kreisdiagramm;
Ringdiagramm.


Kreisdiagramm.	Ringdiagramm.

Weitere Informationen finden Sie unter Pie chart.

Im Rahmen dieser Entwicklung wurde in der Widget-Konfiguration des Diagramms (Registerkarte Legend) ein Kontrollkästchen Show aggregation function hinzugefügt.

Honeycomb

Ein Honeycomb-Widget wurde zu den Dashboard-Widgets hinzugefügt. Es bietet eine dynamische und lebendige Übersicht über die überwachte Netzwerkinfrastruktur und die Ressourcen, wobei Hostgruppen, wie virtuelle Maschinen und Netzwerkgeräte, zusammen mit ihren jeweiligen Datenpunkten visuell als interaktive hexagonale Zellen dargestellt werden. Weitere Informationen finden Sie unter Honeycomb.

Top-Auslöser

Ein Widget Top-Auslöser wurde zu den Dashboard-Widgets hinzugefügt, mit dem sich die Auslöser mit der höchsten Anzahl an Problemen anzeigen lassen.

Weitere Informationen finden Sie unter: Top-Auslöser.

Item history und Plain text

Das neue Dashboard-Widget Item history hat das Widget Plain text ersetzt und bietet mehrere Verbesserungen.

Im Gegensatz zum Widget Plain Text, das nur die neuesten Daten des Datenpunkts in einfachem Text anzeigte, unterstützt das Widget Item History verschiedene Anzeigeoptionen für mehrere Datenpunkttypen (numerisch, Zeichen, Protokoll, Text und binär). Es kann beispielsweise Fortschrittsbalken oder Indikatoren anzeigen, Bilder für binäre Datentypen (nützlich für Browser-Datenpunkte) und Textwerte hervorheben (nützlich für die Überwachung von Protokolldateien).

Weitere Informationen finden Sie unter Item history. Einzelheiten zum Ersatz des Widgets Plain text finden Sie unter Upgrade-Hinweise für 7.0.0.

Host navigator und Item navigator

Die Widgets Host navigator und Item navigator wurden zu den Dashboard-Widgets hinzugefügt. Diese Widgets zeigen Hosts bzw. Datenpunkte basierend auf verschiedenen Filter- und Gruppierungsoptionen an und ermöglichen es, die in anderen Widgets angezeigten Informationen anhand des ausgewählten Hosts oder Datenpunkts zu steuern. Weitere Informationen finden Sie unter Host navigator und Item navigator.

Kommunikationsframework für Widgets

Dashboard-Widgets können jetzt miteinander verbunden werden und miteinander kommunizieren, wodurch Widgets und Dashboards dynamischer werden. Mehrere Widgets verfügen über Parameter, mit denen sie Konfigurationsdaten zwischen kompatiblen Widgets oder dem Dashboard austauschen können.

Diese Funktion führt die folgenden Änderungen ein:

Host groups, Hosts und Item-Parameter ermöglichen es Ihnen, entweder die jeweiligen Entitäten oder eine Datenquelle auszuwählen, die diese bereitstellt.
Der Parameter Enable host selection wurde durch den Parameter Override host ersetzt, mit dem Sie eine Datenquelle auswählen können, die Hosts bereitstellt.
Der Parameter Time period wurde mehreren Widgets hinzugefügt und ermöglicht es Ihnen, eine Datenquelle auszuwählen, die einen Zeitraum bereitstellt.
Der Parameter Map im Widget Map ermöglicht es, entweder eine Karte oder ein anderes Widget als Datenquelle für Karten auszuwählen.
Der Parameter Graph im Widget Graph (classic) ermöglicht es, entweder einen Graphen oder ein anderes Widget als Datenquelle für Graphen auszuwählen.

Je nach Widget und seinen Parametern kann die Datenquelle entweder ein kompatibles Widget aus demselben Dashboard oder das Dashboard selbst sein. Weitere Informationen finden Sie unter Dashboard widgets.

Informationen zu Änderungen an Standard-Vorlagen, die mit Zabbix ausgeliefert werden, finden Sie unter Template changes.

Zeiträume für die Aggregation in den Widgets "Datenpunktwert" und "Top-Hosts"

Zeiträume können jetzt in den Widgets Datenpunktwert und Top-Hosts konfiguriert werden.

Außerdem ist es jetzt möglich, im Widget "Datenpunktwert" für den gewählten Zeitraum einen aggregierten Wert anzuzeigen. Der aggregierte Wert kann wie folgt angezeigt werden:

Minimum
Maximum
Durchschnitt
Anzahl
Summe
Erster
Letzter

Diese neuen Funktionen sind nützlich, um Widgets zum Vergleich von Daten zu erstellen. In einem Widget können Sie beispielsweise den neuesten Wert anzeigen, während in einem anderen der Durchschnittswert für einen längeren Zeitraum angezeigt wird. Oder mehrere Widgets können für einen direkten Vergleich aggregierter Werte aus verschiedenen Zeiträumen in der Vergangenheit verwendet werden.

Erweiterte Widget-Verfügbarkeit auf Vorlagen-Dashboards

Bisher konnten Sie auf einem Vorlagen-Dashboard nur die folgenden Widgets erstellen:
Clock, Graph (classic), Graph prototype, Item value, Plain text, URL.

Jetzt unterstützen Vorlagen-Dashboards die Erstellung aller Widgets.

Jetzt ist es neben der Sortierung nach Datenpunktwert auch möglich, die Spalte Host name oder Text als Sortierspalte im Widget Top hosts festzulegen.

Erweiterte Funktionalität des Widgets zur Host-Verfügbarkeit

Das Widget Host availability ermöglicht jetzt die Anzeige von Hosts mit der Schnittstelle Zabbix agent (active checks). Ein weiterer Verfügbarkeitsstatus wurde hinzugefügt, nämlich Mixed. Dieser entspricht der Situation, in der mindestens eine Schnittstelle nicht verfügbar ist und mindestens eine weitere entweder verfügbar oder unbekannt ist. Außerdem wurde die Möglichkeit eingeführt, nur die Gesamtzahl der Hosts ohne Aufschlüsselung nach Schnittstellen anzuzeigen.

Variable Legendengröße im Graph-Widget

Das Graph-Widget unterstützt jetzt die Konfiguration einer variablen Anzahl von Legenden-Zeilen, die durch die Anzahl der konfigurierten Datenpunkte bestimmt wird.

Funktionen

Neue Funktionen

Für die Verwendung in Ausdrücken von Auslösern und berechneten Datenpunkten wurden neue Funktionen hinzugefügt:

jsonpath() - gibt das JSONPath-Ergebnis zurück;
xmlxpath() - gibt das XML-XPath-Ergebnis zurück.

Siehe auch: String-Funktionen

Aktualisierte Funktionen

Mehrere Funktionen wurden aktualisiert:

Aggregatfunktionen unterstützen nun auch nicht numerische Typen für Berechnungen. Dies kann beispielsweise bei den Funktionen count und count_foreach nützlich sein.
Die Aggregatfunktionen count und count_foreach unterstützen die optionalen Parameter operator und pattern, mit denen sich das Filtern von Datenpunkten genauer steuern lässt und nur Werte gezählt werden, die den angegebenen Kriterien entsprechen.
Alle foreach functions schließen nicht mehr unterstützte Datenpunkte nicht mehr in die Zählung ein.
Die Funktion last_foreach, die zuvor so konfiguriert war, dass sie das Zeitraummargument ignoriert, akzeptiert es nun als optionalen Parameter.
Der unterstützte Wertebereich für von prediction functions zurückgegebene Werte wurde erweitert, um dem Bereich des Datentyps double zu entsprechen. Jetzt kann die Funktion timeleft() Werte bis zu 1.7976931348623158E+308 akzeptieren, und die Funktion forecast() kann Werte im Bereich von -1.7976931348623158E+308 bis 1.7976931348623158E+308 akzeptieren.

Datenpunkte

Einheitlicher standardmäßiger Aufbewahrungszeitraum für Verlaufsdaten

Der standardmäßige Aufbewahrungszeitraum für die Speicherung von Datenpunkt-Verlaufsdaten wurde im Frontend und in der Datenbank auf 31 Tage vereinheitlicht. Diese Änderung betrifft die Konfigurationsformulare für Datenpunkt, Vorlagen-Datenpunkt und Datenpunkt-Prototypen sowie die Überschreibung des Aufbewahrungszeitraums für Verlaufsdaten in der Low-Level-Discovery.

Gleitkommawerte für Ganzzahl-Datenpunkte gekürzt

Wenn nun für einen vorzeichenlosen Ganzzahl-Datenpunkt ein Gleitkommawert empfangen wird, wird der Wert vom Dezimalteil abgeschnitten und als Ganzzahl gespeichert. Zuvor würde ein Gleitkommawert dazu führen, dass ein Ganzzahl-Datenpunkt nicht unterstützt wird.

Zählen von Zeilen im Windows-Ereignisprotokoll

Ein neuer eventlog.count-Datenpunkt wurde zu Zabbix Agent/Agent 2 unter Windows hinzugefügt. Dieser Datenpunkt gibt einen ganzzahligen Wert mit der Anzahl der Zeilen im Windows-Ereignisprotokoll basierend auf den angegebenen Parametern zurück.

Asynchrone SNMP-Anfragen für einzelne OIDs

Ein neues SNMP-Datenpunkt get[OID] wurde hinzugefügt, das es ermöglicht, einen einzelnen OID-Wert asynchron abzufragen.

Interne Datenpunkte

Interne Prüfungen werden jetzt von einem neuen Zabbix-Prozess internal poller auf Server/Proxy verarbeitet.

Zur Überwachung des Proxy-Speicherpuffers wurden interne Datenpunkte hinzugefügt:

zabbix[proxy_buffer,buffer,<mode>] - gibt die Nutzungsstatistiken des Proxy-Speicherpuffers zurück;
zabbix[proxy_buffer,state,changes] - gibt die Anzahl der Zustandsänderungen zwischen Festplatten-/Speicherpuffer-Modi seit dem Start zurück;
zabbix[proxy_buffer,state,current] - gibt den aktuellen Arbeitszustand zurück, in dem die neuen Daten gespeichert werden.

Die folgenden internen Datenpunkte wurden ebenfalls hinzugefügt:

zabbix[discovery_queue] - ermöglicht die Überwachung der Anzahl der Discovery-Prüfungen in der Warteschlange;
zabbix[vps,written] - ermöglicht die Überwachung der Gesamtzahl der in die Datenbank geschriebenen History-Werte.

Neue und aktualisierte Agent-Datenpunkte

Neue Datenpunkte wurden zu Zabbix agent/Agent 2 hinzugefügt:

Der Datenpunkt net.dns.perf gibt die Anzahl der Sekunden zurück, die auf eine Antwort von einem Dienst gewartet wurde, und misst dabei die Ausführung des Datenpunkts net.dns.
Der Zabbix agent 2-Datenpunkt net.dns.get gibt detaillierte Informationen zu DNS-Einträgen zurück.

Die folgenden Zabbix agent/Agent 2-Datenpunkte wurden aktualisiert:

Die Datenpunkte net.dns und net.dns.record akzeptieren bei Reverse-DNS-Abfragen nun den DNS-Namen im umgekehrten und nicht umgekehrten Format;
Die Datenpunkte proc.get im Modus "process" und "summary" geben unter Linux nun auch den PSS-Speicher (proportional set size) zurück;
Die Datenpunkte system.sw.packages und system.sw.packages.get werden nun unter Gentoo Linux unterstützt;
Der Datenpunkt system.hostname kann nun einen Fully Qualified Domain Name zurückgeben, wenn die neue Option fqdn im Parameter type angegeben ist;
Die Datenpunkte wmi.get und wmi.getall, die mit Zabbix agent 2 verwendet werden, geben nun JSON mit booleschen Werten zurück, die als Zeichenfolgen dargestellt werden (zum Beispiel "RealTimeProtectionEnabled": "True" statt des zuvor zurückgegebenen "RealTimeProtectionEnabled": true), um dem Ausgabeformat dieser Datenpunkte auf Zabbix agent zu entsprechen;
Der Zabbix agent 2-Datenpunkt oracle.ts.discovery gibt nun ein neues {#CON_NAME}-LLD-Makro mit dem Containernamen zurück;
Der Zabbix agent 2-Datenpunkt oracle.ts.stats verfügt über einen neuen Parameter conname, um den Namen des Ziel-Containers anzugeben. Das JSON-Format der zurückgegebenen Daten wurde aktualisiert. Wenn in den Schlüsselparametern kein tablespace, type oder conname angegeben ist, enthalten die zurückgegebenen Daten eine zusätzliche JSON-Ebene mit dem Containernamen, sodass zwischen Containern unterschieden werden kann.

Einfache Prüfungen

Das vmware.eventlog-Datenpunkt unterstützt jetzt optionales Filtern nach Schweregrad im dritten Parameter.

Das vmware.vm.discovery-Datenpunkt liefert jetzt auch Daten zu Netzwerkinterfaces virtueller Maschinen zurück. Diese Daten können verwendet werden, um benutzerdefinierte Host-Interfaces zu konfigurieren.

Das vmware.vm.net.if.discovery-Datenpunkt liefert jetzt auch ein Array von Netzwerkinterface-Adressen zurück.

Zu den folgenden Datenpunkten wurde ein neuer Parameter options hinzugefügt:

Mit diesem Parameter kann angegeben werden, ob umgeleitete Antworten als Host erreichbar oder Host nicht erreichbar behandelt werden sollen. Weitere Details finden Sie unter einfache Prüfungen.

Protokollierung doppelter SNMPv3 Engine IDs

Engine IDs in SNMPv3 werden als eindeutige Kennungen des Geräts verwendet. Manchmal sind Engine IDs auf mehreren Geräten aufgrund von Fehlkonfigurationen oder Werkseinstellungen identisch. Da die SNMP-Standards verlangen, dass Engine IDs eindeutig sind, werden Datenpunkte, die dieselbe Engine ID verwenden, in Zabbix nicht mehr unterstützt, was zu Verfügbarkeitsproblemen bei diesen Geräten führt.

Um die Fehlersuche bei solchen Problemen zu erleichtern, werden Informationen über SNMPv3-Geräte mit derselben Engine ID nun regelmäßig vom Zabbix Server protokolliert. Beachten Sie, dass die Erkennung doppelter Engine IDs in jedem SNMP-Poller separat erfolgt.

Dokumentationslink für jeden Standard-Datenpunkt

Jeder Standard-Datenpunkt verfügt jetzt über einen direkten Link vom Frontend zu seiner Dokumentationsseite.

Die Links befinden sich unter dem Fragezeichen-Symbol, wenn das Fenster zur Hilfe für den Datenpunkt aus dem Konfigurationsformular des Datenpunkts geöffnet wird (klicken Sie auf Select neben dem Feld für den Datenpunkt-Schlüssel).

Vorverarbeitung

Erweiterte Root-Cause-Behandlung für den nicht unterstützten Datenpunktstatus

Die Fehlerbehandlung im Fall eines Fehlers beim Abrufen eines Datenpunktwerts (und damit dessen Wechsel in den nicht unterstützten Zustand) bot bisher nicht die Möglichkeit, die Ursache oder die Laufzeitphase zu unterscheiden, in der der Prozess fehlgeschlagen ist. Alle Fehler mussten mit ein und derselben Option zur Fehlerbehandlung verarbeitet werden - entweder den Wert zu verwerfen, einen angegebenen Wert zu setzen oder eine angegebene Fehlermeldung zu setzen.

Es ist nun möglich, die Fehlermeldung mit einem regulären Ausdruck abzugleichen. Wenn die Fehlermeldung übereinstimmt (oder nicht übereinstimmt), kann festgelegt werden, wie der Fehlerfall verarbeitet werden soll. Beispielsweise kann eine bestimmte Fehlermeldung einem allgemeineren Fall zugeordnet werden, der von einem weiteren Vorverarbeitungsschritt geprüft und verarbeitet wird, oder ein vorübergehendes Problem (z. B. mit der Netzwerkverbindung) kann anders behandelt werden als ein eindeutiger Fehler beim Abrufen des Datenpunktwerts.

Mehrere Vorverarbeitungsschritte vom Typ Prüfung auf nicht unterstützten Wert können nun hinzugefügt werden. Beachten Sie, dass es am Ende der Pipeline zur Prüfung des nicht unterstützten Zustands des Datenpunkts nur einen Schritt für die Übereinstimmung mit "beliebigem Fehler" geben kann. Falls vorhanden, wird er aktiviert, wenn keine der spezifischen Prüfungen mit dem entsprechenden Muster übereinstimmt oder wenn eine (modifizierte) Fehlermeldung weitergereicht wurde - d. h. wenn kein Überschreiben durch "Wert verwerfen" oder "Wert setzen auf" wirksam wurde.

Siehe auch: Prüfung auf nicht unterstützten Wert

Verbesserte Benutzerfreundlichkeit für die Massenaktualisierung von Vorverarbeitungsschritten

Das bisherige Design des Formulars für die Massenaktualisierung von Datenpunkten war nicht ausreichend eindeutig, wenn die Aktualisierung von Vorverarbeitungsschritten Vorverarbeitungsschritte hinzufügen oder ersetzen würde. Im neuen Design wurden die Optionsfelder Ersetzen und Alle entfernen hinzugefügt, sodass für Benutzer klar ist, was sie als Ergebnis der Massenaktualisierung von Vorverarbeitungsschritten erwarten können:

Makros

Benutzer-Makros werden in Namen von Datenpunkten und Datenpunkt-Prototypen unterstützt

Benutzer-Makros werden jetzt in Namen von Datenpunkten und Datenpunkt-Prototypen unterstützt.

Beachten Sie, dass die Unterstützung von Benutzer-Makros in Namen von Datenpunkten/Datenpunkt-Prototypen in Zabbix 6.0 entfernt wurde. Jetzt wurde sie wiederhergestellt. Außerdem wird jetzt auch die Suche nach dem Namen des Datenpunkts mit aufgelösten Makros unterstützt, was zuvor nicht unterstützt wurde.

Der Name des Datenpunkts mit aufgelösten Makros wird in einer separaten Datenbanktabelle (item_rtname) gespeichert, die eine Erweiterung der Tabelle items ist. Für jeden Datensatz in der Tabelle items wird ein entsprechender item_rtname-Datensatz erstellt (außer für Datenpunkt-Prototypen, Erkennungsregel-Datenpunkte und Vorlagen-Datenpunkte). Der Name mit aufgelösten Makros ist auf 2048 Zeichen begrenzt.

Der Name des Datenpunkts mit aufgelösten Makros wird an allen Frontend-Positionen angezeigt, außer im Abschnitt Datenerfassung.

Ein neuer Serverprozess configuration syncer worker wurde hinzugefügt, der für das Auflösen und Synchronisieren der Benutzer-Makro-Werte in Namen von Datenpunkten verantwortlich ist.

Erweiterte Unterstützung von Makrofunktionen

Makrofunktionen werden jetzt mit allen Makrotypen unterstützt:

Makrofunktionen können an allen Stellen verwendet werden, die die aufgeführten Makros unterstützen. Dies gilt, sofern nicht ausdrücklich angegeben ist, dass nur ein Makro erwartet wird (zum Beispiel bei der Konfiguration von Host-Makros oder Filtern für Low-Level-Erkennungsregeln).

Geplante Berichte

Die Funktion geplante Berichte ist nicht mehr experimentell.

Mehrseitige Berichterstellung

Für Dashboards mit mehreren Seiten werden Berichte jetzt mit allen Seiten des Dashboards zurückgegeben, wobei jede PDF-Seite einer Dashboard-Seite entspricht. Zuvor war diese Funktionalität darauf beschränkt, nur die erste Dashboard-Seite zurückzugeben.

Benachrichtigungen

Unterstützung der Tag-Verarbeitung für interne Ereignisse

Die Verarbeitung von Tags, die vom webhook-Skript zurückgegeben werden, wird jetzt auch für interne Ereignisse unterstützt.

Außerdem werden die Makros {EVENT.TAGS.<tag name>}, {EVENT.TAGS}, {EVENT.TAGSJSON}, {EVENT.RECOVERY.TAGS}, {EVENT.RECOVERY.TAGSJSON} jetzt für Benachrichtigungen zu internen Ereignissen unterstützt.

Diese Änderungen ermöglichen die Verwendung von webhooks zum Aktualisieren oder Schließen eines externen Issues/Support-Tickets durch eine Wiederherstellungsbenachrichtigung für ein internes Ereignis.

Datenbanken

Auditlog in eine Hypertable auf TimescaleDB konvertiert

Die Tabelle auditlog wurde in Neuinstallationen in eine Hypertable auf TimescaleDB konvertiert, um von der automatischen Partitionierung nach Zeit (standardmäßig 7 Tage) und einer besseren Leistung zu profitieren.

Um bestehende Installationen erfolgreich zu aktualisieren, siehe TimescaleDB-Schema aktualisieren.

Siehe auch: Unterstützte TimescaleDB-Versionen

Separate Datenbanktabelle für Proxies

Proxy-Datensätze wurden aus der Tabelle hosts verschoben und werden jetzt in der neuen Tabelle proxy gespeichert.

Außerdem wurden Betriebsdaten von Proxies (wie letzter Zugriff, Version, Kompatibilität) aus der Tabelle host_rtdata verschoben und werden jetzt in der neuen Tabelle proxy_rtdata gespeichert.

Prozesse

Multithreading

Im Rahmen der Umstellung auf eine Multithread-Architektur wurden mehrere Änderungen vorgenommen:

Ein neuer Konfigurationsparameter wurde hinzugefügt: --with-stacksize. Mit diesem Parameter kann die vom System verwendete Standard-Thread-Stackgröße überschrieben werden (in Kilobyte).
Die Auflösung von Benutzermakros wurde vom Preprocessing-Manager zu den Preprocessing-Workern verschoben.

Absicherung der Serverumgebung

Es ist jetzt möglich, einige Zabbix-Funktionen einzuschränken, um die Sicherheit der Serverumgebung zu erhöhen:

Die Ausführung globaler Skripte auf dem Zabbix Server kann durch Setzen von EnableGlobalScripts=0 in der Serverkonfiguration deaktiviert werden. Bei Neuinstallationen ist die Ausführung globaler Skripte auf dem Zabbix Server standardmäßig deaktiviert.
Die HTTP-Authentifizierung für Benutzer kann durch Setzen von $ALLOW_HTTP_AUTH=false in der Konfigurationsdatei des Frontend (zabbix.conf.php) deaktiviert werden.
Das GSM-Modem für SMS-Benachrichtigungen kann jetzt im neuen Parameter SMSDevices angegeben werden, wodurch die Möglichkeit eingeschränkt wird, den Pfad des GSM-Modems über das Frontend falsch zu konfigurieren.

Validierung der Konfigurationsdatei

Die Möglichkeit zur Validierung der Konfigurationsdatei wurde zu den Wartungsbefehlen von Zabbix Server, Proxy, Agent, Agent 2 und Webdienst hinzugefügt. Die Validierung kann mit der Option -T --test-config durchgeführt werden. Bei erfolgreicher Validierung ist der Exit-Code "0"; andernfalls beendet sich die Komponente mit einem von null verschiedenen Exit-Code und einer entsprechenden Fehlermeldung. Warnungen (z. B. bei einem veralteten Parameter) beeinträchtigen den erfolgreichen Exit-Code nicht.

Erkennen von cURL-Bibliotheksfunktionen zur Laufzeit

Früher wurden cURL-Bibliotheksfunktionen zur Build-Zeit von Zabbix Server, Proxy oder Agent erkannt. Wenn cURL-Funktionen aktualisiert wurden, musste die jeweilige Zabbix-Komponente neu kompiliert werden, um sie nutzen zu können.

Jetzt ist nur noch ein Neustart erforderlich, damit aktualisierte cURL-Bibliotheksfunktionen in Zabbix verfügbar werden. Eine Neukompilierung ist nicht mehr erforderlich. Dies gilt für Zabbix Server, Proxy oder Agent.

Siehe auch die Upgrade-Hinweise.

Agent 2-Konfiguration

Puffergröße

Der Standardwert des Konfigurationsparameters BufferSize für Zabbix Agent 2 wurde von 100 auf 1000 erhöht.

Leere Werte zulässig

Leere Werte sind jetzt in pluginbezogenen Konfigurationsparametern auf Zabbix Agent 2 zulässig.

Festlegen des Starttyps des Windows-Agent-Dienstes

Die Option zum Festlegen des Starttyps des Zabbix Agent/agent 2-Windows-Dienstes (-S --startup-type) wurde hinzugefügt. Mit dieser Option kann konfiguriert werden, dass der Agent/agent 2-Dienst beim Windows-Start automatisch gestartet wird (automatic), nachdem die automatisch gestarteten Dienste ihren Start abgeschlossen haben (delayed), wenn er manuell durch einen Benutzer oder eine Anwendung gestartet wird (manual) oder dass der Dienst vollständig deaktiviert wird (disabled).

Bei der Installation des Windows-Agenten aus MSI ist der Standard-Starttyp unter Windows Server 2008/Vista und neueren Versionen nun delayed, sofern im Befehlszeilenparameter STARTUPTYPE nichts anderes angegeben ist. Dies verbessert die Zuverlässigkeit und Leistung des Zabbix Agent/agent 2-Windows-Dienstes, insbesondere bei Systemneustarts.

Unterstützung für den alten numerischen Typ eingestellt

Der alte Stil von Gleitkommawerten, der zuvor als veraltet markiert war, wird nicht mehr unterstützt, da numerische Werte mit erweitertem Bereich verwendet werden.

Vault-Präfix-Parameter zu Konfigurationsdateien hinzugefügt

Die Konfigurationsdateien zabbix_server.conf und zabbix_proxy.conf wurden um den neuen optionalen Parameter Vault Prefix ergänzt; zabbix.conf.php wurde um das optionale $DB['VAULT_PREFIX'] ergänzt, und setup.php wurde entsprechend aktualisiert.

Die Vault-Pfade für CyberArk und HashiCorp sind daher nicht mehr fest codiert, um Vault-Bereitstellungen mit nicht standardmäßigen Pfaden zu ermöglichen.

Discovery

Parallelität bei der Netzwerkerkennung

Bisher wurde jede Regel der Netzwerkerkennung von einem Discoverer-Prozess verarbeitet. Dadurch konnten alle Serviceprüfungen innerhalb der Regel nur sequenziell ausgeführt werden.

In der neuen Version wurde der Prozess der Netzwerkerkennung überarbeitet, um Parallelität zwischen Serviceprüfungen zu ermöglichen. Zusammen mit einer konfigurierbaren Anzahl von Discovery-Workern (oder Threads) wurde ein neuer Discovery-Manager-Prozess hinzugefügt.

Der Discovery-Manager verarbeitet Erkennungsregeln und erstellt für jede Regel einen Discovery-Job mit Aufgaben (Serviceprüfungen). Die Serviceprüfungen werden von den Discovery-Workern aufgenommen und ausgeführt. Nur Prüfungen mit derselben IP und demselben Port werden sequenziell geplant, da einige Geräte möglicherweise keine gleichzeitigen Verbindungen über denselben Port zulassen.

Ein neuer interner Datenpunkt zabbix[discovery_queue] ermöglicht die Überwachung der Anzahl der Discovery-Prüfungen in der Warteschlange.

Der Parameter StartDiscoverers bestimmt nun die Gesamtzahl der für die Erkennung verfügbaren Discovery-Worker. Der Standardwert von StartDiscoverers wurde von 1 auf 5 erhöht, und der Bereich von 0-250 auf 0-1000 erweitert. Die discoverer-Prozesse aus früheren Zabbix-Versionen wurden entfernt.

Zusätzlich:

Alle Serviceprüfungen werden jetzt asynchron ausgeführt, außer LDAP-Prüfungen;
Die Anzahl gleichzeitiger asynchroner Prüfungen pro Serviceprüfungstyp (oder die Anzahl verfügbarer Worker für alle synchronen Serviceprüfungen) ist jetzt im Frontend konfigurierbar (siehe Maximale gleichzeitige Prüfungen pro Typ). Dieser Parameter ist optional.
Die HTTP-Serviceprüfung war zuvor identisch mit der TCP-Prüfung. Jetzt erfolgt die HTTP/HTTPS-Prüfung über libcurl. Wenn Zabbix Server/Proxy ohne libcurl kompiliert wurde, funktionieren HTTP-Prüfungen weiterhin wie zuvor (d. h. als TCP-Prüfungen), HTTPS-Prüfungen jedoch nicht.
Fehler im Prozess der Netzwerkerkennung werden jetzt im Frontend angezeigt (unter Datenerfassung -> Erkennung), zum Beispiel:
- fping-Fehler;
- falsche SNMP-OID;
- falscher Makrowert für das Datenpunkt-Timeout;
- Fehler im Adressbereich.

Hinzufügen von Host-Tags während der Erkennung/Autoregistrierung

Für Erkennungs- und Autoregistrierungsereignisse sind jetzt zusätzliche Operationen verfügbar:

Host-Tags hinzufügen
Host-Tags entfernen

Freigabe erkannter Host-Gruppen

Low-Level-Discovery-Regeln können jetzt bereits erkannte und vorhandene Host-Gruppen mit Hosts verknüpfen, die von denselben Low-Level-Discovery-Regeln erstellt wurden. Dies betrifft Host-Gruppen, die zuvor von anderen Low-Level-Discovery-Regeln auf Grundlage der angegebenen Gruppenprototypen erkannt und erstellt wurden.

Connectors

Die Funktionalität Datenstreaming ist nicht mehr experimentell.

Selektive Daten streamen und Versuchsinvervalle konfigurieren

Beim Streamen von Datenpunktwerten von Zabbix an externe Systeme können Sie jetzt konfigurieren, welche Datenpunktwerte der Connector basierend auf ihrem Informationstyp streamen soll (numerisch (vorzeichenlos), numerisch (Gleitkomma), Zeichen usw.).

Darüber hinaus können Sie jetzt auch das Versuchsinvervall konfigurieren, um erfolglose Versuche beim Streamen von Datenpunktwerten oder Ereignissen zu vermeiden (z. B. wenn der HTTP-Endpunkt ausgelastet ist oder durch Rate-Limiting eingeschränkt wird) - also wie lange der Connector nach einem erfolglosen Versuch zum Streamen von Daten warten soll.

Die HTTP-Antwortcodes 201, 202, 203 und 204 werden von Connectors jetzt ebenfalls als Erfolg akzeptiert (zuvor nur 200).

Streamen von Daten an Apache Kafka

Ein neues Tool für das Streaming von Daten an externe Systeme - der Kafka-Connector für den Zabbix Server - ist jetzt verfügbar. Der Kafka-Connector ist ein schlanker Server, der in Go geschrieben wurde und dazu dient, Datenpunktwerte und Ereignisse von einem Zabbix Server an einen Kafka-Broker weiterzuleiten.

Vorlagen

Für neue Vorlagen und Änderungen an bestehenden Vorlagen siehe Änderungen an Vorlagen.

Frontend

Multi-Faktor-Authentifizierung

Multi-Faktor-Authentifizierung (MFA) mit der Time-Based One-Time Password-(TOTP)- oder Duo Universal Prompt-Authentifizierungsmethode kann jetzt für die Anmeldung bei Zabbix verwendet werden und bietet eine zusätzliche Sicherheitsebene über Benutzername und Passwort hinaus.

US-Zeitformat

Zeit- und Datumsanzeigen im Frontend entsprechen nun dem US-Standard für Zeit- und Datumsanzeige, wenn die Standardsprache des Frontends (en_US) verwendet wird.

Before	Now

Klonen vereinfacht

Früher war es möglich, Hosts, Vorlagen und Karten mit Klonen und Vollständigem Klonen zu versehen.

Jetzt wurde die Option Klonen entfernt, und die Option Vollständiges Klonen wurde in Klonen umbenannt, wobei weiterhin die gesamte bisherige Funktionalität von Vollständigem Klonen erhalten bleibt.

Symbole durch Schriftarten ersetzt

Alle Symbole im Frontend wurden von Symbolbild-Sheets auf Schriftarten umgestellt.

Modale Formulare

Mehrere Frontend-Formulare werden jetzt in modalen (Popup-)Fenstern geöffnet:

Konfiguration der Netzwerkerkennungsregel;
Konfiguration des globalen Skripts;
Konfiguration der Ereigniskorrelation;
Konfiguration des Moduls;
Konfiguration des Medientyps;
Konfiguration der Vorlage;
Konfiguration von Auslöser und Auslöserprototyp;
Konfiguration von Datenpunkt und Datenpunktprototyp.

Einklappbare erweiterte Konfiguration

Die Kontrollkästchen für Erweiterte Konfiguration, die für die Anzeige erweiterter Konfigurationsoptionen zuständig sind, wurden durch einklappbare Blöcke ersetzt (siehe zum Beispiel Connector-Konfiguration, Service-Konfiguration, Clock-Widget-Konfiguration usw.). Dies verbessert die Benutzererfahrung, da das Einklappen dieser Blöcke und das Speichern der Konfiguration die konfigurierten erweiterten Optionen nicht mehr auf ihre Standardwerte zurücksetzt.

Verbesserter Menüabschnitt für Top-Auslöser

Der Menüabschnitt zum Anzeigen der Top-Auslöser heißt jetzt Top 100 triggers. Es wurde die Möglichkeit hinzugefügt, Auslöser nach Problemname und Tags zu filtern. Außerdem wird für jeden Auslöser jetzt die Anzahl der erkannten Probleme statt der Anzahl der Statusänderungen angezeigt.

Erhöhte Zeichenbegrenzung für Konfigurationsfelder

URL-Felder

Die Zeichenbegrenzung für alle URL-Felder beträgt jetzt 2048 Zeichen. Dies umfasst jetzt: Tile URL für Einstellungen im Zusammenhang mit geografischen Karten, Frontend URL für die Konfiguration verschiedener Frontend-Parameter, URLs für Netzwerkkarten und Netzwerkkartenelemente, URL A-C für Felder der Host-Inventarisierung, sowie URL für das URL-Dashboard-Widget.

Authentifizierungsfelder

Die Zeichenbegrenzung für die Authentifizierungsfelder User/User name und Password beträgt jetzt 255 Zeichen. Dies gilt für die Konfiguration der HTTP-Authentifizierung für HTTP agent-Datenpunkte, Web-Szenarien und Connectoren, sowie für die Konfiguration der Authentifizierung für einfache Prüfungen, ODBC-Überwachung, SSH-Prüfungen, Telnet-Prüfungen, und JMX-Überwachung.

Datenpunkt- und Vorverarbeitungstest-Ergebnisabschneidung

Beim Testen von Datenpunkten oder Testen von Vorverarbeitungsschritten werden von einem Host abgerufene Werte und Testergebnisse nun auf eine maximale Größe von 512 KB gekürzt, wenn sie an das Frontend gesendet werden. Beachten Sie, dass Daten, die größer als 512 KB sind, weiterhin vollständig vom Server verarbeitet werden.

Host-Dashboard-Tabs

Alle konfigurierten Host-Dashboards für den ausgewählten Host werden nun als Tabs unter der Seitenüberschrift der Host-Dashboards angezeigt und ersetzen das bisherige Dropdown-Menü in der oberen rechten Ecke. Dies ermöglicht einen einfachen Wechsel zwischen verschiedenen Host-Dashboards und verbessert die Navigation durch die Überwachungsdaten.

Audit-Log

In Administration → Audit-Log können Sie jetzt die Audit-Protokollierung von Low-Level-Discovery-, Netzwerk-Discovery- und Autoregistrierungsaktivitäten aktivieren oder deaktivieren, die vom Server (Systembenutzer) ausgeführt werden.

Der Standardzeitraum für die Speicherung von Audit-Log-Einträgen, bevor diese vom Housekeeper gelöscht werden, wurde von 365 Tagen auf 31 Tage geändert.

Filter für die neuesten Daten

In Monitoring → Neueste Daten werden der Unterfilter und die Daten standardmäßig nicht mehr angezeigt, wenn der Filter nicht gesetzt ist.

Wenn Sie von früheren Zabbix-Versionen aktualisieren, siehe auch: Upgrade-Hinweise für 7.0.0.

Mindest erforderliche PHP-Version

Die mindestens erforderliche PHP-Version wurde von 7.4.0 auf 8.0.0 angehoben.

Umbenannte Elemente

Einige Parameter von Dashboard-Widgets mit der Bezeichnung Tags wurden zur besseren Verständlichkeit umbenannt: Item tags (für das Widget Data overview), Scenario tags (für das Widget Web monitoring); Problem tags (für die Widgets Graph, Problem hosts, Problems, Problems by severity und Trigger overview);
Der Aktionslink zum Bearbeiten des Karteninhalts, der in der Kartenliste im Abschnitt Monitoring → Maps verfügbar ist, wurde von Constructor in Edit umbenannt;
Die Felder zum Festlegen der Aufbewahrungszeiträume für History und Trends in den Konfigurationsformularen für item und item prototype wurden umbenannt;
In der Konfiguration des Widgets Top hosts wurden die Felder Order column und Host count in Order by und Host limit umbenannt, um ihre Funktionen besser zu beschreiben.
In der Konfiguration des Widgets Graph wurde das Feld legend Display min/max/avg in Display min/avg/max umbenannt, und die Felder host pattern und item pattern im data set wurden in host patterns und item patterns umbenannt.
In den Einstellungen des User profile wurde die Registerkarte Messaging in Frontend notifications umbenannt; dort wurde auch die Option Frontend messaging in Frontend notifications umbenannt.

Verschiedenes

Die Symbole des Hauptmenüs wurden aktualisiert;
Meldungen, die das Fehlen von Daten oder nicht gesetzte Filter anzeigen (in Widgets oder Popup-Filtern ohne anzuzeigende Daten), wurden aktualisiert. Zusätzlich wurde die Fußzeile "Displaying 0 of 0 found" entfernt, wenn keine Daten anzuzeigen sind oder wenn das Filtern (oder die Verwendung der globalen Suche) zu keinen Treffern führt.
Die Versionsnummern von Zabbix Frontend und Zabbix Server sind jetzt auf der Seite mit Systeminformationen sichtbar;
Alle Aktionen, in denen der Medientyp verwendet wird, werden jetzt in der Liste der Medientypen angezeigt (Spalte Used in actions). Zuvor wurden Aktionen, bei denen die Option Send only to in der Aktionskonfiguration auf "All" gesetzt war, nicht in der Spalte Used in actions des Medientyps berücksichtigt;
Im Abschnitt Latest data wurde eine neue Filteroption hinzugefügt: Sie ermöglicht jetzt das Filtern von Datenpunkten nach ihrem Status (unterstützt/nicht unterstützt);
Im Abschnitt Problems wurde eine neue Filteroption Acknowledgement status hinzugefügt: Sie ermöglicht jetzt das Filtern von Problemen nach ihrem Status (nicht bestätigt/bestätigt/von mir bestätigt);
Standardmäßige Schaltfläche zum Schließen von Fenstern wurde zu Popup-Fenstern hinzugefügt, die für die Konfiguration und Massenaktualisierung von Kartenelementen und Formen vorgesehen sind;
Die Konfiguration von Berechtigungen für Benutzergruppen und Tags zum Filtern sichtbarer Probleme wurde verfeinert. Jetzt ist es möglich, mehrere Host-/Vorlagengruppen gleichzeitig auszuwählen, um ihnen dieselben Berechtigungen zuzuweisen.
Das Snoozing globaler Benachrichtigungen in einem Browser wird diese nun in allen Browsern/Geräten snoozen, auf denen der Benutzer angemeldet ist.
Der Parameter Override host im Widget Item value wurde für eine bessere Benutzerfreundlichkeit vor den Abschnitt Advanced configuration verschoben.

Plugins

Ember+

Ein neues Plugin für die direkte Überwachung von Ember+ durch Zabbix Agent 2 wurde hinzugefügt.

Weitere Informationen finden Sie unter:

Installation

Separate Installationspakete für RHEL-Derivate

Für die Versionen 8 und 9 von AlmaLinux, CentOS Stream, Oracle Linux und Rocky Linux sind dedizierte Installationspakete verfügbar. Zuvor wurden einzelne Installationspakete für RHEL und RHEL-basierte Distributionen bereitgestellt. Jetzt werden separate Pakete für RHEL und jedes der oben genannten Derivate verwendet, um potenzielle Probleme mit binärer Inkompatibilität zu vermeiden.

Unterstützung für ARM64/AArch64

ARM64/AArch64-Installationspakete sind jetzt für Debian, RHEL 8, 9 und deren Derivate sowie für SLES/OpenSUSE Leap 15 verfügbar.

What’s next?

6 Was ist neu in Zabbix 7.0.1

Docs

5 Was ist neu in Zabbix 7.0.0

AGPL-3.0-Lizenz

Software-Update-Prüfung