Zabbix 7.0 ist die erste LTS-Linie seit 6.0 und bringt die sichtbarste Änderung seit Jahren: ein neu gebautes Frontend, eine effizientere Erfassungs-Engine und ein natives SLA-System. Bei imaxe haben wir all das in einer produktionsreifen AMI auf Ubuntu 24.04 neu verpackt, mit unserem SQS-Reader, der neu geschrieben wurde, um die neuen APIs zu nutzen.
Wenn du bereits eine unserer Zabbix-6.0-AMIs betreibst, sagt dir diese Anleitung, was dein Team beim Aktualisieren gewinnt und wie du es tust, ohne auch nur einen Punkt Verlauf zu verlieren.
Die AMI Zabbix 7.0 LTS ist im AWS Marketplace bereits in den 7 üblichen kommerziellen Regionen verfügbar. 6.0 LTS bleibt bis 2027-02 gepflegt, es besteht also keine Eile bei der Migration.
Ein Frontend, das sich endlich modern anfühlt #
Die Änderung, die man beim Einloggen am meisten bemerkt. Die Dashboards unterstützen jetzt mehrseitige Widgets mit automatischer Rotation, ideal für NOC-Bildschirme, und die Navigation wurde abgeflacht: weniger Klicks bis zu einem konkreten Problem.
- Widgets für top hosts, Gauge und Torten neu gestaltet, mit konfigurierbaren Farbschwellen.
- Verbesserter Kiosk-Modus für Wandpanels, mit unabhängiger Aktualisierung pro Widget.
- Pro Benutzer gespeicherte Filter, die zwischen Sitzungen erhalten bleiben.
Natives SLA, ohne Verrenkungen #
Bisher bedeutete das Berechnen eines anständigen SLA in Zabbix triggers als Hilfsmittel und manuelle Berechnungen. 7.0 führt einen erstklassigen SLA-Dienst ein: du definierst das Ziel, die Servicefenster und die geplanten Ausfallzeiten, und Zabbix erledigt den Rest.
Wir sind vom Pflegen einer parallelen Tabellenkalkulation dazu übergegangen, die SLA-Einhaltung im selben Panel wie die übrigen Metriken zu haben. Allein das rechtfertigt schon das Update.
Wartungsfenster ausschließen
Die Berechnung berücksichtigt die Wartungszeiträume, sodass ein geplanter Neustart deine Verfügbarkeit nicht belastet. Es wird einmal konfiguriert und gilt für alle zugeordneten Dienste.
Die triggers als Hilfsmittel, die du in 6.0 für SLA verwendet hast, werden nicht von selbst konvertiert. Notiere deine aktuellen Ziele, um sie mit dem neuen Dienst neu aufzubauen.
Neu geschriebener SQS-Reader #
Unsere Auto-Scaling-Integration liest Auto-Scaling-Ereignisse aus einer SQS-Queue, um verschwindende Instanzen abzumelden. In 7.0 haben wir sie neu geschrieben, um den asynchronen Client zu nutzen und Batches zu verarbeiten, wodurch die Abmelde-Latenz von Minuten auf Sekunden sinkt.
Die Konfiguration ändert sich nicht: sie lebt weiterhin in /etc/zabbix/zabbix_ami.yml. Wenn du von 6.0 kommst, ist deine Datei unverändert kompatibel.
$ imaxe status zabbix-sqs-reader
→ Version 3.0.1 (async) · Queue verbunden
→ letzter Batch: 4 Nachrichten in 0.8s
$ journalctl -u zabbix-sqs-reader -n 20 --no-pagerWie man von 6.0 migriert #
Wir empfehlen, zu migrieren, indem du eine neue Instanz mit der AMI 7.0 startest und die Daten überträgst, statt in situ zu aktualisieren. Das ist sicherer und lässt dir einen Rückweg.
- Starte die AMI Zabbix 7.0 LTS in derselben Region und einem gleichwertigen Instanztyp.
- Exportiere die Datenbank der 6.0-Instanz und stelle sie in der neuen wieder her — das Schema wird beim ersten Start aktualisiert.
- Kopiere
/etc/zabbix/zabbix_ami.ymlund deine benutzerdefinierten Templates. - Überprüfe Agenten und Alerts 24–48 h lang parallel, bevor du die EIP umziehst.
Das enthaltene Werkzeug imaxe-zabbix-migrate automatisiert den Dump, das Laden und die Schema-Prüfung. Wir dokumentieren es Schritt für Schritt auf der AMI-Produktseite.
Lohnt es sich? #
Wenn du in den Dashboards lebst oder SLA berichten musst, ist 7.0 ein klarer Sprung. Wenn dein 6.0 läuft und du kein SLA nutzt, besteht keine Eile: wir halten es bis 2027 gepatcht und auditiert. In jedem Fall ist die neue AMI bereit, sobald du es bist.