HighLoad++, Mikhail Makurov, Maxim Chernetsov (Intersvyaz): Zabbix, 100kNVPS auf einem Server

Die nächste Konferenz HighLoad++ findet am 6. und 7. April 2020 in Sankt Petersburg statt. Details und Tickets unter diesem Link. HighLoad++ Moskau 2018. Saal „Moskau“. 9. November, 15:00. Thesen und Präsentation.

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

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

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

MM: – Darf ich Maxim vorstellen. Max ist ein talentierter Ingenieur, der beste Netzwerker, den ich kenne. Maxim beschäftigt sich mit Netzwerken und Services, deren Entwicklung und Betrieb.

MT: – Ich möchte über Mikhail erzählen. Mikhail ist C-Entwickler. Er hat einige hochgradig belastete Lösungen zur Verarbeitung von Traffic für unser Unternehmen geschrieben. Wir leben und arbeiten im Ural, in der Stadt der rauen Männer, Tscheljabinsk, in der Firma „Intersvyaz“. Unser Unternehmen ist Anbieter von Internet- und Kabelfernsehdiensten für eine Million Menschen in 16 Städten.

MM: – Und es ist zu sagen, dass „Intersvyaz“ viel mehr ist als nur ein Provider, es ist ein IT-Unternehmen. Die meisten unserer Lösungen werden durch unsere IT-Abteilung erstellt.

A: von Servern, die Traffic verarbeiten, bis hin zu Call-Centern und mobilen Anwendungen. In der IT-Abteilung arbeiten jetzt etwa 80 Personen mit sehr unterschiedlichen Kompetenzen.

Ü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 Monitoring-System „out of the box“ auf Unternehmensebene. Es bietet viele Funktionen, die das Leben erleichtern: ausgeklügelte Eskalationsregeln, API für Integration, Gruppierung und automatische Erkennung von Hosts und Metriken. Zabbix hat sogenannte Skalierungsmittel – Proxys. Zabbix ist ein Open-Source-System.

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

• Server. In C geschrieben. Mit einer ziemlich komplexen Verarbeitung und Übertragung von Informationen zwischen Threads. Alle Verarbeitungen erfolgen dort: vom Empfang bis zur Speicherung in der Datenbank.
• Alle Daten werden in einer Datenbank gespeichert. Zabbix unterstützt MySQL, PostgreSQL und Oracle.
• Die Webschnittstelle ist in PHP geschrieben. Die meisten Systeme werden mit dem Apache-Server geliefert, arbeiten aber effizienter in Kombination mit nginx + php.

Heute möchten wir eine Geschichte aus dem Leben unseres Unternehmens erzählen, die mit „Zabbix“ verbunden ist...

Eine Geschichte aus dem Leben des Unternehmens „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 erreicht habe – ich habe etwas zu besprechen. Wir hatten wieder Probleme mit der Überwachung. Während eines großen Ausfalls hat alles gehakt, und es gab keine Informationen über den Zustand des Netzwerks. Leider passiert das schon zum wiederholten Mal. Ich brauche deine Hilfe. Lass uns sicherstellen, dass unsere Überwachung unter allen Umständen funktioniert!

MM: – Aber lass uns zuerst synchronisieren. Ich habe da schon seit ein paar Jahren nicht mehr hineingeschaut. Soweit ich mich erinnere, haben wir vor etwa 8 Jahren Nagios aufgegeben und sind zu „Zabbix“ gewechselt. Und jetzt haben wir anscheinend 6 leistungsstarke Server und etwa ein Dutzend Proxys. Verwirre ich mich nicht?

MT: – Fast. 15 Server, von denen einige virtuelle Maschinen sind. Das Wichtigste ist, dass uns das nicht hilft, wenn wir es am nötigsten brauchen. Bei einem Ausfall – die Server hängen und man sieht nichts. Wir haben versucht, die Konfiguration zu optimieren, aber das hat keine merkliche Leistungssteigerung gebracht.

MM: – Verstanden. Hast du etwas untersucht, etwas aus der Diagnose gesammelt?

