💨 🔁 ❎ Wie wir Zabbix aktualisiert haben ☝🏼 👩‍👦‍👦 🍧

Bild

Warum lieben wir Prometheus ? Er hat eine Konfiguration - er hat geschaut und alles ist klar, das Programm macht das, was ihr gesagt wurde. Sie können Überwachungseinstellungen automatisieren, in VCS speichern und den Befehl überprüfen. Verengte Ihre MR , arbeitete Pipeline, eine neue Konfiguration auf Prometheus angewendet. Im Allgemeinen IaC in seiner ganzen Pracht.

Apropos Prometheus. Verwenden Sie es für Ihre Eiseninfrastruktur? Also verwenden wir nicht.

Wie viele, die schon lange überwachen und über „nackte“ Hardware verfügen, verwenden wir Zabbix , das sich übrigens auf dieser Hardware befindet. Leider sind Zabbix und IaC im Moment nichts miteinander zu tun. Zabbix kann entweder manuell oder über die API konfiguriert werden.

Hintergrund

Im Oktober 2018 wurde Zabbix-4.0 veröffentlicht - eine neue LTS- Niederlassung. Mitte März planten wir ein Upgrade unserer Installation von Version 3.4 darauf.

Es gab fast keine besonderen Probleme mit 3.4:

Manchmal funktionierte ein LLD irgendwo nicht und das Unmögliche geschah, was unklar ist, wie man eine vom Entwickler nicht unterstützte Version debuggt
Der Speicher der HTTP-Abzieher floss ständig - wodurch ein sorgfältig konfiguriertes System die Überwachung festnagelte und erneut startete. Das Problem wurde durch eine anständige Menge an Serverspeicher maskiert. Das Problem ist bekannt und dokumentiert .

Und in 4.0 gab es interessante Funktionen wie native HTTP-Elemente und Serviceperioden, die nicht für den gesamten Host gelten.

Und wo ist es zu sehen, auf einer irrelevanten Version der Überwachung zu sitzen, nicht einmal auf LTS? Wir müssen auf dem Laufenden bleiben.

Darüber hinaus wurde bei der Planung des Updates ein interessantes Detail herausgefunden: Der Fortschritt steht nicht still, Sie können schnellere Autos zu einem niedrigeren Preis nehmen. Dabei habe ich in mehreren Projekten von Kollegen einen Weg gefunden, den ohnehin schon unnötigen Hoster-Service einzusparen. Wie sie sagen, haben wir es erfolgreich eingegeben.

Stirn Update

Es ist nicht besonders kompliziert, den zabbix jetzt zu aktualisieren. Bestellen Sie einen Server, konfigurieren Sie ihn und führen Sie eine Kopie der Datenbank zusammen. Legen Sie Überwachungspakete ab und zeigen Sie ihnen die Basis, führen Sie Zabbiks aus - und er wird alles für Sie selbst aktualisieren und alle Migrationen durchführen. Ja, Sie wissen wahrscheinlich, wie einfach das Zabbix-Upgrade geworden ist.

Insgesamt dauerte die Datenbankmigration etwa 15 Minuten und auch ohne großen Missbrauch. Und alles scheint in Ordnung zu sein. Huh? Egal wie! Trotz der Tatsache, dass die IP des neuen Servers nicht in den weißen Listen der Agenten aufgeführt ist und nur Daten von wenigen Testhosts sammelt, geschieht das Unmögliche immer noch auf diesem Server.

Ich muss sagen, dass die Entwickler von Zabbix ihr Wort halten - Version 4.2 wird zu diesem Zeitpunkt unterstützt. Nachdem wir im Projekt-Tracker gesprochen haben, stellen wir fest, dass der Grund für das Unmögliche darin besteht, dass es nicht mit der erwarteten Struktur einer der Datenbanktabellen übereinstimmt.

Vage Zweifel schleichen sich ein. Es sei daran erinnert, dass historisch gesehen die „dicksten“ Zabbix-Datenbanktabellen partitioniert wurden. Zunächst einmal aus Leistungsgründen, um Ihren Lieblings-Zabbix-Kallus irgendwie zu vertuschen - das Löschen historischer Daten im RDBMS . Wir vergleichen die Strukturen aller Tabellen in einer Zeile in einer frisch aktualisierten Datenbank und einer Kontrolldatenbank, die vom Server selbst von Grund auf neu erstellt wurde. Die Befürchtungen wurden bestätigt. Zusätzlich zum Fehlen einiger Konstanten in der Datenbank sind in vielen Tabellen viele digitale Spalten vom falschen Typ.

