HighLoad++, Michail Makurov, Maxim Tschernizow (Intersvyaz): Zabbix, 100kNVPS auf einem Server

Die nächste HighLoad++-Konferenz findet am 6. und 7. April 2020 in Sankt Petersburg statt. Weitere Informationen und Tickets. über den LinkHighLoad++ Moskau 2018. Saal „Moskau“. 9. November, 15:00. Abstracts und Präsentation nützlich sein..

* Monitoring – online und Analyse.
* Hauptbeschränkungen der ZABBIX-Plattform.
* Lösung zur Skalierung des Analyse-Speichers.
* ZABBIX-Server-Optimierung.
* UI-Optimierung.
* Erfahrungen mit dem Betrieb des Systems bei Lasten von über 40k NVPS.
* Kurze Fazits.

Mikhail Makurov (im Folgenden – MM): – Hallo zusammen!

Maxim Tschernizow (im Folgenden – MT): – Guten Tag!

MM: – Erlauben Sie mir, Maxim vorzustellen. Max ist ein talentierter Ingenieur, der beste Netzwerktechniker, den ich kenne. Maxim beschäftigt sich mit Netzwerken und Diensten, deren Entwicklung und Betrieb.

MT: – Und ich möchte über Mikhail sprechen. Mikhail ist C-Entwickler. Er hat mehrere hochbelastete Lösungen zur Datenverkehrsverarbeitung für unser Unternehmen erstellt. Wir leben und arbeiten im Ural, in der Stadt der harten Männer Tscheljabinsk, in der Firma „Intersvyaz“. Unser Unternehmen ist Anbieter von Internet- und Kabel-TV-Diensten für eine Million Menschen in 16 Städten.

MM: Es ist wichtig zu erwähnen, dass „Intersvyaz“ weit mehr ist als nur ein Anbieter, es ist ein IT-Unternehmen. Die meisten unserer Lösungen werden von unserem IT-Team entwickelt.

A: Von den Servern, die den Datenverkehr verarbeiten, bis hin zum Callcenter und der mobilen App. In unserem IT-Team sind derzeit etwa 80 Personen mit äußerst vielfältigen Kompetenzen tätig.

Über Zabbix und seine Architektur

MT: Jetzt werde ich versuchen, einen persönlichen Rekord aufzustellen und in einer Minute zu erklären, was Zabbix (im Folgenden „Zabbix“) ist.

Zabbix positioniert sich als ein „Out-of-the-Box“ Unternehmensüberwachungssystem. Es bietet viele Funktionen, die das Leben erleichtern: ausgeklügelte Eskalationsregeln, APIs für die Integration, Gruppierung und automatische Erkennung von Hosts und Metriken. Zabbix verfügt über sogenannte Skalierungsmöglichkeiten – Proxys. Zabbix ist ein Open-Source-System.

Kurz zur Architektur. Man kann sagen, sie besteht aus drei Komponenten:

• Server. In C geschrieben. Mit einer recht komplexen Verarbeitung und Übertragung von Informationen zwischen den Threads. Alle Verarbeitungen erfolgen hier: vom Empfang bis zur Speicherung in der Datenbank.
• Alle Daten werden in einer Datenbank gespeichert. Zabbix unterstützt MySQL, PostgreSQL und Oracle.
• Das Web-Interface ist in PHP geschrieben. Es wird in den meisten Systemen zusammen mit dem Apache-Server geliefert, funktioniert jedoch effizienter in Kombination mit Nginx + PHP.

Heute möchten wir eine Geschichte aus dem Leben unseres Unternehmens erzählen, die mit "Zabbix" zu tun hat...

Eine Geschichte aus dem Leben der Firma "Intersvyaz". Was haben wir und was brauchen wir?

Vor 5 oder 6 Monaten. Eines Tages nach der Arbeit...

MT: – Misha, hallo! Schön, dass ich dich erwischt habe – ich muss mit dir reden. Wir hatten wieder Probleme mit dem Monitoring. Während eines großen Ausfalls lief alles langsam, und es gab keine Informationen über den Zustand des Netzwerks. Leider kommt das nicht zum ersten Mal vor. Ich brauche deine Hilfe. Lass uns dafür sorgen, dass unser Monitoring unter allen Umständen funktioniert!

MM: – Aber lass uns zuerst synchronisieren. Ich habe da seit ein paar Jahren nicht mehr hinein geschaut. Soweit ich mich erinnere, haben wir vor etwa 8 Jahren Nagios aufgegeben und sind zu "Zabbix" gewechselt. Und jetzt haben wir, glaube ich, 6 leistungsstarke Server und etwa ein Dutzend Proxys. Verwechsel ich da nichts?