MT: – Das erste, womit man es zu tun hat, ist die DB. MySQL ist sowieso ständig ausgelastet, während es neue Metriken speichert, und wenn „Zabbix“ anfängt, eine Menge Ereignisse zu generieren – geht die Datenbank buchstäblich für mehrere Stunden in den Standby. Von der Optimierung der Konfiguration habe ich dir schon erzählt, und in diesem Jahr haben wir die Hardware aktualisiert: Auf den Servern stehen über einhundert Gigabyte RAM und Speicherarrays auf SSD-RAIDs – es macht keinen Sinn, es linear weiter zu vergrößern. Was sollen wir tun?

MM: – Verstanden. Tatsächlich ist MySQL eine LTP-Datenbank. Anscheinend ist sie nicht mehr für die Speicherung von Archiven unserer Metrikgröße geeignet. Lass uns das klären.

MT: – Lass es uns tun!

Integration von Zabbix und Clickhouse als Ergebnis eines Hackathons

Nach einiger Zeit erhielten wir interessante Daten:

Der größte Teil des Raums in unserer Datenbank war mit dem Archiv von Metriken belegt und weniger als 1 % wurde für Konfigurationen, Vorlagen und Einstellungen verwendet. Zu diesem Zeitpunkt hatten wir schon seit über einem Jahr eine Big Data-Lösung auf Basis von Clickhouse in Betrieb. Der Weg, den wir einschlagen sollten, war für uns offensichtlich. Beim diesjährigen Frühlings-Hackathon entwickelte ich eine Integration von Zabbix mit Clickhouse für den Server und das Frontend. Zu diesem Zeitpunkt unterstützte Zabbix bereits ElasticSearch, und wir entschieden uns, diese zu vergleichen.

Vergleich Clickhouse und Elasticsearch

MM: – Für den Vergleich erzeugten wir eine Last, die der von Zabbix-Server entsprach, und beobachteten, wie sich die Systeme verhalten würden. Wir schrieben Daten in Paketen von 1000 Zeilen und verwendeten CURL. Wir erwarteten im Voraus, dass Clickhouse für das Lastprofil von Zabbix effizienter sein würde. Die Ergebnisse übertrafen sogar unsere Erwartungen:

Unter den gleichen Bedingungen schrieb Clickhouse dreimal so viele Daten während der Tests. Beide Systeme konsumierten sehr effizient (geringe Ressourcennutzung), wenn sie Daten lasen. Aber ElasticSearch benötigte eine große Menge an Prozessorleistung beim Schreiben:

Insgesamt übertraf Clickhouse ElasticSearch erheblich in Bezug auf den CPU-Verbrauch und die Geschwindigkeit. Durch die Datenkompression benötigt Clickhouse 11-mal weniger Speicherplatz auf der Festplatte und führt etwa 30-mal weniger Festplattenoperationen durch:

MT: – Ja, die Arbeit mit dem Festplattensystem von Clickhouse ist sehr effizient umgesetzt. Für Datenbanken kann man riesige SATA-Festplatten verwenden und erreicht Schreibgeschwindigkeiten von Hunderttausenden von Zeilen pro Sekunde. Die Systemunterstützung für Sharding und Replikation ist "out of the box" verfügbar und es ist recht einfach, es einzurichten. Wir sind mit seinem Einsatz über ein Jahr mehr als zufrieden.

Zur Ressourcenschonung kann Clickhouse neben der bestehenden Hauptdatenbank installiert werden, was eine Menge an Prozessorzeit und Festplattenoperationen spart. Wir haben das Archiv der Metriken auf bereits vorhandene Clickhouse-Cluster übertragen:

Wir haben die Haupt-MySQL-Datenbank so stark entlastet, dass wir sie auf derselben Maschine mit dem Zabbix-Server zusammenführen und auf einen dedizierten Server für MySQL verzichten konnten.

Wie funktioniert Polling in Zabbix?

Vor 4 Monaten

MM: – Na, können wir die Probleme mit der Datenbank hinter uns lassen?

MT: Das ist genau richtig! Eine andere Aufgabe, die wir lösen müssen, ist die langsame Datensammlung. Jetzt sind all unsere 15 Proxy-Server mit SNMP- und Polling-Prozessen überlastet. Und es gibt keine anderen Optionen, als immer neue Server hinzuzufügen.

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