Das heißt, wir haben kein Basisschema, das von den Entwicklern unterstützt wird, sondern unsere eigene „Gabel“. Eine andere Art von Spaltendaten ist möglicherweise:

andere metrische Speicherkosten
unterschiedliche Genauigkeit von Zahlen
unterschiedliche Abtast- / Aufzeichnungsgeschwindigkeit von Metriken

Zum Besseren denken? Es ist zweifelhaft. Nach früheren Erfahrungen mit technischem Support und Zabbix-Entwicklern können sie DBMS optimieren.

Und diese Art von Spaltendaten ist möglich, aber schwierig und langwierig zu ändern. Und ohne lange Ausfallzeiten ist dies nicht möglich. Ohne Erfolgsgarantien, ohne zukünftige Unterstützung durch den Entwickler. Brauche einen anderen Weg.

Und Zabbix hat es. Denn im April 2019 kommt zabbix-4.2 heraus

Die zweite Annäherung an das Projektil

Das Hauptmerkmal von 4.2 ist für uns die Unterstützung der sofort einsatzbereiten Partitionierung mit TimescaleDB . Nachdem wir mit den Vertretern von Zabbix gesprochen und uns mit den Ergebnissen des Testens des technischen Supports für diese Funktion ( Übersetzung auf dem Hub) vertraut gemacht haben, beschließen wir, die Installation mit timescaledb zu testen und basierend auf den Ergebnissen eine Entscheidung über den Übergang zu treffen. Genauer gesagt: Für einige Zeit werden alle Überwachungsdaten parallel zur alten und zur neuen Version geschrieben. Und dann wechseln wir einfach den DNS-Eintrag.

Mit diesem Ansatz können Sie natürlich keine historischen Daten und Trends speichern - die neue Datenbank wird von Grund auf neu gefüllt. Aber werden sie wirklich gebraucht? Die Geschichte ist nur hier und jetzt wichtig, sie wird sich ziemlich schnell wieder ansammeln (siehe den gleichen Prometheus). Nur der unbestrittene Nutzen von Trends für die Kapazitätsplanung bleibt bestehen. In jedem Fall bleibt das Archiv mit den bereits gesammelten Daten bei uns (mit Blick auf die Zukunft - es war für einige Kunden nützlich). Ein weiteres Merkmal der Timescaledb-Unterstützung in zabbix ist, dass einzelne Perioden der Verlaufs- / Trendspeicherung nicht mehr gültig sind.

Wir haben Kunden, die darauf bestehen, alle gesammelten Daten um jeden Preis „ewig“ zu speichern. Wir können ihnen anbieten, die Installation / Unterstützung einer separaten Überwachungsinstallation mit bestimmten Einstellungen in Betracht zu ziehen. Unsere Hauptaufgabe besteht darin, den stabilen Betrieb der Projekte / Server der Kunden sicherzustellen und gleichzeitig akzeptable Kosten für die Dienste aufrechtzuerhalten, einschließlich der Überwachung.

Insgesamt sind für die Migration folgende Schritte erforderlich:

Installieren und konfigurieren Sie eine zweite Überwachungsinstallation
Holen Sie sich alles wie in der ersten Installation
Wechseln!

Klingt einfach, oder? Das erste ist in der Tat nicht sehr schwierig, da wir während des vorherigen Ansatzes eine Rolle für die Installation eines zabbix-Servers geschrieben haben. Es reicht aus, nur die Konfiguration hochzuladen. Das dritte Element sieht ebenfalls einfach aus: Wechseln Sie zum DNS, und alle zabbiks-Agenten, Proxys, API-Clients und Live-Benutzer erhalten die neue Version. Aber wie macht man den zweiten Punkt?

Zuerst haben wir einen naiven Ansatz versucht. Importiert aus der aktuellen Überwachung einige der am häufigsten verwendeten Vorlagen. Unter Verwendung der bereits geschriebenen Skripte für die Arbeit mit der API haben wir in der neuen Überwachung dieselben Projekte wie in der aktuellen gestartet, Änderungen durch die SCM- Systeme übertragen und die IP des neuen Computers dem Paketfilter und den Anweisungen Server / ServerActive- Agenten hinzugefügt. Es hat sogar funktioniert - viele Hosts haben begonnen, sich in zwei Überwachungen gleichzeitig zu registrieren, eine neue hat ihnen Vorlagen zugewiesen und parallel zur aktuellen Datenerfassung begonnen.