MT: – Fast. 15 Server, von denen einige virtuelle Maschinen sind. Das Wichtigste ist, dass uns das nicht hilft, wenn wir es am dringendsten brauchen. Bei einem Ausfall – die Server sind langsam und nichts ist sichtbar. Wir haben versucht, die Konfiguration zu optimieren, aber das hat nicht den gewünschten Leistungsschub gebracht.

MM: – Verstanden. Hast du schon etwas untersucht oder aus den Diagnosen gefunden?

MT: – Das Erste, mit dem wir uns auseinandersetzen müssen, ist die Datenbank. MySQL ist ständig belastet, da es neue Metriken speichert, und wenn Zabbix anfängt, eine Menge Ereignisse zu generieren, zieht sich die Datenbank buchstäblich für mehrere Stunden zurück. Ich habe dir schon von der Konfigurationsoptimierung erzählt, und dieses Jahr haben wir die Hardware aktualisiert: Auf den Servern sind über hundert Gigabyte RAM installiert und die Speichermedien laufen auf SSD-RAID-Systemen – es macht keinen Sinn, die Kapazität linear weiter zu erhöhen. Was sollen wir tun?

MM: – Verstanden. Generell ist MySQL eine LTP-Datenbank. Offensichtlich eignet sie sich nicht mehr zur Speicherung von Archivmetriken in unserer Größenordnung. Lass uns das angehen.

MT: – Lass es uns machen!

Integration von Zabbix und Clickhouse als Ergebnis des Hackathons

Nach einiger Zeit erhielten wir interessante Daten:

Der Großteil des Speicherplatzes in unserer Datenbank war mit einem Archivar von Metriken belegt, während weniger als 1 % für Konfigurationen, Vorlagen und Einstellungen verwendet wurde. Zu diesem Zeitpunkt hatten wir bereits über ein Jahr lang eine Big Data-Lösung auf der Basis von Clickhouse betrieben. Der Weg, den wir einschlagen wollten, war offensichtlich. Bei unserem Frühjahrs-Hackathon habe ich eine Integration von Zabbix mit Clickhouse für den Server und das Frontend geschrieben. Zu diesem Zeitpunkt hatte Zabbix bereits Unterstützung für ElasticSearch, und wir haben uns entschieden, die beiden zu vergleichen.

Vergleich von Clickhouse und Elasticsearch

MM: – Für den Vergleich haben wir eine Last erzeugt, die der eines Zabbix-Servers entspricht, und beobachtet, wie sich die Systeme verhalten. Wir haben Daten in Paketen von 1000 Zeilen geschrieben und CURL verwendet. Wir vermuteten bereits im Vorfeld, dass Clickhouse für das Lastprofil, das Zabbix generiert, effizienter sein würde. Die Ergebnisse übertrafen sogar unsere Erwartungen:

Unter den gleichen Bedingungen schrieb Clickhouse in den Tests drei Mal so viele Daten. Dabei konsumierten beide Systeme sehr effizient (geringe Ressourcen), um die Daten zu lesen. Aber ElasticSearch benötigte beim Schreiben eine hohe CPU-Auslastung:

Insgesamt hat «ClickHouse» «Elasticsearch» deutlich in Bezug auf CPU-Verbrauch und Geschwindigkeit übertroffen. Durch die Datenkompression benötigt «ClickHouse» zudem 11-mal weniger Speicherplatz auf der Festplatte und führt etwa 30-mal weniger Festplattenoperationen durch:

MT: – Ja, die Arbeit mit dem Speichersystem bei «ClickHouse» ist sehr effizient umgesetzt. Sie können riesige SATA-Festplatten für Datenbanken verwenden und dabei Schreibgeschwindigkeiten vonHunderttausenden von Zeilen pro Sekunde erzielen. Das System unterstützt nativ Sharding und Replikation und lässt sich recht einfach konfigurieren. Wir sind sehr zufrieden mit dem Betrieb über das letzte Jahr.

Um Ressourcen zu optimieren, kann «ClickHouse» neben der bestehenden Hauptdatenbank installiert werden, wodurch viel CPU-Zeit und Festplattenoperationen eingespart werden. Wir haben die Metrikarchive auf die bereits bestehenden «ClickHouse»-Cluster verschoben:

Wir haben die Haupt-MySQL-Datenbank so entlastet, dass wir sie auf demselben Rechner wie den «Zabbix»-Server zusammenführen und auf einen dedizierten Server für MySQL verzichten konnten.

Wie funktioniert das Polling in Zabbix?

Vor 4 Monaten

MM: – Na, kann man die Probleme mit der Datenbank jetzt vergessen?

MT: – Genau! Eine weitere Herausforderung, die wir angehen müssen, ist die langsame Datensammlung. Zurzeit sind alle unsere 15 Proxiserver mit SNMP-Prozessen und Polling überlastet. Wir haben keine andere Wahl, als immer neue Server einzurichten.

MM: – Hervorragend. Aber erzähl mir zuerst, wie das Polling in Zabbix funktioniert?