MT: Kurz gesagt, es gibt 20 Metriktypen und eine Handvoll Möglichkeiten, diese zu erheben. Zabbix kann Daten entweder im Anfrage-Antwort-Modus sammeln oder neue Daten über die Trapper-Schnittstelle abwarten.

Es ist erwähnenswert, dass diese Methode (Trapper) im Original-Zabbix die schnellste ist.

Es gibt Proxys zur Lastenverteilung:

Proxys können die gleichen Sammelfunktionen wie der Zabbix-Server ausführen, indem sie Aufgaben von ihm erhalten und die gesammelten Metriken genau über die Trapper-Schnittstelle zurücksenden. Dies ist die offiziell empfohlene Methode zur Lastenverteilung. Proxys sind auch nützlich für das Monitoring von remote Infrastruktur, die über NAT oder eine langsame Verbindung arbeitet:

MM: Die Architektur ist also klar. Wir müssen uns die Quellcodes ansehen...

Ein paar Tage später

Die Geschichte darüber, wie nmap fping besiegt hat

MM: Es scheint, dass ich etwas gefunden habe.

MT: Erzähl!

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 Inter-Paket-Intervall in ihrem Ping zu entfernen – das hat die Leistung verdoppelt. Aber ich hätte gerne größere Zahlen.

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

MM: Über 500 prüfen? 600?

MT: Mindestens ein paar Tausend.

MM: Okay. Das Wichtigste, was ich sagen wollte: Ich habe herausgefunden, dass das meiste Polling in Zabbix synchron erfolgt. Wir müssen es unbedingt auf asynchron umstellen. Dann können wir die Anzahl der von den Pollern gesammelten Metriken drastisch erhöhen, insbesondere wenn wir die Anzahl der Metriken pro Iteration erhöhen.

MT: Das klingt großartig! Und wann?

MM: Wie immer, gestern.

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

Auf einer großen Anzahl von Hosts war nmap erwartungsgemäß bis zu fünfmal effektiver. Da nmap lediglich die Verfügbarkeit und die Antwortzeiten überprüft, haben wir die Verlustzählung auf Trigger verschoben und die Überprüfungsintervalle erheblich verkürzt. Die optimale Anzahl an Hosts für nmap haben wir bei etwa 4.000 pro Iteration festgestellt. Nmap ermöglichte es uns, die CPU-Kosten für die Überprüfungen der Verfügbarkeit um drei Viertel zu senken und das Intervall von 120 Sekunden auf 10 zu reduzieren.

Optimierung des Pollings

MM: – Dann haben wir uns mit den Pollern beschäftigt. Hauptsächlich interessierte uns das SNMP-Monitoring und die Agenten. Im „Zabbix“ erfolgt das Polling synchron, und es wurden spezielle Maßnahmen ergriffen, um die Effizienz des Systems zu steigern. Im synchronen Modus führt die Unerreichbarkeit von Hosts zu einer erheblichen Verschlechterung des Polling. Es gibt ein ganzes System von Zuständen, spezielle Prozesse – sogenannte unerreichbare Poller, die nur mit unerreichbaren Hosts arbeiten:

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

Genau deshalb konnten Tausende von Poller-Threads auf einem Dutzend Proxys nicht die benötigte Menge an Daten für uns sammeln. Die asynchrone Implementierung löste nicht nur die Probleme mit der Anzahl der Threads, sondern vereinfachte auch das System von Zuständen unerreichbarer Hosts erheblich, da bei beliebiger Anzahl in einer Polling-Iteration die maximale Wartezeit 1 Timeout betrug:

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

Dies geschieht für eine ganze Gruppe von Hosts. Dieser Modus ist letztlich nicht langsamer als vollständig asynchron, da die Abfrage von 150 SNMP-Werten immer noch viel schneller ist als 1 Timeout.

Unsere Experimente haben gezeigt, dass die optimale Anzahl von Anfragen in einer Iteration etwa 8.000 beim SNMP-Polling beträgt. Insgesamt ermöglichte der Wechsel in den asynchronen Modus eine Steigerung der Polling-Leistung um das 200-Fache, um mehrere Hundertfache.

