Die nächste HighLoad++-Konferenz findet am 6. und 7. April 2020 in St. Petersburg statt. Details und Tickets . HighLoad++ Moskau 2018. Halle „Moskau“. 9. November, 15:00 Uhr. Thesen und .
* Überwachung – online und Analyse.
* Grundlegende Einschränkungen der ZABBIX-Plattform.
* Lösung zur Skalierung des Analysespeichers.
* Optimierung des ZABBIX-Servers.
* UI-Optimierung.
* Erfahrung im Betrieb des Systems unter Lasten von mehr als 40 NVPS.
* Kurze Schlussfolgerungen.
Mikhail Makurov (im Folgenden – MM): - Hallo zusammen!
Maxim Chernetsov (im Folgenden – MCH): - Guten Tag!
MM: – Lassen Sie mich Maxim vorstellen. Max ist ein talentierter Ingenieur, der beste Netzwerker, den ich kenne. Maxim beschäftigt sich mit Netzwerken und Diensten, deren Entwicklung und Betrieb.
MCH: – Und ich möchte Ihnen von Mikhail erzählen. Mikhail ist ein C-Entwickler. Er hat mehrere Lösungen für die Verarbeitung von Hochlast-Verkehr für unser Unternehmen geschrieben. Wir leben und arbeiten im Ural, in der Stadt der harten Männer Tscheljabinsk, in der Firma Intersvyaz. Unser Unternehmen ist ein Anbieter von Internet- und Kabelfernsehdiensten für eine Million Menschen in 16 Städten.
MM: – Und es ist erwähnenswert, dass Intersvyaz viel mehr als nur ein Anbieter ist, es ist ein IT-Unternehmen. Die meisten unserer Lösungen werden von unserer IT-Abteilung erstellt.
A: Von Servern, die den Datenverkehr verarbeiten, bis hin zu einem Callcenter und einer mobilen Anwendung. Die IT-Abteilung besteht mittlerweile aus rund 80 Personen mit sehr, sehr unterschiedlichen Kompetenzen.
Über Zabbix und seine Architektur
MCH: – Und jetzt versuche ich, einen persönlichen Rekord aufzustellen und in einer Minute zu sagen, was Zabbix ist (im Folgenden „Zabbix“ genannt).
Zabbix positioniert sich als sofort einsatzbereites Überwachungssystem auf Unternehmensebene. Es verfügt über viele Funktionen, die das Leben einfacher machen: erweiterte Eskalationsregeln, API für Integration, Gruppierung und automatische Erkennung von Hosts und Metriken. Zabbix verfügt über sogenannte Skalierungstools – Proxys. Zabbix ist ein Open-Source-System.
Kurz zur Architektur. Wir können sagen, dass es aus drei Komponenten besteht:
- Server. Geschrieben in C. Mit ziemlich komplexer Verarbeitung und Übertragung von Informationen zwischen Threads. Darin findet die gesamte Verarbeitung statt: vom Empfang bis zur Speicherung in der Datenbank.
- Alle Daten werden in der Datenbank gespeichert. Zabbix unterstützt MySQL, PostreSQL und Oracle.
- Das Webinterface ist in PHP geschrieben. Auf den meisten Systemen ist es mit einem Apache-Server ausgestattet, arbeitet aber in Kombination mit Nginx + PHP effizienter.
Heute möchten wir eine Geschichte aus dem Leben unseres Unternehmens rund um Zabbix erzählen...
Eine Geschichte aus dem Leben der Firma Intersvyaz. Was haben wir und was brauchen wir?
Vor 5 oder 6 Monaten. Einen Tag nach der Arbeit...
MCH: - Mischa, hallo! Ich bin froh, dass ich dich erwischt habe – es gibt ein Gespräch. Wir hatten erneut Probleme mit der Überwachung. Bei einem schweren Unfall war alles langsam und es gab keine Informationen über den Zustand des Netzwerks. Leider ist dies nicht das erste Mal, dass dies passiert. Ich brauche deine Hilfe. Sorgen wir dafür, dass unsere Überwachung unter allen Umständen funktioniert!
MM: - Aber lasst uns zuerst synchronisieren. Ich habe dort seit ein paar Jahren nicht mehr gesucht. Soweit ich mich erinnere, haben wir vor etwa 8 Jahren Nagios aufgegeben und sind auf Zabbix umgestiegen. Und jetzt scheinen wir über 6 leistungsstarke Server und etwa ein Dutzend Proxys zu verfügen. Verwechsle ich etwas?
MCH: - Fast. 15 Server, teilweise virtuelle Maschinen. Das Wichtigste ist, dass es uns nicht in dem Moment rettet, in dem wir es am meisten brauchen. Wie ein Unfall – die Server werden langsamer und man kann nichts sehen. Wir haben versucht, die Konfiguration zu optimieren, dies führte jedoch nicht zu einer optimalen Leistungssteigerung.
MM: - Es ist klar. Hast du dir etwas angesehen, hast du schon etwas aus der Diagnose herausgefunden?
MCH: – Das erste, womit Sie sich befassen müssen, ist die Datenbank. MySQL wird ständig geladen und speichert neue Metriken, und wenn Zabbix beginnt, eine Reihe von Ereignissen zu generieren, gerät die Datenbank buchstäblich für ein paar Stunden auf Hochtouren. Ich habe Ihnen bereits von der Optimierung der Konfiguration erzählt, aber dieses Jahr haben sie buchstäblich die Hardware aktualisiert: Die Server verfügen über mehr als hundert Gigabyte Speicher und Festplatten-Arrays auf SSD-RAIDs – es macht auf lange Sicht keinen Sinn, diese linear zu erweitern. Was machen wir?
MM: - Es ist klar. Im Allgemeinen ist MySQL eine LTP-Datenbank. Anscheinend ist es nicht mehr geeignet, ein Metrikarchiv unserer Größe zu speichern. Lass es uns herausfinden.
MCH: - Lasst uns!
Integration von Zabbix und Clickhouse als Ergebnis des Hackathons
Nach einiger Zeit erhielten wir interessante Daten:
Der größte Teil des Speicherplatzes in unserer Datenbank wurde vom Metrikarchiv belegt und weniger als 1 % wurde für Konfiguration, Vorlagen und Einstellungen verwendet. Zu diesem Zeitpunkt hatten wir die auf Clickhouse basierende Big-Data-Lösung bereits seit mehr als einem Jahr im Einsatz. Die Bewegungsrichtung war für uns klar. Bei unserem Frühjahrs-Hackathon habe ich die Integration von Zabbix mit Clickhouse für den Server und das Frontend geschrieben. Zu diesem Zeitpunkt unterstützte Zabbix bereits ElasticSearch und wir beschlossen, sie zu vergleichen.
Vergleich von Clickhouse und Elasticsearch
MM: – Zum Vergleich haben wir die gleiche Last erzeugt, die der Zabbix-Server bereitstellt, und uns angeschaut, wie sich die Systeme verhalten würden. Wir haben Daten in Stapeln von 1000 Zeilen mit CURL geschrieben. Wir gingen im Vorfeld davon aus, dass Clickhouse für das Lastprofil effizienter wäre als Zabbix. Die Ergebnisse übertrafen sogar unsere Erwartungen:
Unter den gleichen Testbedingungen schrieb Clickhouse dreimal mehr Daten. Gleichzeitig verbrauchten beide Systeme beim Lesen von Daten sehr effizient (geringe Ressourcenmenge). Allerdings benötigte Elastics bei der Aufnahme viel Prozessor:
Insgesamt war Clickhouse Elastix hinsichtlich Prozessorverbrauch und Geschwindigkeit deutlich überlegen. Gleichzeitig verbraucht Clickhouse aufgrund der Datenkomprimierung 11-mal weniger Festplattenlaufwerk und führt etwa 30-mal weniger Festplattenoperationen durch:
MCH: – Ja, die Arbeit von Clickhouse mit dem Festplatten-Subsystem ist sehr effizient umgesetzt. Sie können riesige SATA-Festplatten für Datenbanken verwenden und Schreibgeschwindigkeiten von Hunderttausenden Zeilen pro Sekunde erreichen. Das sofort einsatzbereite System unterstützt Sharding und Replikation und ist sehr einfach zu konfigurieren. Mit der ganzjährigen Nutzung sind wir mehr als zufrieden.
Um die Ressourcen zu optimieren, können Sie Clickhouse neben Ihrer bestehenden Hauptdatenbank installieren und dadurch viel CPU-Zeit und Festplattenoperationen sparen. Wir haben das Metrikarchiv in bestehende Clickhouse-Cluster verschoben:
Wir haben die Haupt-MySQL-Datenbank so stark entlastet, dass wir sie auf einer Maschine mit dem Zabbix-Server kombinieren und den dedizierten Server für MySQL aufgeben konnten.
Wie funktioniert die Umfrage in Zabbix?
4 Monaten
MM: – Können wir die Probleme mit der Basis vergessen?
MCH: - So wahr! Ein weiteres Problem, das wir lösen müssen, ist die langsame Datenerfassung. Jetzt sind alle unsere 15 Proxy-Server mit SNMP- und Polling-Prozessen überlastet. Und es gibt keine andere Möglichkeit, als immer neue Server zu installieren.
MM: - Großartig. Aber erzählen Sie uns zunächst, wie die Umfrage in Zabbix funktioniert.
MCH: – Kurz gesagt, es gibt 20 Arten von Metriken und ein Dutzend Möglichkeiten, sie zu erhalten. Zabbix kann Daten entweder im „Request-Response“-Modus sammeln oder über die „Trapper-Schnittstelle“ auf neue Daten warten.
Es ist erwähnenswert, dass diese Methode (Trapper) im ursprünglichen Zabbix die schnellste ist.
Für die Lastverteilung gibt es Proxy-Server:
Proxys können die gleichen Erfassungsfunktionen wie der Zabbix-Server ausführen, Aufgaben von ihm empfangen und die gesammelten Metriken über die Trapper-Schnittstelle senden. Dies ist die offiziell empfohlene Art der Lastverteilung. Proxys sind auch nützlich für die Überwachung entfernter Infrastrukturen, die über NAT oder einen langsamen Kanal betrieben werden:
MM: – Bei der Architektur ist alles klar. Wir müssen uns die Quellen ansehen...
Ein paar Tage später
Die Geschichte, wie nmap fping gewann
MM: „Ich glaube, ich habe etwas ausgegraben.“
MCH: - Sag mir!
MM: – Ich habe festgestellt, dass Zabbix bei der Überprüfung der Verfügbarkeit maximal 128 Hosts gleichzeitig überprüft. Ich habe versucht, diese Zahl auf 500 zu erhöhen und das Intervall zwischen Paketen in ihrem Ping (Ping) zu entfernen – dadurch wurde die Leistung verdoppelt. Aber ich hätte gerne größere Zahlen.
MCH: – In meiner Praxis muss ich manchmal die Verfügbarkeit von Tausenden von Hosts überprüfen, und ich habe dafür noch nie etwas schnelleres als nmap gesehen. Ich bin sicher, das ist der schnellste Weg. Lass es uns versuchen! Wir müssen die Anzahl der Hosts pro Iteration deutlich erhöhen.
MM: – Mehr als fünfhundert prüfen? 600?
MCH: - Mindestens ein paar Tausend.
MM: - OK. Das Wichtigste, was ich sagen wollte, ist, dass ich festgestellt habe, dass die meisten Abfragen in Zabbix synchron erfolgen. Wir müssen es unbedingt in den asynchronen Modus ändern. Dann können wir die Anzahl der von Pollern gesammelten Metriken drastisch erhöhen, insbesondere wenn wir die Anzahl der Metriken pro Iteration erhöhen.
MCH: - Großartig! Und wann?
MM: – Wie immer gestern.
MCH: – Wir haben beide Versionen von fping und nmap verglichen:
Auf einer großen Anzahl von Hosts wurde erwartet, dass nmap bis zu fünfmal effektiver ist. Da nmap nur die Verfügbarkeit und Antwortzeit prüft, haben wir die Verlustberechnung auf Trigger verlagert und die Verfügbarkeitsprüfungsintervalle deutlich verkürzt. Wir haben festgestellt, dass die optimale Anzahl an Hosts für nmap etwa 4 pro Iteration beträgt. Mit Nmap konnten wir die CPU-Kosten für Verfügbarkeitsprüfungen um das Dreifache senken und das Intervall von 120 Sekunden auf 10 Sekunden verkürzen.
Polling-Optimierung
MM: „Dann haben wir angefangen, Umfragen durchzuführen. Unser Hauptinteresse galt der SNMP-Erkennung und den SNMP-Agenten. In Zabbix erfolgt die Abfrage synchron und es wurden besondere Maßnahmen ergriffen, um die Effizienz des Systems zu steigern. Im synchronen Modus führt die Nichtverfügbarkeit des Hosts zu einer erheblichen Beeinträchtigung der Abfrage. Es gibt ein ganzes System von Zuständen, es gibt spezielle Prozesse – die sogenannten Unreachable Poller, die nur mit nicht erreichbaren Hosts arbeiten:
Dies ist ein Kommentar, der die Zustandsmatrix und die gesamte Komplexität des Systems an Übergängen demonstriert, die erforderlich sind, damit das System wirksam bleibt. Darüber hinaus ist die synchrone Abfrage selbst recht langsam:
Aus diesem Grund konnten Tausende Poller-Streams auf Dutzenden Proxys nicht die erforderliche Datenmenge für uns sammeln. Die asynchrone Implementierung löste nicht nur die Probleme mit der Anzahl der Threads, sondern vereinfachte auch das Statussystem nicht verfügbarer Hosts erheblich, da für jede in einer Abfrageiteration überprüfte Anzahl die maximale Wartezeit 1 Timeout betrug:
Darüber hinaus haben wir das Abfragesystem für SNMP-Anfragen geändert und verbessert. Tatsache ist, dass die meisten Menschen nicht auf mehrere SNMP-Anfragen gleichzeitig reagieren können. Aus diesem Grund haben wir einen Hybridmodus erstellt, bei dem die SNMP-Abfrage desselben Hosts asynchron erfolgt:
Dies erfolgt für das gesamte Hostpaket. Dieser Modus ist letztendlich nicht langsamer als ein vollständig asynchroner, da die Abfrage von eineinhalbhundert SNMP-Werten immer noch viel schneller ist als 1 Timeout.
Unsere Experimente haben gezeigt, dass die optimale Anzahl von Anfragen in einer Iteration bei SNMP-Abfragen etwa 8 beträgt. Insgesamt konnten wir durch den Übergang zum asynchronen Modus die Abfrageleistung um das 200-fache bzw. mehrere Hundertfache beschleunigen.
MCH: – Die daraus resultierenden Polling-Optimierungen haben gezeigt, dass wir nicht nur alle Proxys loswerden können, sondern auch die Intervalle für viele Überprüfungen verkürzen können und Proxys zur Lastverteilung nicht mehr benötigt werden.
Vor etwa drei Monaten
Architektur ändern – Last erhöhen!
MM: - Nun, Max, ist es an der Zeit, produktiv zu werden? Ich brauche einen leistungsstarken Server und einen guten Ingenieur.
MCH: - Okay, lass es uns planen. Es ist höchste Zeit, den toten Punkt von 5 Messwerten pro Sekunde zu verlassen.
Morgen nach dem Upgrade
MCH: - Mischa, wir haben uns aktualisiert, aber am Morgen haben wir einen Rollback gemacht... Ratet mal, welche Geschwindigkeit wir erreicht haben?
MM: – maximal 20.
MCH: - Ja, 25! Leider sind wir wieder da, wo wir angefangen haben.
MM: - Warum? Haben Sie eine Diagnose durchgeführt?
MCH: - Ja natürlich! Hier ist zum Beispiel ein interessantes Oberteil:
MM: - Lass uns gucken. Ich sehe, dass wir eine große Anzahl von Umfragethreads ausprobiert haben:
Aber gleichzeitig konnten sie das System nicht einmal zur Hälfte recyceln:
Und die Gesamtleistung ist recht gering, etwa 4 Messwerte pro Sekunde:
Gibt es noch etwas?
MCH: – Ja, Strace eines der Meinungsforscher:
MM: – Hier ist deutlich zu erkennen, dass der Polling-Prozess auf „Semaphoren“ wartet. Das sind die Schlösser:
MCH: - Unverständlich.
MM: – Schauen Sie, das ähnelt einer Situation, in der eine Reihe von Threads versuchen, mit Ressourcen zu arbeiten, mit denen jeweils nur einer arbeiten kann. Dann können sie diese Ressource im Laufe der Zeit nur noch teilen:
Und die Gesamtleistung bei der Arbeit mit einer solchen Ressource wird durch die Geschwindigkeit eines Kerns begrenzt:
Es gibt zwei Möglichkeiten, dieses Problem zu lösen.
Rüsten Sie die Hardware der Maschine auf und wechseln Sie zu schnelleren Kernen:
Oder ändern Sie die Architektur und ändern Sie gleichzeitig die Last:
MCH: – Übrigens werden wir auf der Testmaschine weniger Kerne verwenden als auf der Kampfmaschine, aber sie sind 1,5-mal schneller in der Frequenz pro Kern!
MM: - Klar? Sie müssen sich den Servercode ansehen.
Datenpfad im Zabbix-Server
MCH: – Um das herauszufinden, haben wir begonnen zu analysieren, wie Daten innerhalb des Zabbix-Servers übertragen werden:
Cooles Bild, oder? Gehen wir es Schritt für Schritt durch, um es mehr oder weniger klar zu machen. Es gibt Threads und Dienste, die für die Datenerfassung verantwortlich sind:
Sie übermitteln die gesammelten Metriken über einen Socket an den Präprozessor-Manager, wo sie in einer Warteschlange gespeichert werden:
Der „Präprozessor-Manager“ überträgt Daten an seine Worker, die Vorverarbeitungsanweisungen ausführen und sie über denselben Socket zurücksenden:
Danach speichert der Präprozessor-Manager sie im Verlaufscache:
Von dort werden sie von History Sinkern übernommen, die eine ganze Reihe von Funktionen ausführen: zum Beispiel das Berechnen von Triggern, das Füllen des Werte-Cache und, was am wichtigsten ist, das Speichern von Metriken im History-Speicher. Generell ist der Prozess komplex und sehr verwirrend.
MM: – Das erste, was uns auffiel, war, dass die meisten Threads um den sogenannten „Konfigurationscache“ (den Speicherbereich, in dem alle Serverkonfigurationen gespeichert sind) konkurrieren. Threads, die für das Sammeln von Daten verantwortlich sind, blockieren besonders häufig:
...da die Konfiguration nicht nur Metriken mit ihren Parametern speichert, sondern auch Warteschlangen, aus denen Poller Informationen darüber beziehen, was als nächstes zu tun ist. Wenn es viele Poller gibt und einer die Konfiguration blockiert, warten die anderen auf Anfragen:
Meinungsforscher sollten keinen Konflikt haben
Deshalb haben wir als erstes die Warteschlange in vier Teile geteilt und den Pollern erlaubt, diese Warteschlangen, diese Teile gleichzeitig, unter sicheren Bedingungen zu blockieren:
Dadurch wurde die Konkurrenz um den Konfigurationscache beseitigt und die Geschwindigkeit der Poller wurde deutlich erhöht. Doch dann stellten wir fest, dass der Präprozessor-Manager begann, eine Warteschlange mit Jobs anzusammeln:
Der Präprozessor-Manager muss in der Lage sein, Prioritäten zu setzen
Dies geschah in Fällen, in denen es ihm an Leistung mangelte. Dann konnte er nur noch Anfragen von Datenerfassungsprozessen sammeln und deren Puffer aufsummieren, bis der gesamte Speicher verbraucht war und abstürzte:
Um dieses Problem zu lösen, haben wir einen zweiten Sockel hinzugefügt, der speziell für Arbeiter gedacht ist:
Somit hatte der Präprozessor-Manager die Möglichkeit, seine Arbeit zu priorisieren, und wenn der Puffer wächst, besteht die Aufgabe darin, den Abbau zu verlangsamen, um den Arbeitern die Möglichkeit zu geben, diesen Puffer zu nutzen:
Dann stellten wir fest, dass einer der Gründe für die Verlangsamung die Arbeiter selbst waren, die um eine Ressource konkurrierten, die für ihre Arbeit völlig unwichtig war. Wir haben dieses Problem als Bugfix dokumentiert und es wurde bereits in neuen Versionen von Zabbix behoben:
Wir erhöhen die Anzahl der Steckdosen – wir erhalten das Ergebnis
Darüber hinaus wurde der Präprozessor-Manager selbst zum Flaschenhals, da es sich um einen Thread handelt. Es basierte auf der Kerngeschwindigkeit und ergab eine maximale Geschwindigkeit von etwa 70 Messwerten pro Sekunde:
Deshalb haben wir vier Arbeiter mit vier Steckdosensätzen hergestellt:
Dadurch konnten wir die Geschwindigkeit auf etwa 130 Messwerte steigern:
Die Nichtlinearität des Wachstums erklärt sich aus der Tatsache, dass Konkurrenz um den History-Cache entstanden ist. 4 Präprozessor-Manager und History-Senker konkurrierten darum. Zu diesem Zeitpunkt empfingen wir auf der Testmaschine etwa 130 Messwerte pro Sekunde, die von etwa 95 % des Prozessors genutzt wurden:
Vor etwa 2,5 Monaten
Die Ablehnung durch die SNMP-Community erhöhte die NVPs um das Eineinhalbfache
MM: – Max, ich brauche ein neues Testauto! Wir passen nicht mehr in die jetzige.
MCH: - Was habt ihr denn jetzt?
MM: – Jetzt – 130 NVPs und ein regalfertiger Prozessor.
MCH: - Wow! Cool! Moment, ich habe zwei Fragen. Meinen Berechnungen zufolge liegt unser Bedarf bei etwa 15 bis 20 Messwerten pro Sekunde. Warum brauchen wir mehr?
MM: „Ich möchte den Job zu Ende bringen.“ Ich würde gerne sehen, wie viel wir aus diesem System herausholen können.
MCH: - Aber ...
MM: „Aber für das Geschäft ist es nutzlos.“
MCH: - Es ist klar. Und die zweite Frage: Können wir das, was wir jetzt haben, alleine unterstützen, ohne die Hilfe eines Entwicklers?
MM: - Ich denke nicht. Es stellt ein Problem dar, die Funktionsweise des Konfigurationscache zu ändern. Es wirkt sich auf Änderungen in den meisten Threads aus und ist ziemlich schwierig zu warten. Höchstwahrscheinlich wird es sehr schwierig sein, es aufrechtzuerhalten.
MCH: „Dann brauchen wir eine Alternative.“
MM: - Es gibt eine solche Option. Wir können auf schnelle Kerne umsteigen und gleichzeitig auf das neue Verriegelungssystem verzichten. Wir werden immer noch eine Leistung von 60-80 Metriken erzielen. Gleichzeitig können wir den gesamten Rest des Codes belassen. Clickhouse und asynchrone Abfragen funktionieren. Und es wird leicht zu warten sein.
MCH: - Toll! Ich schlage vor, dass wir hier anhalten.
Nachdem wir die Serverseite optimiert hatten, konnten wir den neuen Code endlich in die Produktion bringen. Wir haben einige der Änderungen aufgegeben und sind stattdessen auf eine Maschine mit schnellen Kernen umgestiegen und haben die Anzahl der Codeänderungen minimiert. Wir haben außerdem die Konfiguration vereinfacht und Makros in Datenelementen, wo möglich, entfernt, da sie zusätzliche Sperren einführen.
Durch den Verzicht auf das snmp-community-Makro, das häufig in Dokumentationen und Beispielen zu finden ist, war es in unserem Fall möglich, NVPs um etwa das 1,5-fache zu beschleunigen.
Nach zwei Tagen in Produktion
Pop-ups zum Vorfallverlauf werden entfernt
MCH: – Mischa, wir nutzen das System seit zwei Tagen und alles funktioniert. Aber nur, wenn alles funktioniert! Wir hatten die Arbeit mit der Übertragung eines ziemlich großen Teils des Netzwerks geplant und haben erneut mit unseren Händen überprüft, was geklappt hat und was nicht.
MM: - Kann nicht sein! Wir haben alles 10 Mal überprüft. Der Server bewältigt selbst eine vollständige Nichtverfügbarkeit des Netzwerks sofort.
MCH: - Ja, ich verstehe alles: Server, Datenbank, Top, Austat, Protokolle – alles ist schnell... Aber wir schauen uns die Weboberfläche an, und da ist ein Prozessor „im Regal“ auf dem Server und das:
MM: - Es ist klar. Schauen wir uns das Internet an. Wir haben festgestellt, dass in einer Situation mit einer großen Anzahl aktiver Vorfälle die meisten Live-Widgets sehr langsam zu funktionieren begannen:
Der Grund dafür war die Generierung von Popups zum Vorfallverlauf, die für jedes Element in der Liste generiert werden. Daher haben wir die Generierung dieser Fenster aufgegeben (5 Zeilen im Code auskommentiert) und dadurch unsere Probleme gelöst.
Die Ladezeit für Widgets, selbst wenn sie überhaupt nicht verfügbar sind, wurde von mehreren Minuten auf die für uns akzeptablen 10-15 Sekunden reduziert, und der Verlauf kann weiterhin durch Klicken auf die Uhrzeit angezeigt werden:
Nach der Arbeit. Vor 2 Monaten
MCH: - Mischa, gehst du? Wir müssen reden.
MM: - Das hatte ich nicht vor. Schon wieder was mit Zabbix?
MCH: - Nein, entspann dich! Ich wollte nur sagen: Alles funktioniert, danke! Ich habe ein Bier.
Zabbix ist effizient
Zabbix ist ein ziemlich universelles und reichhaltiges System und Funktionen. Es kann für kleine Installationen sofort verwendet werden, aber wenn die Anforderungen wachsen, muss es optimiert werden. Um ein großes Metrikarchiv zu speichern, verwenden Sie einen geeigneten Speicher:
- Sie können integrierte Tools in Form der Integration mit Elasticsearch oder des Hochladens des Verlaufs in Textdateien verwenden (verfügbar ab Version XNUMX);
- Profitieren Sie von unserer Erfahrung und Integration mit Clickhouse.
Um die Geschwindigkeit der Metrikerfassung drastisch zu erhöhen, erfassen Sie sie mit asynchronen Methoden und übertragen Sie sie über die Trapper-Schnittstelle an den Zabbix-Server. Oder Sie können einen Patch verwenden, um Zabbix-Poller asynchron zu machen.
Zabbix ist in C geschrieben und recht effizient. Durch die Lösung mehrerer architektonischer Engpässe können Sie die Leistung weiter steigern und unserer Erfahrung nach mehr als 100 Metriken auf einem Einprozessorrechner erhalten.
Der gleiche Zabbix-Patch
MM: – Ich möchte ein paar Punkte hinzufügen. Der gesamte aktuelle Bericht, alle Tests und Zahlen werden für die von uns verwendete Konfiguration angegeben. Wir beziehen daraus derzeit etwa 20 Messwerte pro Sekunde. Wenn Sie herausfinden möchten, ob dies für Sie funktioniert, können Sie vergleichen. Was heute besprochen wurde, ist in Form eines Patches auf GitHub veröffentlicht:
Der Patch enthält:
- vollständige Integration mit Clickhouse (sowohl Zabbix-Server als auch Frontend);
- Lösen von Problemen mit dem Präprozessor-Manager;
- asynchrone Abfrage.
Der Patch ist mit allen Versionen 4 kompatibel, einschließlich LTS. Höchstwahrscheinlich wird es mit minimalen Änderungen auf Version 3.4 funktionieren.
Vielen Dank für Ihre Aufmerksamkeit.
Fragen
Frage aus dem Publikum (im Folgenden – A): – Guten Tag! Bitte sagen Sie mir, haben Sie Pläne für eine intensive Interaktion mit dem Zabbix-Team oder mit ihnen, damit dies kein Patch, sondern normales Verhalten von Zabbix ist?
MM: – Ja, wir werden auf jeden Fall einige der Änderungen vornehmen. Es wird etwas passieren, etwas wird im Patch bleiben.
A: – Vielen Dank für den tollen Bericht! Bitte sagen Sie mir, dass die Unterstützung von Zabbix nach der Anwendung des Patches bestehen bleibt und wie kann ich mit dem Update auf höhere Versionen fortfahren? Wird es möglich sein, Zabbix nach Ihrem Patch auf 4.2, 5.0 zu aktualisieren?
MM: – Zum Support kann ich nichts sagen. Wenn ich der technische Support von Zabbix wäre, würde ich wahrscheinlich Nein sagen, da dies der Code von jemand anderem ist. Was die Codebasis 4.2 betrifft, so ist unser Standpunkt: „Wir werden uns mit der Zeit weiterentwickeln und uns auf die nächste Version aktualisieren.“ Daher werden wir für einige Zeit einen Patch für aktualisierte Versionen veröffentlichen. Ich habe im Bericht bereits gesagt: Die Anzahl der Änderungen bei Versionen ist noch recht gering. Ich glaube, der Übergang von 3.4 auf 4 hat etwa 15 Minuten gedauert. Da hat sich etwas geändert, aber nicht sehr wichtig.
A: – Sie planen also, Ihren Patch zu unterstützen und ihn sicher in der Produktion zu installieren und in Zukunft auf irgendeine Weise Updates zu erhalten?
MM: – Wir empfehlen es dringend. Das löst für uns viele Probleme.
MCH: – Ich möchte noch einmal darauf aufmerksam machen, dass die Änderungen, die nicht die Architektur betreffen und weder Blockierung noch Warteschlangen betreffen, modular sind, sie sind in separaten Modulen. Selbst mit kleinen Änderungen können Sie diese ganz einfach pflegen.
MM: – Wenn Sie sich für die Details interessieren, dann nutzt „Clickhouse“ die sogenannte Geschichtsbibliothek. Es ist ungebunden – es ist eine Kopie der Elastics-Unterstützung, das heißt, es ist konfigurierbar. Bei der Umfrage werden nur die Umfrageteilnehmer geändert. Wir glauben, dass dies noch lange funktionieren wird.
A: - Vielen Dank. Sagen Sie mir, gibt es eine Dokumentation der vorgenommenen Änderungen?
MM: – Dokumentation ist ein Patch. Offensichtlich ergeben sich mit der Einführung von Clickhouse und der Einführung neuer Pollertypen neue Konfigurationsmöglichkeiten. Der Link auf der letzten Folie enthält eine kurze Beschreibung der Verwendung.
Informationen zum Ersetzen von fping durch nmap
A: – Wie haben Sie das letztendlich umgesetzt? Können Sie konkrete Beispiele nennen: Haben Sie Strappers und ein externes Skript? Was führt dazu, dass so viele Hosts so schnell überprüft werden? Wie schürft man diese Hosts? Müssen wir sie irgendwie in nmap einspeisen, sie von irgendwoher holen, einfügen, etwas ausführen?
MM: - Cool. Eine sehr richtige Frage! Der Punkt ist dieser. Wir haben die Bibliothek (ICMP-Ping, Teil von Zabbix) für ICMP-Prüfungen geändert, die die Anzahl der Pakete angeben – eins (1), und der Code versucht, nmap zu verwenden. Das heißt, dies ist die interne Arbeit von Zabbix, die zur internen Arbeit des Pingers geworden ist. Dementsprechend ist keine Synchronisierung oder Verwendung eines Trappers erforderlich. Dies geschah bewusst, um das System intakt zu lassen und sich nicht um die Synchronisierung zweier Datenbanksysteme kümmern zu müssen: Was soll überprüft, über den Poller hochgeladen werden, und ist unser Upload fehlerhaft? … Das ist viel einfacher.
A: – Funktioniert es auch für Proxys?
MM: – Ja, aber wir haben es nicht überprüft. Der Abfragecode ist sowohl in Zabbix als auch auf dem Server derselbe. Sollte arbeiten. Ich möchte es noch einmal betonen: Die Leistung des Systems ist so, dass wir keinen Proxy benötigen.
MCH: – Die richtige Antwort auf die Frage lautet: „Warum braucht man bei einem solchen System einen Proxy?“ Nur wegen NAT oder Überwachung über einen langsamen Kanal ...
A: – Und Sie verwenden Zabbix als Allergor, wenn ich das richtig verstehe. Oder haben Sie Ihre Grafiken (wo sich die Archivebene befindet) auf ein anderes System verschoben, beispielsweise Grafana? Oder nutzen Sie diese Funktionalität nicht?
MM: – Ich betone noch einmal: Wir haben eine vollständige Integration erreicht. Wir füllen Clickhouse mit Geschichte, haben aber gleichzeitig das PHP-Frontend geändert. Das PHP-Frontend geht zu Clickhouse und erstellt von dort aus alle Grafiken. Gleichzeitig haben wir, um ehrlich zu sein, einen Teil, der Daten in anderen Grafikanzeigesystemen aus demselben Clickhouse und aus denselben Zabbix-Daten erstellt.
MCH: – Auch in „Grafan“.
Wie wurden Entscheidungen über die Ressourcenallokation getroffen?
A: – Teilen Sie ein wenig von Ihrer inneren Küche. Wie wurde die Entscheidung getroffen, dass Ressourcen für eine ernsthafte Verarbeitung des Produkts bereitgestellt werden mussten? Dabei handelt es sich im Allgemeinen um bestimmte Risiken. Und sagen Sie mir bitte im Zusammenhang mit der Tatsache, dass Sie neue Versionen unterstützen werden: Wie rechtfertigt sich diese Entscheidung aus Managementsicht?
MM: – Anscheinend haben wir das Drama der Geschichte nicht sehr gut erzählt. Wir befanden uns in einer Situation, in der etwas getan werden musste, und gingen im Wesentlichen mit zwei parallelen Teams vor:
- Eine davon war die Einführung eines Überwachungssystems mit neuen Methoden: Monitoring as a Service, ein Standardsatz von Open-Source-Lösungen, die wir kombinieren und dann versuchen, den Geschäftsprozess zu ändern, um mit dem neuen Überwachungssystem zu arbeiten.
- Gleichzeitig hatten wir einen begeisterten Programmierer, der dies (über sich selbst) tat. So kam es, dass er gewann.
A: – Und wie groß ist das Team?
MCH: - Sie ist vor dir.
A: – Sie brauchen also wie immer einen Leidenschaftlichen?
MM: – Ich weiß nicht, was ein Leidenschaftlicher ist.
A: - In diesem Fall offenbar Sie. Vielen Dank, du bist großartig.
MM: - Danke.
Über Patches für Zabbix
A: – Ist es für ein System, das Proxys verwendet (z. B. in einigen verteilten Systemen), möglich, beispielsweise Poller, Proxys und teilweise den Präprozessor von Zabbix selbst anzupassen und zu patchen? und ihr Zusammenspiel? Ist es möglich, bestehende Entwicklungen für ein System mit mehreren Proxys zu optimieren?
MM: – Ich weiß, dass der Zabbix-Server mithilfe eines Proxys zusammengestellt wird (der Code wird kompiliert und abgerufen). Wir haben dies nicht in der Produktion getestet. Ich bin mir da nicht sicher, aber ich denke, dass der Präprozessor-Manager im Proxy nicht verwendet wird. Die Aufgabe des Proxys besteht darin, eine Reihe von Metriken von Zabbix zu übernehmen, diese zusammenzuführen (er zeichnet auch die Konfiguration, die lokale Datenbank auf) und sie an den Zabbix-Server zurückzugeben. Der Server selbst führt dann die Vorverarbeitung durch, wenn er sie empfängt.
Das Interesse an Proxys ist verständlich. Wir werden es uns ansehen. Das ist ein interessantes Thema.
A: – Die Idee war folgende: Wenn Sie Poller patchen können, können Sie sie auf dem Proxy patchen und die Interaktion mit dem Server patchen und den Präprozessor nur auf dem Server für diese Zwecke anpassen.
MM: – Ich denke, es ist noch einfacher. Sie nehmen den Code, wenden einen Patch an und konfigurieren ihn dann nach Bedarf – sammeln Sie Proxyserver (z. B. mit ODBC) und verteilen Sie den gepatchten Code auf alle Systeme. Sammeln Sie bei Bedarf einen Proxy, bei Bedarf einen Server.
A: – Höchstwahrscheinlich müssen Sie die Proxy-Übertragung zum Server nicht zusätzlich patchen?
MCH: - Nein, es ist Standard.
MM: – Tatsächlich klang eine der Ideen nicht. Wir haben immer ein Gleichgewicht zwischen der Explosion von Ideen und der Menge an Änderungen und der Leichtigkeit des Supports gewahrt.
Einige Anzeigen 🙂
Vielen Dank, dass Sie bei uns geblieben sind. Gefallen Ihnen unsere Artikel? Möchten Sie weitere interessante Inhalte sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder an Freunde weiterempfehlen. , ein einzigartiges Analogon von Einstiegsservern, das von uns für Sie erfunden wurde: (verfügbar mit RAID1 und RAID10, bis zu 24 Kerne und bis zu 40 GB DDR4).
Dell R730xd 2-mal günstiger im Equinix Tier IV-Rechenzentrum in Amsterdam? Nur hier in den Niederlanden! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbit/s 100 TB – ab 99 $! Lesen über
Source: habr.com