MT: – Kurz gesagt gibt es 20 Metriktypen und ein Dutzend Möglichkeiten, diese zu erhalten. Zabbix kann Daten entweder im „Request-Response“-Modus sammeln oder neue Daten über die „Trapper-Schnittstelle“ abwarten.

Es ist erwähnenswert, dass dieser Ansatz (Trapper) im ursprünglichen Zabbix der schnellste ist.

Es gibt Proxiserver zur Lastverteilung:

Proxys können die gleichen Sammlungsmöglichkeiten wie der Zabbix-Server ausführen, indem sie Aufgaben von diesem erhalten und die gesammelten Metriken über die Trapper-Schnittstelle zurücksenden. Dies wird als offizieller empfohlener Ansatz zur Lastverteilung betrachtet. Proxys sind auch nützlich für die Überwachung von Remote-Infrastrukturen, die über NAT oder langsame Verbindungen arbeiten:

MM: – Mit der Architektur ist alles klar. Wir müssen die Quellcodes betrachten...

Ein paar Tage später

Die Geschichte darüber, wie nmap fping besiegte

MM: – Es scheint, als hätte ich etwas gefunden.

MT: – Erzähl mir mehr!

MM: – Ich habe festgestellt, dass Zabbix bei Verfügbarkeitsprüfungen maximal 128 Hosts gleichzeitig überprüft. Ich habe versucht, diese Zahl auf 500 zu erhöhen und den Paketintervall in ihrem Ping zu entfernen – das hat die Leistung verdoppelt. Aber ich hätte gerne noch höhere Zahlen.

MT: – In meiner Praxis muss ich manchmal die Verfügbarkeit von Tausenden von Hosts überprüfen, und nichts ist schneller als nmap. Ich bin mir sicher, dass dies der schnellste Weg ist. Lass es uns ausprobieren! Wir müssen die Anzahl der Hosts pro Iteration erheblich erhöhen.

MM: – Mehr als fünfhundert überprüfen? 600?

MT: – Mindestens ein paar Tausend.

MM: – Okay. Das Wichtigste, was ich sagen wollte: Ich habe herausgefunden, dass die meisten Abfragen in Zabbix synchron durchgeführt werden. Wir müssen das unbedingt auf asynchron umstellen. Dann können wir die Anzahl der Metriken, die von den Pollern gesammelt werden, drastisch erhöhen, insbesondere wenn wir die Anzahl der Metriken pro Iteration steigern.

MT: – Klasse! Und wann?

MM: – Wie üblich, gestern.

MT: – Wir haben beide Versionen von fping und nmap verglichen:

Bei einer großen Anzahl von Hosts war nmap erwartungsgemäß bis zu fünfmal effektiver. Da nmap nur die Erreichbarkeit und die Antwortzeit prüft, haben wir die Verlustberechnungen in Trigger verschoben und die Prüfintervalle für die Erreichbarkeit erheblich verkürzt. Die optimale Anzahl an Hosts für nmap haben wir bei etwa 4.000 pro Iteration gefunden. Nmap ermöglichte es uns, die CPU-Kosten für die Erreichbarkeitsprüfungen um das Dreifache zu senken und das Intervall von 120 Sekunden auf 10 zu reduzieren.

Optimierung des Pollings

MM: – Danach beschäftigten wir uns mit den Pollern. Besonders interessiert haben uns SNMP-Abfragen und Agenten. In „Zabbix“ wird das Polling synchron durchgeführt, und es wurden spezielle Maßnahmen ergriffen, um die Effizienz des Systems zu erhöhen. Im synchronen Modus führt die Nichterreichbarkeit von Hosts zu einer erheblichen Verschlechterung des Pollings. Es gibt ein ganzes System von Zuständen und spezielle Prozesse – die sogenannten unreachable-Poller, die nur mit nicht erreichbaren Hosts arbeiten:

Dies ist ein Kommentar, der die Zustandsmatrix demonstriert, sowie die gesamte Komplexität der Übergangssysteme, die erforderlich sind, damit das System effizient bleibt. Darüber hinaus ist das synchrone Polling selbst relativ langsam:

Das ist der Grund, warum Tausende von Poller-Threads über zehn Proxys nicht die benötigte Datenmenge für uns sammeln konnten. Die asynchrone Implementierung löste nicht nur Probleme mit der Anzahl der Threads, sondern vereinfachte auch erheblich das System für den Zustand nicht erreichbarer Hosts, da die maximale Wartezeit bei beliebiger Anzahl in einer Polling-Iteration 1 Timeout betrug.

Zusätzlich haben wir das Polling-System für SNMP-Anfragen modifiziert und weiterentwickelt. Das Problem ist, dass die meisten nicht gleichzeitig auf mehrere SNMP-Anfragen reagieren können. Daher haben wir einen hybriden Modus geschaffen, bei dem das SNMP-Polling desselben Hosts asynchron durchgeführt wird:

Dies wird für eine gesamte Gruppe von Hosts durchgeführt. In diesem Modus ist das Ergebnis letztlich nicht langsamer als bei einer vollständig asynchronen Lösung, da die Abfrage von anderthalbhundert SNMP-Werten dennoch viel schneller ist als 1 Timeout.

Unsere Experimente haben gezeigt, dass die optimale Anzahl von Anfragen in einer Iteration etwa 8.000 bei SNMP-Polling beträgt. Insgesamt hat der Übergang zum asynchronen Modus die Polling-Leistung um das 200-Fache und in einigen Fällen um mehrere Hundertmal beschleunigt.

MT: Die durchgeführten Optimierungen des Pollings haben gezeigt, dass wir nicht nur alle Proxys loswerden können, sondern auch die Intervalle bei vielen Überprüfungen verkürzen. Proxys werden nicht mehr benötigt, um die Last zu verteilen.

Vor etwa drei Monaten

Ändere die Architektur – erhöhe die Last!

MM: – Na, Max, ist es Zeit für die Produktion? Ich brauche einen leistungsstarken Server und einen guten Ingenieur.

MT: – Gut, lass uns planen. Es wird Zeit, die stagnierenden 5.000 Metriken pro Sekunde zu überwinden.

Der Morgen nach dem Upgrade

MT: – Misha, wir haben uns aktualisiert, aber bis zum Morgen sind wir zurückgefallen... Rate, welche Geschwindigkeit wir erreicht haben?

MM: – Maximal etwa 20.000.

MT: – Aha, 25! Leider sind wir wieder da, wo wir angefangen haben.

MM: – Warum ist das so? Haben wir eine Diagnose gemacht?

MT: – Ja, natürlich! Hier zum Beispiel ein interessantes top:

MM: – Lass uns schauen. Ich sehe, dass wir eine riesige Anzahl von Polling-Streams ausprobiert haben:

Aber wir konnten das System nicht einmal zur Hälfte nutzen:

Und die gesamte Leistung ist ziemlich gering, etwa 4.000 Metriken pro Sekunde:

Gibt es noch etwas?

MT: – Ja, strace eines der Poller:

MM: – Hier sieht man deutlich, dass der Polling-Prozess auf «Semaphoren» wartet. Das sind Sperren:

MT: – Unverständlich.

MM: – Sieht so aus, als ob wir hier in einer Situation sind, in der viele Threads versuchen, auf Ressourcen zuzugreifen, die nur von einem zur gleichen Zeit genutzt werden können. Das Einzige, was sie tun können, ist, diese Ressource zeitlich aufzuteilen:

Und die gesamte Leistungsfähigkeit bei der Nutzung solcher Ressourcen ist auf die Geschwindigkeit eines Kerns begrenzt:

Es gibt zwei Wege, um dieses Problem zu lösen.

Entweder das Hardware-Upgrade der Maschinen, indem man auf schnellere Kerne umsteigt:

Oder die Architektur zu ändern und gleichzeitig die Last:

MT: – Übrigens, auf der Testmaschine verwenden wir weniger Kerne als auf der Produktionsmaschine, dafür sind diese jedoch etwa 1,5 mal schneller in der Taktfrequenz!

MM: – Ist das klar? Wir müssen den Server-Code überprüfen.

Datenpfad im Zabbix-Server

MT: – Um das zu verstehen, haben wir angefangen zu analysieren, wie die Daten innerhalb des 'Zabbix'-Servers übertragen werden:

Tolle Grafik, oder? Lassen Sie uns Schritt für Schritt durchgehen, um alles etwas klarer zu machen. Es gibt Threads und Services, die für das Sammeln der Daten verantwortlich sind:

Die gesammelten Metriken werden dann über einen Socket an den Preprocessor-Manager übermittelt, wo sie in eine Warteschlange aufgenommen werden:

Der Preprozessor-Manager überträgt Daten an seine Worker, die die Vorverarbeitungsanweisungen ausführen und sie über denselben Socket zurücksendet.

Anschließend speichert der Preprozessor-Manager sie im Verlaufscache.

Dort werden sie von den Verlaufssynkern abgerufen, die eine Vielzahl von Funktionen ausführen: zum Beispiel das Berechnen von Triggern, das Auffüllen des Werte-Caches und, das Wichtigste, das Speichern von Metriken im Verlaufsspeicher. Insgesamt ist der Prozess komplex und sehr verworren.

MM: Das Erste, was uns auffiel, war, dass die meisten Threads um den sogenannten "Konfigurationscache" (Speicherbereich, in dem alle Serverkonfigurationen gespeichert werden) konkurrieren. Insbesondere treten viele Sperren bei den Threads auf, die für das Abrufen von Daten verantwortlich sind:

…da in der Konfiguration nicht nur die Metriken mit ihren Parametern gespeichert sind, sondern auch die Warteschlangen, aus denen die Poller Informationen darüber erhalten, was sie als Nächstes tun sollen. Wenn es viele Poller gibt und einer die Konfiguration blockiert, warten die anderen auf Anfragen:

Poller sollten nicht miteinander in Konflikt stehen.

Deshalb haben wir als erstes die Warteschlange in vier Teile unterteilt und den Pollern in einer sicheren Umgebung erlaubt, diese Teile gleichzeitig zu blockieren:

Das hat den Wettbewerb um den Konfigurations-Cache ausgeschaltet und die Geschwindigkeit der Poller erheblich gesteigert. Doch dann standen wir vor dem Problem, dass der Preprocessor-Manager begann, die Aufgabenwarteschlange anzusammeln:

Der Preprocessor-Manager muss in der Lage sein, Prioritäten zu setzen.

Dies geschah in Fällen, in denen ihm die Leistung fehlte. Alles, was er tun konnte, war, die Anfragen der Datensammlungsprozesse zu sammeln und sie im Puffer zu speichern, bis er den gesamten Speicher aufbrauchte und abstürzte:

Um dieses Problem zu lösen, haben wir einen zweiten Sockel hinzugefügt, der speziell für die Worker vorgesehen war:

Somit konnte der Preprocessor-Manager seine Arbeit priorisieren und im Falle eines Pufferausbaus die Aufgabe verlangsamen, um den Workern die Möglichkeit zu geben, diesen Puffer abzuholen:

Dann haben wir festgestellt, dass eine der Ursachen für die Verlangsamung die Worker selbst waren, da sie um eine Ressource konkurrierten, die für ihre Arbeit völlig unwichtig war. Dieses Problem haben wir als Bugfix dokumentiert, und in den neuen Versionen von „Zabbix“ wurde es bereits behoben:

Durch die Erhöhung der Anzahl der Sockets – erzielen wir Ergebnisse

Der Preprocessor-Manager stellte sich als Engpass heraus, da er nur einen Thread hatte. Er war an der Geschwindigkeit des Kernels begrenzt und erreichte eine maximale Geschwindigkeit von etwa 70.000 Metriken pro Sekunde:

Daher haben wir vier Preprocessor-Manager mit vier Satz-Konfigurationen erstellt:

Und das erlaubte es, die Geschwindigkeit auf etwa 130.000 Metriken zu erhöhen:

Die nichtlineare Wachstumsrate erklärt sich daraus, dass es einen Wettbewerb um den Cache der Historie gab. Vier Preprocessor-Manager und Historie-Synchronisierer konkurrierten darum. Zu diesem Zeitpunkt erhielten wir auf der Testmaschine etwa 130.000 Metriken pro Sekunde und nutzten dabei etwa 95 % der CPU:

Vor etwa 2,5 Monaten

Der Verzicht auf die SNMP-Community erhöhte die NVPs um das Eineinhalbfache

MM: – Max, ich brauche eine neue Testmaschine! In die aktuelle passen wir nicht mehr rein.

MT: – Was gibt es jetzt?

MM: – Momentan – 130k NVPs und der Prozessor ist „in der Warteschlange“.

MT: – Wow! Cool! Wait, I have two questions. According to my calculations, we need around 15,000 to 20,000 metrics per second. Why do we need more?

MM: – I want to finish this properly. I want to see how much we can get out of this system.

MT: – But…

MM: – But it’s useless for business.

MT: – Understood. And my second question: can we maintain what we have now on our own, without a developer's help?

MM: – I don't think so. Changing how the configuration cache works is a problem. It involves changes in most streams and is quite complex to support. Most likely, it will be very difficult to maintain.

MT: – Then we need some alternative.

MM: – There is an option. We can switch to faster cores while dropping the new locking system. We will still achieve a performance of 60,000 to 80,000 metrics. Meanwhile, we can keep all the other code. "ClickHouse" and asynchronous polling will work. And it will be easy to maintain.

MT: – Wonderful! I suggest we stop here.

Nach der Optimierung der Server-Infrastruktur konnten wir endlich den neuen Code produktiv einsetzen. Wir haben auf einige Änderungen verzichtet, um auf eine Maschine mit schnellen Kernen umzusteigen und die Anzahl der Änderungen im Code zu minimieren. Zudem haben wir die Konfiguration vereinfacht und wo immer möglich auf Makros in den Datenelementen verzichtet, da diese zusätzliche Blockierungen verursachen.

Zum Beispiel hat der Verzicht auf das in der Dokumentation und in Beispielen häufig verwendete Makro snmp-community in unserem Fall die NVPs um etwa 1,5 Mal beschleunigt.

Nach zwei Tagen in der Produktivumgebung

Wir entfernen die Pop-ups der Vorfallhistorie