MT: Die erhaltenen Optimierungen des Pollings haben gezeigt, dass wir nicht nur alle Proxys loswerden können, sondern auch die Intervalle für viele Prüfungen verkürzen können, während Proxys als Mittel zur Lastverteilung nicht mehr benötigt werden.

Vor etwa drei Monaten

Ändere die Architektur – erhöhe die Last!

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

MT: – Gut, lass uns planen. Es ist höchste Zeit, von dem Stillstand von 5.000 Metriken pro Sekunde wegzukommen.

Der Morgen nach dem Upgrade

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

MM: – Höchstens 20.000.

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

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

MT: – Ja, natürlich! Hier ist beispielsweise ein interessantes Top:

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

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

Die Gesamtleistung ist recht gering, etwa 4.000 Metriken pro Sekunde:

Gibt es noch etwas?

MT: – Ja, strace von einem der Poller:

MM: – Hier sieht man klar, dass der Polling-Prozess auf 'Semaphore' wartet. Das sind Sperren:

MT: – Unverständlich.

MM: – Schau, das ähnelt einer Situation, in der viele Threads versuchen, mit Ressourcen zu arbeiten, auf die gleichzeitig nur einer zugreifen kann. Dann können sie nur diesen Resource zeitlich aufteilen:

Die Gesamtproduktivität bei der Arbeit mit einer solchen Ressource ist auf die Geschwindigkeit eines Kerns begrenzt:

Eine solche Problematik kann auf zwei Arten gelöst werden.

Die Hardware der Maschine aufrüsten, auf schnellere Kerne umsteigen:

Oder die Architektur und parallel die Last ändern:

MT: – Übrigens, auf der Testmaschine verwenden wir weniger Kerne als auf der Produktionsmaschine, aber sie sind dafür etwa 1,5-mal schneller in der Taktfrequenz pro Kern!

MM: – Verstehst du? Wir müssen den Servercode überprüfen.

Der Datenfluss 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? Lass uns Schritt für Schritt durchgehen, um es mehr oder weniger zu klären. Es gibt Threads und Dienste, die für die Datensammlung verantwortlich sind:

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

Der 'Preprocessor-Manager' übergibt die Daten an seine Worker, die die Vorverarbeitungsanweisungen ausführen und sie über denselben Socket zurückgeben:

Nach diesem Schritt speichert der Preprocessor-Manager sie im Verlauf-Cache:

Von dort holen sie sich die History-Synker, die viele Funktionen übernehmen: zum Beispiel das Berechnen von Triggern, das Füllen des Wert-Caches und, am wichtigsten, das Speichern von Metriken im Verlaufsspeicher. Insgesamt ist der Prozess komplex und ziemlich verwirrend.

MM: – Das erste, was wir festgestellt haben, ist, dass die meisten Threads um den sogenannten "Konfigurations-Cache" konkurrieren (ein Speicherbereich, in dem alle Serverkonfigurationen gespeichert sind). Insbesondere viele Sperren verursachen die Threads, die für das Abrufen von Daten verantwortlich sind:

…da in der Konfiguration nicht nur die Metriken mit ihren Parametern gespeichert werden, sondern auch die Warteschlangen, aus denen die Poller Informationen darüber entnehmen, was als nächstes zu tun ist. Wenn es viele Poller gibt und einer die Konfiguration sperrt, warten die anderen auf Anfragen:

Poller dürfen nicht in Konflikt geraten

Daher haben wir als Erstes die Warteschlange in 4 Teile geteilt und den Pollern unter sicheren Bedingungen erlaubt, diese Warteschlangen, diese Teile gleichzeitig zu sperren:

Dies beseitigte die Konkurrenz um den Konfigurations-Cache, und die Geschwindigkeit der Poller nahm erheblich zu. Aber dann erlebten wir, 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. Dann konnte er nur noch die Anfragen von den Datenbeschaffungsprozessen ansammeln und seinen Puffer stapeln, bis er den gesamten Speicher aufbrauchte und abstürzte:

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

Damit konnte der Preprocessor-Manager seine Arbeit priorisieren und im Falle einer Puffervergrößerung die Aufgabe des Abbremsens des Abrufs übernehmen, um den Workern die Möglichkeit zu geben, diesen Puffer abzuholen:

Dann stellten wir fest, dass einer der Gründe für die Verzögerung die Worker selbst waren, da sie um einen für ihre Arbeit völlig unwichtigen Ressourcen konkurrierten. Dieses Problem haben wir mit einem Bug-Fix behoben, und in den neuen Versionen von "Zabbix" ist es bereits gelöst:

Wir erhöhen die Anzahl der Sockets – wir erzielen Ergebnisse

Weiterhin wurde der Preprocessor-Manager zum Engpass, da dies ein einzelner Thread ist. Er stieß an die Geschwindigkeitsgrenze des Kerns, was eine maximale Geschwindigkeit von etwa 70.000 Metriken pro Sekunde ermöglichte:

Deshalb haben wir vier gemacht, mit vier Sets von Sockets, Arbeitern:

Und das hat es ermöglicht, die Geschwindigkeit auf etwa 130 Tausend Metriken zu steigern:

Die Nichtlinearität des Wachstums erklärt sich dadurch, dass Konkurrenz um den History-Cache entstand. Daran konkurrierten 4 Preprocess-Manager und History-Syncer. Zu diesem Zeitpunkt erhielten wir auf der Testmaschine etwa 130 Tausend Metriken pro Sekunde und nutzten sie zu etwa 95 % aus, was die CPU betrifft:

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 hinein.

MT: – Was gibt es jetzt?

MM: – Jetzt – 130k NVPs und die CPU ist "in der Schonung".

MT: – Wow! Cool! Warte, ich habe zwei Fragen. Nach meinen Berechnungen liegt unser Bedarf bei etwa 15-20 Tausend Metriken pro Sekunde. Warum brauchen wir mehr?

MM: – Ich möchte die Sache bis zum Ende durchziehen. Ich möchte sehen, wie viel wir aus diesem System herausholen können.

MT: – Aber...

MM: – Aber das ist für das Geschäft nutzlos.

MT: – Verstanden. Und die zweite Frage: Können wir das, was wir jetzt haben, selbstständig ohne Hilfe von Entwicklern unterstützen?

MM: – Ich glaube nicht. Die Änderung der Arbeit mit dem Konfigurationscache ist ein Problem. Sie betrifft Änderungen in den meisten Streams und ist ziemlich schwer zu unterstützen. Wahrscheinlich wird es sehr schwierig sein, sie zu unterstützen.

MT: – Dann müssen wir eine Alternative finden.

MM: – Es gibt eine solche Möglichkeit. Wir können auf schnelle Kerne umsteigen und gleichzeitig auf das neue Sperrsystem verzichten. Wir würden trotzdem eine Leistung von 60-80 Tausend Metriken erhalten. Dabei können wir den gesamten übrigen Code behalten. «ClickHouse», asynchrones Polling wird funktionieren. Und das wird leicht zu unterstützen sein.

MT: – Großartig! Ich schlage vor, an dieser Stelle Schluss zu machen.

Nach der Optimierung des Serverteils konnten wir endlich den neuen Code in der Produktion starten. Wir verzichteten auf einen Teil der Änderungen zugunsten des Wechsels zu einer Maschine mit schnellen Kernen und zur Minimierung der Änderungen im Code. Wir haben auch die Konfiguration vereinfacht und wo möglich auf Makros in den Datenelementen verzichtet, da sie zusätzliche Sperren verursachen.

Zum Beispiel hat der Verzicht auf das häufige in der Dokumentation und in Beispielen vorkommende Makro SNMP-Community in unserem Fall dazu geführt, dass die NVPs etwa 1,5 Mal schneller wurden.

Nach zwei Tagen in der Produktion

Wir entfernen die Pop-ups der Vorfallhistorie

MT: – Misha, wir nutzen das System seit zwei Tagen, und es funktioniert alles. Aber nur, wenn alles funktioniert! Wir hatten planmäßige Arbeiten mit der Verlagerung eines ziemlich großen Netzwerksegments, und wir haben wieder manuell überprüft, was hochgefahren wurde und was nicht.

