Code Review - Engineering-Praxis im Sinne einer flexiblen Entwicklungsmethodik. Dies ist eine Analyse (Inspektion) des Codes, um Fehler, Mängel und Unstimmigkeiten beim Schreiben des Codes zu identifizieren und zu verstehen, ob der Code die Aufgabe löst.
Heute werde ich darüber sprechen, wie wir den Überprüfungsprozess für die Überwachung der Konfiguration in Zabbix organisiert haben. Der Artikel ist nützlich für diejenigen, die mit dem Zabbix-Überwachungssystem arbeiten, sowohl in einem großen Team als auch allein, selbst wenn Sie „zehn Hosts haben, was zu überprüfen ist“.
Welche Probleme lösen wir?
Zur Überwachung unserer internen Services und zum Aufbau der Infrastruktur verwenden wir Zabbix. Wir haben Namenskonventionen - Namenskonventionen (wir verwenden ein Vorbild mit Rollenhervorhebung, Profilvorlagen für die Überwachung), aber es gibt kein spezielles Überwachungsteam (es gibt leitende Ingenieure, die den Hund in Überwachungsfragen „gefressen“ haben), es gibt Ingenieure und Junioringenieure, ~ 500 Hosts, ~ 150 Vorlagen (kleine, aber sehr dynamische Infrastruktur).
Diese Infrastruktur wird zur Unterstützung und Automatisierung von Entwicklungsprozessen im Unternehmen verwendet . Zusätzlich zu deren Unterstützung entwickeln wir auch Automatisierungs- und Integrationstools. Daher haben wir wenig Erfahrung und Verständnis für Entwicklungsprozesse von innen.
Mit der Zunahme der Mitarbeiterzahl und den Änderungen im Überwachungssystem traten immer mehr typische Fehler auf, die schwer nachzuvollziehen waren:
- Bindungselement, direkt an Hosts außerhalb der Vorlagen auslösen (und einige Hosts bleiben nicht überwacht).
- Falscher Wert der Trigger (irgendwie vereinbart auf einem verfügbaren Speicherplatz von 3 GB, aber ein Tippfehler, wir erhalten einen nie funktionierenden Trigger von 34 GB).
- Nichteinhaltung der Namenskonvention - und wir erhalten den unverständlichen Namen des Triggers " Skript fehlgeschlagen" (obwohl dies bedeutet, dass das Update-Übermittlungssystem nicht funktioniert) oder der Vorlage "Gitlab- Vorlagen" (Überwachung welchen Servers oder Agenten?).
- Deaktivieren eines temporären Triggers für Tests. Infolgedessen haben wir die Warnung in der Infrastruktur verpasst und sind aufgestanden.
In der Welt der Programmierer werden all diese Probleme ganz einfach gelöst: Linter, Codereview. Warum also nicht diese Best Practices für eine Überprüfung der Zabbix-Konfiguration nutzen? Nimm es!
Wir haben bereits früher über die Vorteile und Beispiele der Codeüberprüfung geschrieben: Implementierung von Codeinspektionen im Entwicklungsprozess , Ein praktisches Beispiel für die Implementierung von Codeinspektion, Codeinspektion. Zusammenfassung
Warum benötigen Sie möglicherweise eine Überprüfung der Zabbix-Konfigurationen:
- Überprüfen Sie, ob Hosts und Vorlagen im Befehl als akzeptiert benannt sind ( Namenskonvention ).
- Trainieren Sie neue Mitarbeiter und stellen Sie sicher, dass sie die besprochene Aufgabe erfüllt haben.
- Wissenstransfer zwischen erfahrenen Mitarbeitern.
- Beachten Sie, dass Auslöser versehentlich oder vorübergehend ausgeschaltet werden.
- Beachten Sie falsche Werte in Element oder Trigger - last (0) anstelle von min (5 m) .
Fügen Sie Ihre Probleme in die Kommentare ein und versuchen Sie gemeinsam herauszufinden, wie Sie sie mit einer Überprüfung lösen können.
Wie Zabbix mit Änderungsverfolgung
Zabbix verfügt über ein Audit- Subsystem, mit dessen Hilfe wir untersuchen, wer Änderungen an der Konfiguration vorgenommen hat. Der wesentliche Nachteil ist die große Anzahl gespeicherter Ereignisse, da jedes Benutzerereignis gespeichert wird.
Stellen Sie sich vor, dass jede Änderung am Code im Git-Verlauf verbleibt. Sie haben versucht, den Variablennamen für eine Stunde auszuwählen, 40 Optionen ausprobiert und alle sind jetzt gespeichert. Jede Änderung ist ein separates Commit. Anschließend wird der Verlauf dieser Commits der Überprüfung übergeben, ohne dass Start und Ende verglichen werden können Version. Schrecklich, richtig?
Und in Zabbix Audit ist das richtig. Es kann verwendet werden, um Änderungen zu verfolgen, aber es ermöglicht Ihnen nicht, den Unterschied (diff) zwischen den beiden Zuständen des Systems (am Anfang der Woche und am Ende) schnell zu erkennen. Darüber hinaus sind alle ihre Aktionen nach Typ unterteilt: Hinzufügen, Ändern, Löschen müssen in verschiedenen Fenstern angezeigt werden. Ein Beispiel finden Sie in Ihrem Zabbix auf der Registerkarte Audit (oder sehen Sie sich den Screenshot an). Es ist schwer zu verstehen, welcher Zustand anfänglich ist, was aktuell ist, welche Änderungen während der Woche vorgenommen wurden. Die Situation ist kompliziert, wenn wir Dutzende von Änderungen pro Woche haben.
Ich möchte einen Mechanismus, der Folgendes ermöglicht:
- Machen Sie einmal pro Woche oder nach Abschluss der Aufgabe zum Ändern der Überwachungslogik eine Besetzung des Systemstatus.
- Vergleichen Sie das aktuelle Konfigurationsnugget mit dem vorherigen Nugget (diff).
- Namenskonvention automatisch überprüfen.
- Überprüfen Sie die Qualität der Aufgabe, geben Sie Empfehlungen, Ratschläge und diskutieren Sie Lösungen.
- Überprüfen Sie, ob die Änderungen legitim sind - alle werden gemäß der Aufgabe vorgenommen.
- Verwenden Sie vertraute Tools für Entwickler - Git, Diff, Mergerequest.
- Führen Sie einen Rollback auf einen bestimmten Status des Systems durch, verlieren Sie jedoch keine Daten (daher ist eine Sicherung nicht geeignet).
- Steuern Sie Zabbix-Entitäten - Host, Vorlagen, Aktion, Makros, Bildschirm, Karte.
Lassen Sie uns nun darüber sprechen, wie wir den Mechanismus implementiert haben und wie er für Ihre Zabbix-Infrastruktur nützlich sein kann.
Überprüfung der Zabbix-Konfiguration
Zum Speichern der Zabbix-Konfiguration verwenden wir die folgenden Formate:
- Original XML - Exportiert mit dem Original Zabbix Export . Verwendung für Host-, Vorlagen- und Bildschirmobjekte. Es gibt Funktionen:
- XML ist schwer zu lesen und Änderungen anzuzeigen.
- alle Felder enthalten, auch leere;
- enthalten das Felddatum - das Datum des Exports, wir schneiden es aus.
- Roh- JSON - Einige Arten von Objekten, die Zabbix nicht exportieren kann (Aktionen, Mediatypen), aber sie sind wichtig, und ich möchte die Änderungen sehen. Daher nehmen wir die Rohdaten von ZabbixAPI und speichern sie in JSON.
- Lesbares YAML - Wir verarbeiten das exportierte XML und das unformatierte JSON und speichern es in lesbarem, praktischem Vanille-YAML. Mit ihm ist es einfach, große Mengen an Veränderungen mit Ihren Augen zu bewältigen. Fügen Sie dort eine kleine Verarbeitung hinzu:
- Das Entfernen von Feldern ohne Werte ist ein strittiger Punkt, sodass wir ein leeres Feld überspringen können, obwohl es beispielsweise mit einem Feld mit einer Beschreibung des Problems am Trigger (trigger.description) gefüllt werden sollte. Nach der Diskussion wurde entschieden, dass es besser ist, leere Felder zu entfernen, es gibt zu viele davon. Wenn Sie möchten, können Sie einige leere Felder ausnehmen und nicht löschen.
- Wir löschen Daten - sie ändern sich jedes Mal und wenn Zusammenführungsanforderungen als Änderungen für jeden Host angezeigt werden.
- Sie können optional andere Vorgänge zum Ausfüllen von Informationen hinzufügen. Die Benutzer-ID wird beispielsweise anstelle von Benutzern in Aktion geschrieben.
Wir unterscheiden drei Git-Repositorys (wir verwenden Gitlab als Speicher, aber jedes VCS kann dies tun):
- zabbix-review-export - Hier werden der Exportcode (Python-Skripte) und die Parameter für gitlab-ci-Jobs gespeichert.
- zabbix-xml - Wir speichern XML + JSON in einem Zweig. Die Überprüfung dieses Geschäfts ist schwierig und zeitaufwändig. Wird verwendet, um den Zabbix-Konfigurationsstatus für eine bestimmte Zeit wiederherzustellen.
- zabbix-yaml ist unser Haupt-Repository. Hier führen wir Anforderungen zusammen, sehen die Änderungen, diskutieren die getroffenen Entscheidungen und führen sie im Master zusammen, wenn keine Kommentare vorhanden sind.
In diesen Repositorys speichern wir die Konfigurationsdaten, die Regeln dort sind wie folgt:
Jetzt sehen wir deutlich, welche Art von Objekt sich geändert hat, und es ist klar, welches Objekt sich geändert hat. Im folgenden Beispiel hat sich die Profilvorlage geändert . Scmdev. FlusContinuousTest .
Zeigen Sie an Beispielen
Um die Änderungen anzuzeigen, verwenden wir den Merge-Request-Mechanismus in gitlab.
Die Profilvorlage wurde geändert . DevOps. Test - hat den Triggerausdruck geändert. Vorlage, wie sie sich im Vorlagenordner befindet :
Der Ausdruck im Trigger und die Priorität wurden geändert:
Link zu einer Vorlage einer anderen:
Aktion geändert - Standardmäßig wurde am Ende des Textes eine neue Zeile hinzugefügt:
Ein Beispiel für Diskussionen in den Zusammenführungsanforderungen (genau wie Programmierer!) - es ist ersichtlich, dass sie die Standardvorlage direkt mit dem Host verbunden haben, aber es lohnt sich, eine separate Rolle für die Zukunft hervorzuheben. Screenshot aus der alten Überprüfung, dann weiterhin die XML-Darstellung der Konfiguration.
Im Allgemeinen ist alles einfach:
- Ein neuer Host oder ein anderes Objekt wurde hinzugefügt - eine neue Datei wurde erstellt.
- Der Host oder ein anderes Objekt wurde geändert - sah diff aus.
- Gelöscht - Die Datei wurde gelöscht.
Angenommen, Sie haben eine Aufgabe erledigt und möchten einen Kollegen fragen, ob Sie etwas vergessen haben. Wir bitten um eine Überprüfung: Führen Sie dazu im zabbix-review-export- Repository den gitlab-ci-Job mit einem manuellen Start aus.
Wir weisen einem Kollegen, der die Codeüberwachungsinfrastruktur überprüft, bespricht und korrigiert, eine Zusammenführungsanforderung zu.
Einmal pro Woche wird eine neue Überprüfung gestartet, um kleine Änderungen zu verfolgen. Dazu wird gemäß dem Zeitplan ( Zeitplan ) die Konfiguration exportiert und im Git-Repository gespeichert (mit einem neuen Commit), und der Überwachungsguru überprüft die Änderungen.
Sie verbreiten sich sanft, aber Sie müssen es versuchen
Jetzt erfahren Sie, wie Sie dieses System für die Überprüfung der Zabbix-Konfiguration konfigurieren ( wir lieben Open Source und versuchen, unsere Best Practices mit der Community zu teilen).
Es gibt zwei Verwendungsmöglichkeiten:
- Führen Sie das Exportskript einfach von Hand aus - führen Sie das Skript aus, sehen Sie sich die Änderungen an und lassen Sie
git add * && git commit && git push . Diese Option eignet sich für seltene Änderungen oder wenn Sie nur mit einem Überwachungssystem arbeiten. - Verwenden Sie gitlab-ci für die Automatisierung - dann müssen Sie nur noch auf die Schaltfläche Start klicken (siehe Abbildung oben). Option ist eher für große geeignet
faul Teams oder mit häufigen Änderungen.
Beide Optionen werden im Repository https://gitlab.com/devopshq/zabbix-review-export beschrieben, in dem alles gespeichert ist, was Sie benötigen - Skripte, gitlab-ci und README.md-Einstellungen, wie Sie Ihre Infrastruktur einrichten.
Versuchen Sie zunächst die erste Option (oder wenn Sie nicht über die gitlab-ci-Infrastruktur verfügen): Verwenden Sie den manuellen Modus - führen Sie das Skript zabbix-export.py aus , um die Konfiguration zu exportieren (zu sichern), und fügen Sie git add * && git commit && git push auf Ihrem Arbeitscomputer git add * && git commit && git push . Wenn Sie müde werden, gehen Sie zur zweiten Option - Automatisierung automatisieren!
Probleme und mögliche Verbesserungen
Jetzt werden die Änderungen entpersönlicht. Um herauszufinden, wer die Änderungen vorgenommen hat, müssen Sie das Audit- System verwenden, das Schmerzen und Leiden verursacht. Aber nicht alles ist so beängstigend und Audit wird selten benötigt. Normalerweise reicht eine Nachricht im Team-Chat aus, um den richtigen Mitarbeiter zu finden.
Ein weiteres Problem: Wenn sich ein Host oder Element in einem Host ändert, ist es nicht in XML enthalten. Das heißt, wir können alle Trigger auf einem bestimmten Host ausschalten oder ihre Priorität auf eine niedrigere ändern - und niemand wird davon erfahren und uns korrigieren! Wir warten auf eine Lösung unter https://support.zabbix.com/browse/ZBX-15175
Bis sie einen Mechanismus für die automatische Wiederherstellung entwickelten. Angenommen, eine Vorlage oder ein Host wurde stark geändert. Wir verstehen, dass die Änderungen falsch sind und Sie alles so zurückgeben müssen, wie es war. Jetzt suchen wir nach dem erforderlichen XML für den entsprechenden Host und importieren es manuell in die Benutzeroberfläche. Wir wollten jedoch nur auf die Schaltfläche "Die Vorlage TemplateName auf den Commit-Hash-Commit-Status zurücksetzen" klicken.
Sie können die bidirektionale Synchronisierung implementieren. Wenn Änderungen an der Zabbix-Konfiguration vorgenommen werden, wenn Änderungen an YAML vorgenommen werden, müssen Sie nicht zur Weboberfläche des Zabbix-Systems wechseln. Auf Github haben wir ein ähnliches Projekt getroffen, aber irgendwie ist es schnell verblasst und die Community hat die Idee nicht akzeptiert. Anscheinend ist es nicht so einfach, in YAML zu implementieren, was Sie mit der Maus in der Weboberfläche klicken können. Aus diesem Grund haben wir uns für eine Einweginteraktion entschieden.
Die ideale Option besteht darin, dieses System zum Speichern der Konfiguration als Code in Zabbix einzubetten, auch wenn dies nur im XML-Format erfolgt. So geschieht dies auf dem TeamCity CI-Server : Über die Benutzeroberfläche konfigurierte Konfigurationen führen Commits im Namen des Benutzers durch, der die Konfiguration geändert hat. Es stellt sich als sehr praktisches Werkzeug zum Anzeigen von Änderungen heraus und beseitigt auch das Problem der Depersonalisierung von Änderungen.
Versuchen Sie es
Starten Sie den Export Ihrer Zabbix-Konfiguration, schreiben Sie sie in ein Repository (lokal genug), warten Sie eine Woche und führen Sie sie erneut aus. Jetzt haben Sie die Änderungen unter Kontrolle! https://gitlab.com/devopshq/zabbix-review-export
Wer würde sich für diese Funktionalität in der Zabbix-Box interessieren - bitte stimmen Sie für die Ausgabe https://support.zabbix.com/browse/ZBXNEXT-4862 ab
Alle 100% Betriebszeit!