In der IT gibt es einen Aberglauben: „Läuft, nicht anfassen“. Das kann man auch über unser Überwachungssystem sagen. Bei Southbridge verwenden wir Zabbix — als wir uns dafür entschieden, war es wirklich beeindruckend. Und grundsätzlich gab es keine Alternativen.
Im Laufe der Zeit hat unser Ökosystem Anleitungen, zusätzliche Schnittstellen entwickelt, und es gab eine Integration mit Redmine. Zabbix hat einen starken Wettbewerb erhalten, der in vielen Aspekten überlegen war: Arbeitsgeschwindigkeit, Hochverfügbarkeit praktisch out-of-the-box, ansprechende Visualisierung, und Optimierung der Nutzung in Kubernetes-Umgebungen.
Aber wir beeilen uns nicht mit dem Umstieg. Wir haben beschlossen, bei Zabbix vorbei zu schauen und uns zu erkundigen, welche Funktionen sie in den kommenden Versionen planen. Wir haben keine Höflichkeiten gewahrt und unangenehme Fragen an Sergey Sorokin, den Entwicklungsleiter von Zabbix, und Vitaly Zhuravlev, Solution Architect, gerichtet. Was dabei herauskam, lesen Sie weiter.
1. Erzählen Sie uns von der Geschichte des Unternehmens. Wie entstand die Produktidee?
Die Unternehmensgeschichte begann 1997, als der Gründer und Eigentümer Alexey Vladychev als Datenbankadministrator in einer Bank arbeitete. Es erschien Alexey ineffizient, Datenbanken ohne Informationen über historische Werte verschiedener Parameter zu verwalten, ohne ein Verständnis für den aktuellen und historischen Zustand der Umgebung zu haben.
Die damals verfügbaren Lösungen zur Überwachung auf dem Markt waren sehr kostspielig, unhandlich und benötigten große Ressourcen. Daher begann Alexej, verschiedene Skripte zu schreiben, die es ihm ermöglichten, den ihm anvertrauten Teil der Infrastruktur effektiv zu überwachen. Dies entwickelte sich zu einem Hobby. Alexej wechselte die Arbeitgeber, aber das Interesse an dem Projekt blieb. In den Jahren 2000-2001 wurde das Projekt von Grund auf neu geschrieben – und Alexej überlegte, anderen Administratoren die Möglichkeit zu geben, seine Entwicklungen zu nutzen. Dabei stellte sich die Frage, unter welcher Lizenz der bestehende Code veröffentlicht werden sollte. Alexej entschied sich, ihn unter der GPLv2-Lizenz zu veröffentlichen. Das Tool wurde sofort in der Fachwelt bemerkt. Im Laufe der Zeit erhielt Alexej Anfragen nach Unterstützung, Schulungen und Erweiterungen der Softwarefunktionen. Die Zahl solcher Aufträge wuchs ständig. So kam es ganz natürlich zur Entscheidung, ein Unternehmen zu gründen. Das Unternehmen wurde am 12. April 2005 gegründet.
2. Welche Schlüsselpunkte können Sie in der Entwicklungsgeschichte von Zabbix hervorheben?
Derzeit gibt es mehrere solche Punkte:
a. Beginn von Alexeys Arbeiten an den Skripten – 1997.
b. Veröffentlichung des Codes unter der GPLv2-Lizenz – 2001.
c. Gründung des Unternehmens Zabbix – 2005.
d. Abschluss erster Partnerschaftsverträge, Einrichtung des Partnerprogramms – 2007.
e. Gründung von Zabbix Japan LLC – 2012.
f. Gründung von Zabbix LLC (USA) – 2015.
g. Gründung der Zabbix GmbH – 2018.
3. Wie viele Mitarbeiter haben Sie?
Derzeit arbeiten etwas über 70 Mitarbeiter in der Zabbix-Gruppe: Entwickler, Tester, Projektleiter, Support-Techniker, Berater, Verkäufer und Marketingmitarbeiter.
4. Wie erstellen Sie die Roadmap, sammeln Sie Rückmeldungen von Benutzern? Wie bestimmen Sie, wo es weitergeht?
Bei der Erstellung der Roadmap für die nächste Version von Zabbix orientieren wir uns an folgenden wichtigen Faktoren, genauer gesagt, wir sammeln die Roadmap nach den folgenden Kategorien:
a. Strategische Verbesserungen von Zabbix. Dinge, die Zabbix selbst für sehr wichtig erachtet. Zum Beispiel der Zabbix-Agent, der in Go geschrieben wurde.
b. Dinge, die Zabbix-Kunden und -Partner in Zabbix sehen möchten und für die sie bereit sind zu bezahlen.
c. Wünsche/Vorschläge von der Zabbix-Community.
Technische Schulden. 🙂 Dinge, die wir in früheren Versionen veröffentlicht haben, aber nicht vollständig funktional gemacht wurden, nicht flexibel genug waren und nicht alle Optionen angeboten haben.
5. Können Sie Zabbix mit Prometheus vergleichen? Was ist bei Zabbix besser und was schlechter?
Der Hauptunterschied besteht darin, dass Prometheus in erster Linie ein System zur Metriksammlung ist – und um ein umfassendes Monitoring im Unternehmen zu realisieren, müssen zahlreiche andere Komponenten hinzugefügt werden, wie Grafana zur Visualisierung, ein separates Langzeitarchiv, eine eigenständige Problemdokumentation und separate Logger-Arbeiten...
In Prometheus wird es keine vorgefertigten Monitoring-Vorlagen geben; nachdem Sie tausende von Metriken von Exportern erhalten haben, müssen Sie selbst problematische Signale darin finden. Die Konfiguration von Prometheus erfolgt über Konfigurationsdateien. An manchen Stellen ist das praktischer, an anderen weniger.
Zabbix ist eine umfassende Plattform für die Erstellung von Monitoring-Lösungen von Grund auf. Wir bieten eigene Visualisierungen, Problemerkennung und -anzeige, Zugriffskontrollverteilung, Aktionsprotokollierung sowie zahlreiche Datensammlungsoptionen über Agenten, Proxys und verschiedene Protokolle. Zudem lässt sich das System schnell mit Plugins, Skripten und Modulen erweitern.
Es ist sogar möglich, Daten einfach so zu sammeln, wie sie sind, zum Beispiel über das HTTP-Protokoll, und die Antworten dann mithilfe von Preprocessing-Funktionen wie JavaScript, JSONPath, XMLPath, CSV usw. in nützliche Metriken umzuwandeln. Viele Nutzer schätzen Zabbix für die Möglichkeit, das System über eine Web-Oberfläche zu konfigurieren und zu verwalten, für die Beschreibung typischer Monitoring-Konfigurationen in Form von Vorlagen, die miteinander geteilt werden können und die nicht nur Metriken, sondern auch Erkennungsregeln, Schwellenwerte, Grafiken und Beschreibungen enthalten — ein vollständiges Set an Objekten zur Überwachung typischer Ressourcen.
Viele schätzen auch die Möglichkeit, die Verwaltung und Konfiguration über die Zabbix API zu automatisieren. Insgesamt wollen wir keinen Streit entfesseln. Wir glauben, dass beide Systeme gut für ihre jeweiligen Aufgaben geeignet sind und sich harmonisch ergänzen können. Zum Beispiel kann Zabbix ab Version 4.2 Daten von Prometheus-Exportern oder von sich selbst abrufen.
6. Haben Sie darüber nachgedacht, Zabbix als SaaS anzubieten?
Ja, wir haben darüber nachgedacht und werden es in Zukunft umsetzen, aber wir möchten sicherstellen, dass die Lösung für die Kunden so bequem wie möglich ist. In diesem Fall sollte das Standard-Zabbix zusammen mit Kommunikationsmitteln, erweiterten Datensammlungswerkzeugen und so weiter angeboten werden.
7. Wann können wir mit Zabbix HA rechnen? Und ist das zu erwarten?
Auf Zabbix HA können Sie definitiv warten. Wir hoffen sehr, in Zabbix 5.0 LTS etwas zu sehen, aber die Situation wird klarer werden im November 2019, wenn der Roadmap von Zabbix 5.0 vollständig bestätigt wird.
8. Warum gibt es so eine begrenzte Auswahl an Media-Typen von Haus aus? Planen Sie, Slack, Telegram und so weiter hinzuzufügen? Wird Jabber noch von jemandem verwendet?
In der Version 4.4 von Zabbix wurde Jabber entfernt, jedoch wurden dafür Webhooks hinzugefügt. Was die Medientypen angeht, möchte ich keine spezifischen Anwendungen aus dem System erstellen, sondern die standardmäßigen Kommunikationsmittel nutzen. Es ist kein Geheimnis, dass viele Chat-Dienste oder Service-Desk-Systeme über eine HTTP-API verfügen – daher wird sich in diesem Jahr mit der Veröffentlichung von 4.4 einiges ändern.
Mit der Einführung von Webhooks in Zabbix ist in naher Zukunft mit allen gefragten Integrationen direkt ab Werk zu rechnen. Diese Integrationen werden dabei bidirektional sein, und nicht nur einfache Benachrichtigungen in eine Richtung senden. Die Medientypen, auf die wir nicht zugreifen können, werden von unserer Community erstellt – denn nun kann jeder Medientyp in eine Konfigurationsdatei exportiert und auf share.zabbix.com oder GitHub veröffentlicht werden. Andere Benutzer müssen nur die Datei importieren, um mit dieser Integration zu beginnen. Dabei sind keine zusätzlichen Skripte erforderlich!
9. Warum entwickelt sich der Bereich der Virtual Machine Discovery nicht weiter? Es gibt nur VMware. Viele warten auf Integrationen mit EC2 und OpenStack.
Nein, die Entwicklung geht voran. Zum Beispiel wurde in Version 4.4 das Discovery-Datenlager über den Schlüssel vm.datastore.discovery eingeführt. In 4.4 gab es auch sehr hilfreiche Schlüssel wie wmi.getall – wir erwarten, dass damit zusammen mit dem Schlüssel perf_counter_en eine gute Überwachung von Hyper-V möglich sein wird. Und in Richtung Zabbix 5.0 wird es weitere wichtige Änderungen geben.
10. Haben Sie darüber nachgedacht, auf Vorlagen zu verzichten und es wie bei Prometheus zu machen, wo alles, was angeboten wird, automatisch erfasst wird?
Prometheus erfasst automatisch alle Metriken, das ist praktisch. Eine Vorlage ist jedoch mehr als nur eine Sammlung von Metriken; sie ist ein 'Container', der die gesamte erforderliche Standardkonfiguration für die Überwachung eines bestimmten Ressourchentyp oder Dienstes enthält. Darin sind bereits wichtige Trigger, Diagramme, Erkennungsregeln enthalten, und sie bieten Beschreibungen der Metriken und der Grenzwerte, die dem Benutzer helfen, zu verstehen, was gesammelt wird und welche Schwellenwerte genau überprüft werden und warum. Darüber hinaus ist es einfach, Vorlagen mit anderen Benutzern zu teilen – sie erhalten eine gute Überwachung ihres Systems, auch ohne Experten in diesem Bereich zu sein.
11. Warum gibt es so wenige Metriken standardmäßig? Das erschwert die Konfiguration aus Sicht des Betriebs erheblich.
Wenn Sie mit "aus der Box" vorgefertigte Vorlagen meinen, arbeiten wir derzeit an der Erweiterung und Verbesserung unserer Vorlagen. Zabbix 4.4 wurde mit einem neuen, verbesserten Set und besseren Funktionen veröffentlicht.
Für Zabbix finden Sie immer auf share.zabbix.com eine fertige Vorlage für praktisch jedes System. Aber wir haben entschieden, dass wir auch grundlegende Vorlagen selbst erstellen sollten, um anderen ein Beispiel zu zeigen und die Nutzer davon abzuhalten, für ein MySQL erneut eine Vorlage schreiben zu müssen. Daher wird es in Zabbix mit jeder neuen Version immer mehr offizielle Vorlagen geben.
12. Wann wird es möglich sein, Trigger zu erstellen, die nicht an Hosts gebunden sind, sondern auf der Grundlage von Labels? Zum Beispiel überwachen wir eine Website von n verschiedenen Punkten aus und wollen einen einfachen Trigger, der ausgelöst wird, wenn die Website von 2 oder mehr Punkten nicht erreichbar ist.
Tatsächlich gibt es eine solche Funktionalität in Zabbix bereits seit mehreren Jahren, die für einen unserer Kunden entwickelt wurde. Der Kunde ist ICANN. Ähnliche Prüfungen können zum Beispiel auch über aggregierte Elemente oder die Zabbix API durchgeführt werden. Wir arbeiten derzeit aktiv daran, die Erstellung solcher Prüfungen zu vereinfachen.
P.S.: Auf einem der Slyrms haben die Entwickler von Zabbix uns gefragt, was wir im Produkt sehen möchten, um Kubernetes-Cluster genau mit Zabbix und nicht mit Prometheus zu überwachen.
Es ist großartig, wenn Entwickler auf die Wünsche der Kunden eingehen und sich nicht in ihrem eigenen Kosmos bewegen. Daher erwarten wir jedes Release mit aufrichtigem Interesse – es freut uns, dass immer mehr Funktionen, über die wir gesprochen haben, Wirklichkeit werden.
Solange die Entwickler nicht in sich gekehrt sind und sich für die Bedürfnisse der Kunden interessieren, bleibt das Produkt lebendig und entwickelt sich weiter. Wir werden die neuen Releases von Zabbix im Auge behalten.
P.P.S.: In ein paar Monaten starten wir einen Online-Kurs über Monitoring. Wer interessiert ist, kann sich anmelden, um die Ankündigung nicht zu verpassen. In der Zwischenzeit kann man unser .
Quelle: habr.com