MM: – Das kann nicht sein! Wir haben alles 10 Mal überprüft. Der Server bearbeitet selbst die vollständige Nichterreichbarkeit des Netzwerks blitzschnell.

MT: – Ich verstehe alles: Server, Datenbank, top, austat, Logs – alles läuft schnell... Aber wir schauen uns die Weboberfläche an, und da ist die CPU "im Leerlauf" auf dem Server und das hier:

MM: – Verstanden. Lass uns die Weboberfläche anschauen. Wir haben festgestellt, dass in Situationen mit einer großen Anzahl aktiver Vorfälle die meisten operativen Widgets sehr langsam arbeiteten:

Der Grund dafür war die Generierung von Popup-Fenstern mit der Historie der Vorfälle, die für jedes Element in der Liste erstellt werden. Daher haben wir auf die Generierung dieser Fenster verzichtet (wir haben 5 Zeilen im Code kommentiert), und das hat unsere Probleme gelöst.

Die Ladezeit der Widgets verkürzte sich selbst bei vollständiger Nichterreichbarkeit von mehreren Minuten auf für uns akzeptable 10-15 Sekunden, und die Historie kann weiterhin mit einem Klick auf die Zeit angesehen werden:

Nach der Arbeit. Vor 2 Monaten

MT: – Misha, gehst du? Wir müssen reden.

MM: – Ich hatte nicht vor zu gehen. Ist wieder was mit Zabbix?

MT: – Nein, entspanne dich! Ich wollte nur sagen: Es funktioniert alles, danke! Ich lade dich auf ein Bier ein.

Zabbix ist effektiv

"Zabbix" ist ein ziemlich vielseitiges und umfangreiches System und Funktion. Es kann problemlos für kleine Installationen "out of the box" verwendet werden, aber mit wachsenden Anforderungen muss es optimiert werden. Für die Speicherung eines großen Archivs von Metriken verwenden Sie eine geeignete Speicherlösung:

• Sie können die integrierten Funktionen in Form der Integration mit "Elasticsearch" oder den Export der Historie in Textdateien nutzen (verfügbar ab der vierten Version);
• Sie können auch von unserer Erfahrung und der Integration mit "ClickHouse" profitieren.

Um die Geschwindigkeit der Metrikenerfassung drastisch zu erhöhen, erfassen Sie diese mithilfe asynchroner Methoden und übertragen Sie sie über die Trapper-Schnittstelle an den "Zabbix"-Server; alternativ können Sie den Patch für die Asynchronität der Poller von "Zabbix" verwenden.

„Zabbix“ ist in C geschrieben und sehr effizient. Einige enge architektonische Stellen ermöglichen es, die Leistung weiter zu steigern, und aus unserer Erfahrung erhalten wir über 100.000 Metriken auf einer Einzelprozessormaschine.

Der besagte Zabbix-Patch

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

Der Patch beinhaltet:

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

Der Patch ist mit allen Versionen 4 kompatibel, auch mit lts. Höchstwahrscheinlich wird er mit minimalen Änderungen auch in Version 3.4 funktionieren.

Danke für Ihre Aufmerksamkeit.

Fragen

Frage aus dem Publikum (im Folgenden - A): – Guten Tag! Können Sie mir bitte sagen, ob Sie Pläne für eine intensive Zusammenarbeit mit dem Zabbix-Team haben oder umgekehrt, damit es kein Patch, sondern ein normales Verhalten von „Zabbix“ wäre?

MM: – Ja, einige Änderungen werden wir unbedingt committen. Manche Dinge werden in dem Patch bleiben.

A: – Vielen Dank für den großartigen Vortrag! Bitte sagen Sie, wird die Unterstützung seitens „Zabbix“ nach der Anwendung des Patches weiterhin bestehen, und wie wird die Aktualisierung auf höhere Versionen stattfinden? Wird es möglich sein, „Zabbix“ nach Ihrem Patch auf 4.2, 5.0 zu aktualisieren?