Leider ist dies genau der naive Migrationsansatz, der nur für den Test geeignet ist. Die resultierende Last (in nvps ) konnte nicht mit der aktuellen Installation verglichen werden und war um Größenordnungen niedriger. Es ist verständlich. In unserem Fall ist die Überwachung buchstäblich die jahrelange Arbeit vieler Menschen und Skripte, die Quintessenz der Erfahrung bei der Durchführung heterogener Projekte.

Wie wäre es beispielsweise mit manuell aufgelösten Benutzern und ihren Kennwörtern, die beim Erstellen von Projekten zufällig generiert werden, Überwachungsvorlagen, die auf Hosts hängen (mit ihren benutzerdefinierten Makrowerten), manuell erstellten Elementen, komplexen Bildschirmen, Diagrammen, Dashboards, Serviceperioden und Proxys? All dies und noch viel mehr muss für eine reibungslose Migration übertragen werden.

Glücklicherweise verfügt der zabbix über eine integrierte Funktionalität zum Exportieren / Importieren von Objekten - auch über die API verfügbar. Leider deckt es nicht mehr als die Hälfte aller vorhandenen Einrichtungen ab. Und der Code für die Verwendung muss ebenfalls geschrieben werden. Im Allgemeinen können Sie die Konfiguration eines Zabbiks nicht einfach in einen anderen importieren.

Oder ist es möglich?

Hier erinnert sich das Gehirn hilfreich an die Aufgabe aus dem Rückstand, dass es schön wäre, die Speicherung des Überwachungskonfigurationsverlaufs mit externen Mitteln zu organisieren. Leider ist dies ein wunder Punkt von Zabbix. Mit Bezug auf den Artikel über den Hub und das Repository mit Code. Aber es gibt Nuancen:

Der Code exportiert nicht alle Überwachungsobjekte in lesbare YAML-Dateien (insbesondere nicht alles, was wir benötigen).
Der Code unterstützt das Importieren von Objekten nicht

Glücklicherweise gibt es Leute, die die Projektsprache (Python) ein wenig kennen und Erfahrung mit der Zabbix-API haben. Das einzige Geschäft besteht darin, Objekte aus vorgefertigten YAML-Dumps zu importieren. Für wie lange, kurz, aber nach drei Wochen Arbeit und anderthalb hundert Einsätzen war eine Gabel für unsere Zwecke durchaus geeignet. Eigentlich ist für dessen Präsentation der gesamte Artikel geschrieben:

https://github.com/centosadmin/zabbix-review-export-import

Was wurde getan:

Unterstützung für viele neue Objekte hinzugefügt
Das Format des YAML-Exports der meisten vorhandenen Objekte wurde geändert, damit sie importiert werden können
Es wurde die Möglichkeit hinzugefügt, die meisten exportierten Objekte zu importieren
Es wurden eingeschränkte Funktionen zum Konvertieren von Objekten zwischen verschiedenen Versionen von zabbix hinzugefügt (wie in unserem Fall).

Der Import wird fast ausschließlich durch die Erstellung neuer Objekte unterstützt. Wenn ein Objekt vorhanden ist, wird es nicht geändert. Dies ermöglichte es uns, die Komplexität des Codes zumindest in einigen Frameworks beizubehalten, Zeit zu sparen und die Arbeitsgeschwindigkeit kühl zu erhöhen - beim Importieren von Tausenden von Objekten. Die Verwendung des Imports ist sehr einfach:

./zabbix-import.py /path/to/file.yaml

(Es wird davon ausgegangen, dass die Zielüberwachungsparameter in den Umgebungsvariablen angegeben sind. Weitere Informationen finden Sie in der Ausgabe --help. )

Im Allgemeinen können Sie eine beliebige Anzahl von YAML-Eingabedateien angeben - und alle werden verarbeitet. Angesichts der Tatsache, dass es viele Abhängigkeiten zwischen Objekten gibt, ist es sinnvoller, Objekte typweise zu importieren, beginnend mit den einfachsten und grundlegendsten. Wenn Sie ein Objekt aus einer Datei importieren, ist es möglicherweise sinnvoll, seinen Typ explizit anzugeben, um den Import ein wenig zu beschleunigen. Es werden nicht alle Caches geladen, sondern nur die erforderlichen.

