In der IT gibt es einen Aberglauben: „Wenn es funktioniert, nicht anfassen“. Das lässt sich auch auf unser Überwachungssystem anwenden. Bei Southbridge nutzen wir Zabbix – als wir uns dafür entschieden, war es wirklich beeindruckend. Und im Grunde gab es keine Alternativen.
Im Laufe der Zeit hat unser Ökosystem an Anleitungen und zusätzlichen Wrappern zugenommen, und es gab eine Integration mit Redmine. Zabbix erhielt einen starken Wettbewerber, der in vielen Aspekten überlegen war: Arbeitsgeschwindigkeit, HA praktisch sofort einsatzbereit, ansprechende Visualisierung, Optimierung der Arbeit in Kubernetes-Umgebungen.
Aber wir beeilen uns nicht mit dem Wechsel. Wir haben beschlossen, einen Blick auf Zabbix zu werfen und zu erkunden, welche Funktionen sie in den nächsten Versionen planen. Wir gingen direkt zur Sache und stellten Sergej Sorokin, dem Direktor für Entwicklung bei Zabbix, und Vitalij Schurawlew, dem Solution Architect, unangenehme Fragen. Was dabei herauskam, lesen Sie im Folgenden.
1. Erzählen Sie uns die Geschichte des Unternehmens. Wie entstand die Idee des Produkts?
Die Geschichte des Unternehmens begann 1997, als der Gründer und Eigentümer Alexey Vladychev als Datenbankadministrator in einer Bank arbeitete. Alexey erschien es ineffektiv, Datenbanken zu verwalten, ohne Zugang zu historischen Werten verschiedener Parameter zu haben und das aktuelle sowie historische Umfeld zu verstehen.
Dabei waren die zu diesem Zeitpunkt verfügbaren Überwachungslösungen sehr kostspielig, schwerfällig und ressourcenintensiv. Daher begann Alexey, verschiedene Skripte zu schreiben, die ihm eine effektive Überwachung der ihm anvertrauten Infrastruktur ermöglichten. Dies entwickelte sich zu einem Hobby. Alexey wechselte die Stellen, aber das Interesse an dem Projekt blieb bestehen. In den Jahren 2000-2001 wurde das Projekt von Grund auf neu geschrieben – und Alexey dachte darüber nach, 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. Alexey entschied sich, ihn unter der GPLv2-Lizenz zu veröffentlichen. Das Werkzeug wurde sofort in der Fachwelt wahrgenommen. Mit der Zeit erhielt Alexey Anfragen zur Unterstützung, Durchführung von Schulungen und Erweiterung der Softwaremöglichkeiten. Die Anzahl solcher Aufträge wuchs stetig. So kam es selbstverständlich zur Entscheidung, eine Firma zu gründen. Die Firma wurde am 12. April 2005 gegründet.
2. Welche Schlüsselstellen können Sie in der Entwicklungsgeschichte von Zabbix hervorheben?
Derzeit gibt es mehrere solcher Stellen:
a. Beginn der Arbeit von Alexej an den Skripten – 1997.
b. Veröffentlichung des Codes unter der GPLv2-Lizenz – 2001.
c. Gründung der Zabbix GmbH – 2005.
d. Abschluss der ersten Partnerschaftsverträge, Erstellung des Partnerprogramms – 2007.
e. Gründung der Zabbix Japan LLC – 2012.
f. Gründung der Zabbix LLC (USA) – 2015
g. Gründung der Zabbix GmbH – 2018
3. Wie viele Mitarbeiter haben Sie?
Derzeit arbeiten in der Zabbix-Gruppe etwas mehr als 70 Mitarbeiter: Entwickler, Tester, Projektleiter, Supportingenieure, Berater, Vertriebsmitarbeiter, Marketingmitarbeiter.
4. Wie erstellen Sie den Fahrplan, sammeln Sie Feedback von Nutzern? Wie bestimmen Sie, wohin Sie als Nächstes gehen?
Bei der Erstellung des Fahrplans für die nächste Version von Zabbix orientieren wir uns an den folgenden wichtigen Faktoren, genauer gesagt, wir erstellen den Fahrplan nach den folgenden Kategorien:
a. Strategische Verbesserungen an Zabbix. Dinge, die Zabbix selbst für sehr wichtig hält. Beispielsweise der Zabbix-Agent, der in Go geschrieben ist.
b. Dinge, die Zabbix-Kunden und -Partner sehen wollen. Und für die sie bereit sind zu bezahlen.
c. Wünsche/Vorschläge aus der Zabbix-Community.
d. Technische Schulden. 🙂 Dinge, die wir in früheren Versionen veröffentlicht haben, aber nicht vollständig funktional, nicht flexibel genug gemacht haben, nicht alle Optionen angeboten haben.
5. Können Sie Zabbix und Prometheus vergleichen? Was ist bei Zabbix besser, was schlechter?
Der Hauptunterschied besteht unserer Meinung nach darin, dass Prometheus in erster Linie ein System zur Sammlung von Metriken ist – und um ein umfassendes Monitoring im Unternehmen durchzuführen, müssen zahlreiche andere Komponenten hinzugefügt werden, wie Grafana für die Visualisierung, ein separates Langzeitspeicher, irgendwo das Management von Problemen und separat die Arbeit mit Protokollen…
In Prometheus wird es auch keine standardmäßigen Monitoring-Vorlagen geben; nachdem man alle tausenden Metriken von Exportern erhalten hat, muss man selbst die problematischen Signale finden. Die Konfiguration von Prometheus erfolgt über Konfigurationsdateien. Wo es irgendwo praktischer ist, ist es woanders vielleicht nicht.
Zabbix ist eine universelle Plattform zur Erstellung von Monitoring „von A bis Z“, mit eigener Visualisierung, Korrelation von Problemen und deren Anzeige, Verteilung von Zugriffsrechten auf das System, Audit von Aktionen, vielen Optionen zur Datensammlung über Agenten, Proxy und über verschiedene Protokolle, sowie der Möglichkeit, das System schnell mit Plugins, Skripten, Modulen zu erweitern.
Man kann auch einfach Daten so sammeln, wie sie sind, zum Beispiel über das HTTP-Protokoll, und die Antworten dann in nützliche Metriken verwandeln mit solchen Preprocessing-Funktionen wie JavaScript, JSONPath, XMLPath, CSV und ähnlichen. Viele Nutzer schätzen Zabbix für die Möglichkeit, das System über eine Webschnittstelle zu konfigurieren und zu verwalten, für die Möglichkeit, gängige Monitoring-Konfigurationen in Form von Templates zu beschreiben, die man miteinander teilen kann, und die nicht nur Metriken, sondern auch Entdeckungsregeln, Grenzwertwerte, Graphen und Beschreibungen enthalten – ein vollständiges Set an Objekten zur Überwachung typischer Objekte.
Viele schätzen auch die Möglichkeit, das Management und die Konfiguration über die Zabbix API zu automatisieren. Insgesamt möchten wir keinen Glaubenskrieg auslösen. Wir glauben, dass beide Systeme gut zu ihren Aufgaben passen 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. Habt ihr darüber nachgedacht, Zabbix als SaaS anzubieten?
Darüber haben wir nachgedacht und werden es in Zukunft umsetzen, aber wir möchten eine solche Lösung so benutzerfreundlich wie möglich gestalten. In diesem Fall sollte das standardmäßige Zabbix zusammen mit Kommunikationsmitteln, erweiterten Datensammlungsmaßnahmen und so weiter angeboten werden.
7. Wann können wir mit Zabbix HA rechnen? Und ist das überhaupt zu erwarten?
Auf jeden Fall ist Zabbix HA zu erwarten. Wir hoffen sehr, in Zabbix 5.0 LTS etwas zu sehen, aber die Situation wird im November 2019 klarer sein, wenn der Roadmap für Zabbix 5.0 endgültig bestätigt wird.
8. Warum gibt es in der Box nur eine so geringe Auswahl an Medientypen? Plant ihr, Slack, Telegram und so weiter hinzuzufügen? Gibt es noch jemanden, der Jabber nutzt?
Jabber wurde in Zabbix 4.4 entfernt, dafür wurden Webhooks hinzugefügt. Was die Medientypen betrifft, möchten wir keine spezifischen Anwendungen aus dem System machen, sondern standardisierte Kommunikationsmittel. Es ist kein Geheimnis, dass viele solcher Chats oder Service Desks eine API über HTTP haben – daher wird sich die Situation mit dem Erscheinen von 4.4 in diesem Jahr ändern.
Mit der Einführung von Webhooks in Zabbix können wir in naher Zukunft die gefragtesten Integrationen direkt out of the box erwarten. Diese Integrationen werden bidirektional sein und nicht nur einfache Benachrichtigungen in eine Richtung. Die Media-Typen, die wir nicht erreichen können, wird unsere Community bereitstellen – denn jetzt kann ein Media-Typ vollständig in eine Konfigurationsdatei exportiert, auf share.zabbix.com oder GitHub hochgeladen werden. Andere Benutzer müssen dann nur die Datei importieren, um diese Integration verwenden zu können. 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 Richtung entwickelt sich weiter. Zum Beispiel wurde in 4.4 Discovery für Datastore mit dem Schlüssel vm.datastore.discovery eingeführt. In 4.4 wurden auch sehr tolle Schlüssel wie wmi.getall hinzugefügt – wir erwarten, dass wir damit, zusammen mit dem Schlüssel perf_counter_en, ein gutes Monitoring für Hyper-V erstellen können. Außerdem werden in dieser Richtung in Zabbix 5.0 weitere wichtige Änderungen erfolgen.
10. Habt ihr nicht darüber nachgedacht, auf Templates zu verzichten und es wie bei Prometheus zu machen, wo alles, was bereitgestellt wird, abgerufen wird?
Prometheus ruft automatisch alle Metriken ab, das ist praktisch. Ein Template ist jedoch mehr als nur eine Sammlung von Metriken, es ist ein „Container“, der die gesamte erforderliche Standardkonfiguration für das Monitoring dieses Ressourcetypen oder Dienstes enthält. Darin sind bereits wichtige Trigger, Grafiken, Entdeckungsregeln enthalten, sowie Beschreibungen der Metriken und Schwellenwerte, die dem Benutzer helfen, zu verstehen, was gesammelt wird und welche Schwellenwerte genau überprüft werden und warum. Templates lassen sich außerdem leicht mit anderen Benutzern teilen – und sie erhalten ein gutes Monitoring ihres Systems, ohne unbedingt ein Experte darin sein zu müssen.
11. Warum gibt es so wenige Metriken out of the box? Das erschwert doch die Konfiguration aus Sicht des Betriebs erheblich.
Wenn Sie mit „out of the box“ vorgefertigte Templates meinen, arbeiten wir gerade an der Erweiterung und Verbesserung unserer Templates. Zabbix 4.4 wurde mit einem neuen, verbesserten Set und besseren Möglichkeiten veröffentlicht.
Für Zabbix findet man immer eine fertige Vorlage auf share.zabbix.com, die nahezu für jedes System geeignet ist. Aber wir haben entschieden, dass wir auch eigene Basisvorlagen erstellen sollten, um anderen ein Beispiel zu zeigen und die Benutzer davon zu entlasten, für ein MySQL erneut eine Vorlage schreiben zu müssen. Daher wird es jetzt in Zabbix mit jeder Version immer mehr offizielle Vorlagen geben.
12. Wann wird es möglich sein, Trigger zu erstellen, die nicht an Hosts gebunden sind, sondern beispielsweise auf Basis von Labels? Zum Beispiel, wenn wir eine Webseite aus n verschiedenen Punkten überwachen und einen einfachen Trigger haben möchten, der anspringt, wenn die Webseite aus 2 oder mehr Punkten nicht erreichbar ist.
Solche Funktionalität gibt es tatsächlich schon seit mehreren Jahren in Zabbix, entwickelt für einen der Kunden. Der Kunde – ICANN. Ähnliche Prüfungen können zum Beispiel über aggregierte Items oder die Zabbix API durchgeführt werden. Derzeit arbeiten wir intensiv daran, die Erstellung solcher Prüfungen zu vereinfachen.
P.S.: Auf einem der Slörms haben die Zabbix-Entwickler uns gefragt, was wir im Produkt sehen möchten, um Kubernetes-Cluster genau mit Zabbix zu überwachen und nicht mit Prometheus.
Es ist großartig, wenn Entwickler auf Kunden zugehen und nicht nur für sich alleine arbeiten. Und nun begrüßen wir jedes Release mit aufrichtigem Interesse – es freut uns, dass immer mehr Features, über die wir gesprochen haben, Gestalt annehmen.
Solange die Entwickler sich nicht zurückziehen, sondern die Bedürfnisse der Kunden interessieren, lebt und entwickelt sich das Produkt weiter. Wir werden die neuen Releases von Zabbix im Auge behalten.
P.P.S.: In ein paar Monaten werden wir einen Online-Kurs zum Monitoring starten. Wer interessiert ist, meldet sich an, um die Ankündigung nicht zu verpassen. In der Zwischenzeit kann man unseren .
Quelle: habr.com