MM: – Zum Thema Unterstützung kann ich nichts sagen. Wenn ich im technischen Support von „Zabbix“ wäre, würde ich vermutlich nein sagen, da es sich um fremden Code handelt. Was die Codebasis 4.2 angeht, so ist unsere Position die folgende: „Wir werden mit der Zeit gehen und uns selbst auf die nächste Version aktualisieren.“ Daher werden wir eine Zeit lang Patches für aktualisierte Versionen bereitstellen. Ich habe bereits im Vortrag gesagt: Die Anzahl der Änderungen zwischen den Versionen ist derzeit noch recht gering. Ich glaube, der Übergang von 3.4 auf 4 hat bei uns etwa 15 Minuten gedauert. Es hat sich etwas geändert, aber nicht besonders Wichtiges.

A: – Das heißt, Sie planen, Ihren Patch zu unterstützen, und man kann ihn bedenkenlos in der Produktion einsetzen, um künftig auf irgendeine Weise Updates zu erhalten?

MM: – Wir empfehlen das nachdrücklich. Es löst uns sehr viele Probleme.

MT: – Noch einmal möchte ich betonen, dass die Änderungen, die nichts mit der Architektur oder den Blockierungen, Warteschlangen zu tun haben, modular sind, sie befinden sich in separaten Modulen. Auch bei geringfügigen Änderungen können sie relativ einfach verwaltet werden.

MM: – Wenn Sie an den Einzelheiten interessiert sind, verwendet „ClickHouse“ die sogenannte Geschichtsbibliothek. Sie ist entkoppelt – eine Kopie der Unterstützung von „Elastix“, also konfigurationsveränderbar. Polling ändert nur die Poller. Wir glauben, dass das lange funktionieren wird.

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

MM: – Die Dokumentation ist der Patch. Offensichtlich entstehen mit der Einführung von „ClickHouse“ und neuen Pollertypen neue Konfigurationsoptionen. In dem Link aus der letzten Folie gibt es eine kurze Beschreibung, wie man es verwendet.

Zur Ersetzung von fping durch nmap

A: – Wie haben Sie das letztendlich umgesetzt? Können Sie es an konkreten Beispielen erklären: haben Sie Strapper und ein externes Skript? Was prüft letztendlich so schnell eine so große Anzahl von Hosts? Wie beschaffen Sie diese Hosts? Muss man nmap diese irgendwie zuführen, woher bekommen, ablegen, etwas starten?..

MM: – Cool. Sehr gute Frage! Die Essenz ist folgende. Wir haben die Bibliothek (ICMP-Ping, ein Teil von „Zabbix“) für die ICMP-Prüfungen modifiziert, bei denen die Anzahl der Pakete auf eins (1) festgelegt ist, und der Code versucht, nmap zu verwenden. Das ist also die interne Arbeit von „Zabbix“ geworden, die zu interner Arbeit des Pingers wurde. Daher ist keine Synchronisation oder Verwendung eines Trappers erforderlich. Das wurde bewusst so gemacht, um das System ganz zu lassen und sich nicht mit der Synchronisation zweier Basissysteme zu beschäftigen: was zu prüfen, über den Poller zu laden, und ob das Laden nicht kaputt gegangen ist?.. Das ist viel einfacher.

A: – Funktioniert das auch für Proxys?

MM: – Ja, aber wir haben es nicht getestet. Der Polling-Code ist sowohl in „Zabbix“ als auch im Server einheitlich. Es sollte funktionieren. Nochmals betont: Die Systemleistung ist so, dass wir keinen Proxy benötigen.

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

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

MM: – Ich möchte noch einmal betonen: Wir haben eine vollständige Integration vorgenommen. Wir speichern die Historie in „ClickHouse“, aber haben dabei das PHP-Frontend geändert. Das PHP-Frontend greift auf „ClickHouse“ zu und erstellt alle Grafiken von dort. Dabei haben wir, um ehrlich zu sein, einen Teil, der aus demselben „ClickHouse“, aus denselben Daten von „Zabbix“ Daten in anderen grafischen Darstellungen generiert.

MT: – Darunter auch in „Grafana“.

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

A: – Teilen Sie bitte etwas über die interne Vorgehensweise mit. Wie wurde entschieden, dass Ressourcen für eine ernsthafte Überarbeitung des Produkts bereitgestellt werden müssen? Es sind schließlich bestimmte Risiken damit verbunden. Und sagen Sie bitte im Kontext dessen, dass Sie beabsichtigen, neue Versionen zu unterstützen: Wie rechtfertigt sich diese Entscheidung aus Sicht des Managements?