MT: – Misha, wir nutzen das System seit zwei Tagen und alles funktioniert. Aber nur, wenn alles reibungslos läuft! Wir hatten geplante Arbeiten mit der Übertragung eines großen Netzwerksegments und haben erneut manuell überprüft, was funktioniert und was nicht.

MM: – Das kann nicht sein! Wir haben alles zehnmal überprüft. Der Server verarbeitet sogar die vollständige Netzwerkunzugänglichkeit sofort.

MT: – Ich verstehe das alles: der Server, die Datenbank, top, austat, die Protokolle – alles ist schnell… Aber wir sehen uns die Web-Oberfläche an, und dort zeigt der Prozessor „in der Warteschlange“ auf dem Server und das hier:

MM: – Verstanden. Lass uns die Webanwendung ansehen. Wir haben festgestellt, dass bei einer hohen Anzahl aktiver Vorfälle die meisten operativen Widgets sehr langsam wurden:

Der Grund dafür war die Generierung von Pop-ups mit den Vorfallhistorien, die für jedes Element in der Liste erzeugt wurden. Daher haben wir diese Fensteraufrufe gestrichen (5 Zeilen im Code auskommentiert), und das hat unsere Probleme gelöst.

Die Ladezeit der Widgets, selbst bei vollständiger Nichterreichbarkeit, hat sich von mehreren Minuten auf die für uns akzeptablen 10-15 Sekunden reduziert, und die Historie kann weiterhin durch einen Klick auf die Zeit angesehen werden:

Nach der Arbeit. Vor 2 Monaten

MT: – Mischa, gehst du weg? Ich wollte mit dir sprechen.

MM: – Ich hatte nicht vor. Gibt es wieder ein Problem mit Zabbix?

MT: – Nee, ganz ruhig! Ich wollte einfach sagen: Es funktioniert alles, danke! Das Bier geht auf mich.

Zabbix ist effektiv

Zabbix ist ein recht vielseitiges und funktionsreiches System. Es kann durchaus für kleinere Installationen "out of the box" verwendet werden, aber mit steigenden Anforderungen muss es optimiert werden. Für die Speicherung großer Archive von Metriken verwenden Sie geeignete Speicherlösungen:

• Sie können die integrierten Funktionen nutzen, indem Sie die Integration mit «Elasticsearch» oder den Export von Historien in Textdateien verwenden (verfügbar ab der vierten Version);
• Sie können auch von unserer Erfahrung und der Integration mit «ClickHouse» profitieren.

Um die Geschwindigkeit der Metriksammlung drastisch zu erhöhen, sammeln Sie diese asynchron und übermitteln Sie sie über die Trapper-Schnittstelle an den «Zabbix»-Server; alternativ können Sie einen Patch für die Asynchronität der Poller von «Zabbix» verwenden.

«Zabbix» ist in C geschrieben und sehr effizient. Bestimmte architektonische Engpässe ermöglichen es, die Leistung zusätzlich zu steigern, und unserer Erfahrung nach erhalten wir über 100.000 Metriken auf einer Einzelprozessmaschine.

Jener Patch für Zabbix

MM: – Ich möchte ein paar Punkte hinzufügen. Der gesamte aktuelle Bericht, alle Tests und Zahlen beziehen sich auf die Konfiguration, die wir verwenden. Daraus erfassen wir derzeit etwa 20.000 Metriken pro Sekunde. Wenn Sie herausfinden möchten, ob es bei Ihnen funktioniert – können Sie vergleichen. Das, was heute vorgestellt wurde, ist als Patch auf GitHub verfügbar: github.com/miklert/zabbix

Der Patch umfasst:

• volle Integration mit ClickHouse (sowohl für Zabbix-Server als auch für das Frontend);
• Lösungen für Probleme mit dem Preprocessor-Manager;
• asynchrones Polling.

Der Patch ist mit der gesamten Version 4 kompatibel, einschließlich LTS. Höchstwahrscheinlich wird er mit minimalen Änderungen auch auf Version 3.4 funktionieren.

Vielen Dank für Ihre Aufmerksamkeit.

Fragen

Frage aus dem Publikum (im Folgenden – A): – Guten Tag! Haben Sie Pläne für eine intensivere Zusammenarbeit mit dem Zabbix-Team oder umgekehrt, damit es nicht nur ein Patch, sondern ein normales Verhalten von Zabbix wird?

MM: – Ja, einige Änderungen werden wir definitiv committen. Einige Dinge werden im Patch verbleiben.

A: – Vielen Dank für den großartigen Vortrag! Könnten Sie bitte bestätigen, ob die Unterstützung von Zabbix nach der Anwendung des Patches bestehen bleibt und wie man auf höhere Versionen aktualisieren kann? Wird es möglich sein, Zabbix nach Ihrem Patch auf 4.2 oder 5.0 zu aktualisieren?