Daher wurden in unserem Hitlab zwei Repositorys mit regelmäßig aktualisierten YAML-Dumps von zwei Überwachungsversionen angezeigt, der aktuellen und der neuen. Und natürlich die Möglichkeit, fast jedes Überwachungsobjekt jederzeit wiederherzustellen.

Kontinuierliche Überwachung der Bereitstellung und Migration selbst

Als Ergebnis kamen wir zu dem Schluss, dass das Gitlab planmäßig eine Pipeline im Repository der neuen Überwachung startet, die Schritt für Schritt hierarchisch einen Objekttyp nach dem anderen aus der alten Überwachung importiert. Dies ermöglichte es uns, die überwiegende Mehrheit der Objekte zu importieren und unseren Administratorteams Zeit zu geben, um die aufgetretenen Probleme ruhig zu beheben - und sie haben sich im Laufe der Jahre nicht so sehr angesammelt. "Zusätzliche" Objekte wurden nicht gelöscht.

Das Problem mit Benutzerkennwörtern - sie werden ebenfalls exportiert / importiert, aber während der Erstellung wird ein zufälliges Kennwort zugewiesen - könnte behoben werden, indem der SQL-Speicherauszug der Tabelle mit den Anmeldeinformationen der aktuellen Überwachung in SQL-Anweisungen konvertiert wird, um die richtigen Kennwörter in der neuen Überwachung festzulegen.

Um im Parallelbetrieb keinen doppelten Teil der Aufgaben zu erhalten, wurden alle Aktionen in der neuen Überwachung sofort deaktiviert und nicht mehr gelöscht.

Somit war der Wechsel ziemlich einfach und führte zu folgenden Punkten:

Löschen Sie alle Hosts in der neuen Überwachung (hierfür werden einige Skripte über die API geschrieben).
Ziehen Sie SCMs, um die zabbix-Proxy-Version zu aktualisieren und die Proxys auf einen neuen Server zu wechseln
Warten Sie auf den Import von Hosts aus dem Speicherauszug der alten Überwachung
DNS-Einträge wechseln

(Plan zur Vereinfachung verkürzt)

Was weiter?

Natürlich ist der Code nicht perfekt und nicht besonders schön. Es wird nicht alles importiert, insbesondere gibt es Probleme mit einigen Vorlagen - suchen Sie im Code nach FIXME . Aber das hat uns gereicht. Vielleicht ist diese Gabel für jemand anderen nützlich. Eine logische Erweiterung ist die Entwicklung einer ähnlichen Operation des Terraform- Dienstprogramms, wenn die Zielüberwachung vollständig auf die Form reduziert wird, die beispielsweise durch ein Verzeichnis mit YAML-Dumps angegeben wird. Einschließlich der Reduzierung bestehender Einrichtungen auf die gewünschte Form.

Auf diese Weise können Sie ruhig auf die "native" HA- Unterstützung in zabbix warten, da zwei Server vorhanden sind und die Einstellungen automatisch synchronisiert werden. Jetzt müssen Sie ein Replikat, Proxys und Skripte behalten.

Camo kommt?

Nach dem Studium der Materialien für Konferenzen und Besprechungen, der offiziellen Roadmap, des Fehlerverfolgers und der (bescheidenen) Erfahrung der persönlichen Kommunikation mit den Entwicklern des zabbix scheinen sie die aktuelle Situation perfekt zu verstehen. Als der Zabbix begann, dachten die Autoren bei der Lösung ihrer Probleme nicht an IaC. Ein Jahrzehnt später reifte und blühte das Produkt. Die Kehrseite zum Erfolg war die Masse der Kunden des Unternehmens, deren Überwachung ihre Probleme löst. Und wer mag die Revolution nicht wirklich. Unter modernen Bedingungen sind sie einerseits dagegen, alles zu zerbrechen und von vorne zu beginnen. Andererseits mangelt es ihnen manchmal an Überwachungsfunktionen und sie schauen „zur Seite“, ohne zu vergessen, den Entwicklern des Zabbix die Wunschliste mitzuteilen. Das Unternehmen wird sie trotz jeglicher Sympathie für die neue, bequeme, modische Jugend nicht riskieren.

Wir werden in naher Zukunft keinen neuen, korrekten Prometheus von Zabbix sehen. Egal wie ich möchte. Aber die Arbeit geht eindeutig weiter - und wenn Sie wie der Zabbix gründlich und geduldig sind, erwartet die Zukunft auch eine wolkenlose Zukunft.

Wie wir Zabbix aktualisiert haben