MM: – Anscheinend haben wir die dramatische Geschichte nicht sehr gut erzählt. Wir befanden uns in einer Situation, in der etwas getan werden musste, und gingen im Wesentlichen zwei parallele Wege:

• Eine Gruppe kümmerte sich um die Einführung des Monitorings mit neuen Methoden: Monitoring als Service, ein standardmäßiger Satz von Open-Source-Lösungen, die wir kombinieren und dann versuchen, den Geschäftsprozess zu ändern, um mit dem neuen Monitoringsystem zu arbeiten.
• Parallel dazu hatten wir einen enthusiastischen Programmierer, der sich damit beschäftigte (und sich selbst wie ein Protagonist verhielt). Es stellte sich heraus, dass er allen anderen voraus war.

A: – Und wie groß ist das Team?

MT: – Es steht vor Ihnen.

A: – Das heißt, wie immer wird ein Passionierter benötigt?

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

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

MM: – Danke.

Über die Patches für Zabbix

A: – Ist es möglich, Ihre Lösung zu adaptieren und zu patchen für ein System, das Proxy verwendet (zum Beispiel in einigen verteilten Systemen); sagen wir für die Poller, Proxys und teilweise für den Preprocessor von Zabbix; und deren Interaktion? Ist es möglich, bestehende Entwicklungen zu optimieren, um mit einem System mit mehreren Proxys zu funktionieren?

MM: – Ich weiß, dass der Zabbix-Server mit Proxy gebaut wird (es wird kompiliert und der Code entsteht). Wir haben das nicht in der Produktion überprüft. Ich bin mir da nicht sicher, aber meines Erachtens wird der Preprocessor-Manager im Proxy nicht verwendet. Die Aufgabe des Proxys ist es, eine Sammlung von Metriken von Zabbix abzurufen, sie zu spollen (er speichert außerdem die Konfiguration, die lokale Datenbank) und sie dann zurück an den Zabbix-Server zu geben. Der Preprocessing wird dann vom Server durchgeführt, wenn er sie erhält.

Das Interesse an Proxys ist verständlich. Wir werden das prüfen. Es ist ein interessantes Thema.

A: – Die Idee war die: Wenn man Poller patchen kann, kann man sie auch auf Proxys patchen und die Interaktion mit dem Server anpassen, während der Preprocessor dafür nur auf dem Server angepasst wird.

MM: – Ich denke, es ist sogar einfacher. Sie nehmen den Code, wenden den Patch an, konfigurieren ihn dann so, wie Sie es brauchen – erstellen Proxys (zum Beispiel mit ODBC) und verteilen den gepatchten Code auf die Systeme. Wo nötig, erstellen Sie Proxys, wo nötig, den Server.

A: – Wahrscheinlich wird es nicht nötig sein, die Übertragung von Proxys zum Server zusätzlich zu patchen?

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

MM: – Tatsächlich wurde eine der Ideen nicht erwähnt. Wir haben immer versucht, das Gleichgewicht zwischen einem Ideenüberschuss und der Anzahl der Änderungen, sowie der Wartungsfreundlichkeit zu wahren.

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 Freunden empfehlen, Cloud-VPS für Entwickler ab 4,99 $, ein einzigartiges Äquivalent zu Einsteigerservern, das wir für Sie entwickelt haben: Die ganze Wahrheit über VPS (KVM) E5-2697 v3 (6 Kerne) 10GB DDR4 480GB SSD 1Gbps ab 19 $ oder wie man einen Server richtig teilt? (es sind Optionen mit RAID1 und RAID10 bis zu 24 Kernen und bis zu 40GB DDR4 verfügbar).

Dell R730xd ist im Equinix Tier IV Rechenzentrum in Amsterdam doppelt so günstig? 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, wie man eine Unternehmensinfrastruktur der Klasse C mit Dell R730xd E5-2650 v4-Servern für 9000 Euro im Preis-Leistungs-Verhältnis aufbaut?

Quelle: habr.com