MM: – Über den Support kann ich nichts sagen. Wäre ich der Support für «Zabbix», würde ich vermutlich nein sagen, da es sich um fremden Code handelt. Was die Codebasis 4.2 betrifft, so lautet unsere Position: „Wir werden mit der Zeit gehen und uns selbst auf die nächste Version aktualisieren“. Daher werden wir eine Zeit lang einen Patch für die aktualisierten Versionen bereitstellen. Ich habe bereits in meinem Bericht gesagt: Die Anzahl der Änderungen zwischen den Versionen ist bisher relativ gering. Ich denke, der Übergang von 3.4 auf 4 hat uns etwa 15 Minuten gekostet. Es gab einige Änderungen, aber nichts wirklich Wichtiges.

A: – Das heißt, Sie planen, Ihren Patch zu unterstützen, und man kann ihn bedenkenlos in der Produktion einsetzen, während man zukünftig auf irgendeine Weise Updates erhält?

MM: – Das empfehlen wir dringend. Es löst viele Probleme für uns.

MT: – Ich möchte nochmals betonen, dass Änderungen, die die Architektur nicht betreffen und sich nicht auf Blockierungen oder Warteschlangen beziehen, modular sind und in separaten Modulen erfolgen. Selbst bei geringfügigen Änderungen können sie relativ einfach unterstützt werden.

MM: – Wenn Sie an Details interessiert sind, nutzt ClickHouse eine sogenannte Historienbibliothek. Diese ist entkoppelt – es ist eine Kopie der Unterstützung für Elasticsearch, was bedeutet, dass sie konfigurationsveränderbar ist. Das Polling ändert nur die Poller. Wir glauben, dass das langfristig funktionieren wird.

A: – Vielen Dank. Können Sie mir sagen, ob es eine Dokumentation zu den vorgenommenen Änderungen gibt?

MM: – Die Dokumentation ist ein Patch. Offensichtlich ergeben sich mit der Einführung von ClickHouse und den neuen Pollertypen neue Konfigurationsmöglichkeiten. Über den Link in der letzten Folie finden Sie eine kurze Beschreibung, wie Sie es verwenden können.

Zur Ersetzung von fping durch nmap

A: – Wie haben Sie das letztlich umgesetzt? Können Sie konkrete Beispiele nennen: Haben Sie Strapper und ein externes Skript? Was überprüft letztendlich so schnell eine so große Anzahl von Hosts? Wie beschaffen Sie diese Hosts? Muss man nmap diese irgendwie zuführen, von irgendwoher holen, ablegen und dann etwas starten?

MM: – Das ist eine gute Frage! Hier ist der Kern: Wir haben die Bibliothek (ICMP-Ping, Teil von „Zabbix“) für ICMP-Checks modifiziert, bei denen die Anzahl der Pakete auf eins (1) gesetzt ist, und der Code versucht, nmap zu verwenden. Das bedeutet, dass es sich um interne Vorgänge von „Zabbix“ handelt, was nun die internen Funktionen des Pingers beeinflusst. Daher ist keine Synchronisierung oder Verwendung eines Trappers erforderlich. Dies wurde bewusst so gestaltet, um das System intakt zu lassen und nicht zwei Systembasen synchronisieren zu müssen: was zu überprüfen ist, über den Poller hochzuladen und ob der Upload bei uns nicht kaputt gegangen ist? Das ist viel einfacher.

A: – Funktioniert das auch für Proxys?

MM: – Ja, aber wir haben das nicht überprüft. Der Polling-Code ist sowohl in „Zabbix“ als auch auf dem Server identisch. Es sollte funktionieren. Ich betone nochmal: Die Systemleistung ist so, dass wir keinen Proxy benötigen.

MT: – Die richtige Antwort auf die Frage lautet: „Warum benötigen Sie bei einem solchen System einen Proxy?“ Nur wegen NAT oder um über einen langsamen Kanal zu überwachen...

A: – Nutzen Sie „Zabbix“ als Alarmsystem, wenn ich das richtig verstanden habe? Oder sind die Grafiken (wo die Archivschicht ist) in ein anderes System wie Grafana gewandert? Oder verwenden Sie diese Funktionalität nicht?

MM: – Ich möchte noch einmal betonen: Wir haben eine vollständige Integration durchgeführt. Wir leiten die Historie in „ClickHouse“ weiter, haben aber dabei das PHP-Frontend geändert. Das PHP-Frontend greift auf „ClickHouse“ zu und erstellt alle Grafiken von dort. Ehrlich gesagt, haben wir auch einen Teil, der aus demselben „ClickHouse“, aus denselben Daten von „Zabbix“ Informationen in anderen grafischen Darstellungssystemen aufbereitet.

MT: – Auch in „Grafana“.

Wie wurde die Entscheidung über die Bereitstellung von Ressourcen getroffen?

A: – Teilen Sie uns bitte ein wenig über die internen Vorgänge mit. Wie kam es zu der Entscheidung, dass Ressourcen für eine ernsthafte Überarbeitung des Produkts bereitgestellt werden müssen? Das birgt schließlich bestimmte Risiken. Und bitte sagen Sie uns im Kontext dessen, dass Sie neue Versionen unterstützen möchten: Wie rechtfertigt sich diese Entscheidung aus der Sicht des Managements?

MM: – Offensichtlich haben wir die Dramatik der Geschichte nicht sehr gut erzählt. Wir befanden uns in einer Situation, in der etwas getan werden musste, und haben im Grunde genommen zwei parallele Teams gebildet:

• Eine Person war mit der Einführung eines Monitoringsystems beschäftigt, das neue Methoden nutzt: Monitoring als Dienstleistung, ein standardisiertes Set an Open-Source-Lösungen, die wir kombinieren und anschließend versuchen, die Geschäftsprozesse zu ändern, um mit dem neuen Monitoring-System zu arbeiten.
• Parallel dazu hatten wir einen enthusiastischen Programmierer, der sich damit beschäftigte (über sich selbst). So kam es, dass er gewonnen hat.

A: – Und wie groß ist das Team?

MT: – Es steht vor Ihnen.

A: – Das heißt, wie immer braucht man einen Passionierten?

MM: – Ich weiß nicht, was ein Passionierter ist.

A: – In diesem Fall scheinen Sie es zu sein. Vielen Dank, Sie sind großartig.

MM: – Danke.

Über Patches für Zabbix

A: – Ist es möglich, Ihre Lösung für ein System anzupassen und zu patchen, das Proxys verwendet (z.B. in einigen verteilten Systemen), sagen wir, für die Poller, Proxys und teilweise für den Präprozessor von Zabbix; und deren Interaktion? Ist es möglich, bestehende Entwicklungen für ein System mit mehreren Proxys zu optimieren?

MM: – Ich weiß, dass der «Zabbix»-Server über einen Proxy eingerichtet wird (der Code wird kompiliert und generiert). Wir haben das nicht in der Produktion getestet. Ich bin mir nicht sicher, aber meiner Meinung nach wird der Preprocessor-Manager nicht im Proxy verwendet. Die Aufgabe des Proxys besteht darin, eine Reihe von Metriken aus «Zabbix» zu erfassen, sie zu spollieren (er speichert auch die Konfiguration, die lokale Datenbank) und sie an den «Zabbix»-Server zurückzugeben. Die Vorverarbeitung erfolgt später durch den Server, wenn er die Daten erhält.

Das Interesse am Proxy ist verständlich. Wir werden das überprüfen. Es ist ein interessantes Thema.

A: – Die Idee war folgendermaßen: Wenn man die Poller patchen kann, kann man sie auch im Proxy patchen und die Interaktion mit dem Server patchen, während der Preprocessor nur auf den Server angepasst wird.

MM: – Ich denke, es ist sogar einfacher. Sie nehmen den Code, wenden den Patch an, konfigurieren ihn nach Ihren Anforderungen – erstellen Proxys (zum Beispiel mit ODBC) und verteilen den gepatchten Code in den Systemen. Wo nötig, stellen Sie Proxys bereit, wo nötig, den Server.

A: – Zusätzlich muss die Übertragung vom Proxy zum Server wahrscheinlich nicht weiter gepatcht werden?

MT: – Nein, sie ist standardmäßig.

MM: – Tatsächlich wurde eine der Ideen nicht vorgestellt. Wir haben immer ein Gleichgewicht zwischen dem Aufkommen neuer Ideen und der Anzahl der Änderungen sowie der Wartungsfreundlichkeit gewahrt.

Ein wenig Werbung 🙂

Danke, dass Sie bei uns bleiben. Gefallen Ihnen unsere Artikel? Möchten Sie mehr interessante Inhalte sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder uns Ihren Freunden empfehlen. Cloud-VPS für Entwickler ab 4,99 $, eine einzigartige Alternative zu Einsteiger-Servern, die wir für Sie entwickelt haben: Alles über VPS (KVM) E5-2697 v3 (6 Kerne) 10GB DDR4 480GB SSD 1Gbps ab 19 $ oder wie man einen Server richtig teilt? (Verfügbar sind Optionen mit RAID1 und RAID10, bis zu 24 Kerne und bis zu 40GB DDR4).

Dell R730xd im Equinix Tier IV Rechenzentrum in Amsterdam zum halben Preis? Nur bei uns 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB ab 199 $ in den Niederlanden! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — ab 99 $! Lesen Sie darüber Wie man eine Unternehmenskosten-Infrastruktur mit Dell R730xd E5-2650 v4-Servern für ein paar Euro aufbaut?

Quelle: habr.com