HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partionieren.

Wir werden die Arbeit von Zabbix mit der TimescaleDB-Datenbank als Backend betrachten. Wir zeigen, wie man sie von Grund auf startet und wie man von PostgreSQL migriert. Außerdem werden wir vergleichende Leistungstests der beiden Konfigurationen anstellen.

HighLoad++ Sibirien 2019. Raum „Tomsk“. 24. Juni, 16:00. Thesen und Präsentation. Die nächste HighLoad++-Konferenz findet am 6. und 7. April 2020 in St. Petersburg statt. Details und Tickets unter diesem Link.

Andrei Guščin (im Folgenden – AG): – Ich bin Ingenieur im technischen Support von ZABBIX (im Folgenden – „Zabbix“), Trainer. Ich arbeite seit über 6 Jahren im technischen Support und hatte direkten Kontakt mit der Leistung. Heute werde ich über die Leistung sprechen, die TimescaleDB im Vergleich zu herkömmlichem PostgreSQL 10 bieten kann. Auch ein gewisser einführender Teil – darüber, wie es überhaupt funktioniert.

Die größten Herausforderungen in der Leistung: von der Datensammlung bis zur Datenbereinigung

Beginnen wir damit, dass es bestimmte Leistungsherausforderungen gibt, denen jedes Überwachungssystem gegenübersteht. Die erste Herausforderung der Leistung besteht darin, Daten schnell zu sammeln und zu verarbeiten.

Ein gutes Überwachungssystem sollte schnell und rechtzeitig alle Daten erfassen, sie gemäß den Triggerausdrücken verarbeiten, das heißt nach bestimmten Kriterien (in verschiedenen Systemen ist dies unterschiedlich) und in der Datenbank speichern, um diese Daten später zu verwenden.

Die zweite Herausforderung der Leistung besteht darin, die Historie zu speichern. Die Daten in der Datenbank zu speichern und schnellen sowie bequemen Zugriff auf diese Metriken zu haben, die über einen bestimmten Zeitraum gesammelt wurden. Am wichtigsten ist, dass diese Daten leicht abrufbar sind und für Berichte, Grafiken, Trigger, Schwellenwerte für Benachrichtigungen usw. verwendet werden können.

Die dritte Herausforderung der Leistung besteht darin, die Historie zu bereinigen, das heißt, wenn der Tag kommt, an dem Sie bestimmte detaillierte Metriken, die über 5 Jahre gesammelt wurden (sogar Monate oder zwei Monate), nicht mehr speichern müssen. Einige Knoten im Netzwerk wurden gelöscht oder einige Hosts sind nicht mehr erforderlich, da die Metriken veraltet sind und nicht mehr gesammelt werden. All dies muss gereinigt werden, damit Ihre Datenbank nicht auf eine große Größe anwächst. Und im Allgemeinen ist die Bereinigung der Historie oft eine ernsthafte Prüfung für den Speicher – sie wirkt sich oft erheblich auf die Leistung aus.

Wie lösen wir die Probleme mit dem Caching?

Ich werde jetzt konkret über «Zabbix» sprechen. In «Zabbix» werden die ersten und zweiten Aufrufe durch Caching gelöst.

Datensammlung und -verarbeitung – wir verwenden den Arbeitsspeicher, um all diese Daten zu speichern. Jetzt wird über diese Daten genauer berichtet.

Auch auf der Seite der Datenbank gibt es ein gewisses Caching für grundlegende Abfragen – für Diagramme und andere Dinge.

Caching auf der Seite des Zabbix-Servers: Wir haben ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Was ist das?

ConfigurationCache ist der Hauptcache, in dem wir Metriken, Hosts, Datenelemente, Trigger speichern; alles, was für die Verarbeitung von Preprocessing, Datensammlung benötigt wird, von welchen Hosts gesammelt werden soll und in welcher Häufigkeit. All dies wird im ConfigurationCache gespeichert, um nicht immer auf die Datenbank zugreifen und überflüssige Anfragen erstellen zu müssen. Nach dem Start des Servers aktualisieren wir diesen Cache (erstellen ihn) und aktualisieren ihn regelmäßig (je nach Konfigurationseinstellungen).

Caching in Zabbix. Datensammlung

Hier ist das Schema ausreichend groß:

Die Hauptakteure im Schema sind diese Sammler:

Das sind die eigentlichen Sammelprozesse, verschiedene «Poller», die für unterschiedliche Arten von Abfragen verantwortlich sind. Sie sammeln Daten über ICMP, IPMI, verschiedene Protokolle und leiten alles an das Preprocessing weiter.

PreProcessing HistoryCache

Außerdem, wenn wir berechnete Datenelemente haben (wer mit «Zabbix» vertraut ist, weiß das), gibt es berechnete, aggregierte Datenelemente – wir beziehen sie direkt aus dem ValueCache. Wie er gefüllt wird, werde ich später erläutern. Alle diese Sammler nutzen ConfigurationCache, um ihre Aufgaben zu erhalten, und leiten sie dann zum Preprocessing weiter.

Das Preprocessing nutzt ebenfalls ConfigurationCache, um die Schritte zu erhalten, bearbeitet diese Daten auf vielfältige Weise. Seit Version 4.2 wurde es auf einen Proxy ausgelagert. Das ist sehr praktisch, da das Preprocessing selbst eine recht anspruchsvolle Aufgabe ist. Und wenn Sie ein sehr großes «Zabbix» mit einer großen Anzahl von Datenelementen und einer hohen Abfragerate haben, erleichtert das die Arbeit erheblich.

Dementsprechend, nachdem wir diese Daten auf irgendeine Weise mit Hilfe des Preprocessings bearbeitet haben, speichern wir sie im HistoryCache, um sie weiter zu verarbeiten. Damit endet die Datensammlung. Wir kommen zum Hauptprozess.

Arbeit des History Syncers

Der wichtigste Prozess in „Zabbix“ (da es sich um eine monolithische Architektur handelt) ist der History Syncer. Dies ist der Hauptprozess, der sich mit der atomaren Verarbeitung jedes Datenelements beschäftigt, also jedes Wertes.

• ein Wert kommt (er entnimmt ihn aus dem HistoryCache);
• überprüft im Configuration Syncer: Gibt es Trigger für Berechnungen – er berechnet sie;
  wenn ja – erstellt er Ereignisse, erstellt eine Eskalation, um eine Benachrichtigung zu erzeugen, wenn dies gemäß der Konfiguration erforderlich ist;
• speichert Trigger für die spätere Verarbeitung, Aggregation; wenn Sie aggregieren, z. B. in der letzten Stunde, merkt sich dieser Wert den ValueCache, um nicht auf die Historientabelle zugreifen zu müssen; so wird der ValueCache mit den notwendigen Daten gefüllt, die zur Berechnung der Trigger, der berechneten Elemente usw. benötigt werden;
• darüber hinaus speichert der History Syncer alle Daten in der Datenbank;
• die Datenbank schreibt sie auf die Festplatte – damit endet der Verarbeitungsprozess.

Datenbanken. Caching

Auf der Datenbankseite, wenn Sie Grafiken oder Berichte über Ereignisse sehen möchten, gibt es verschiedene Caches. Aber im Rahmen dieses Vortrags werde ich nicht darüber sprechen.

Für MySQL gibt es den Innodb_buffer_pool und eine Menge anderer Caches, die ebenfalls konfiguriert werden können.
Aber das sind die Hauptsachen:

• shared_buffers;
• effective_cache_size;
• shared_pool.

Ich habe für alle Datenbanken aufgeführt, dass es bestimmte Caches gibt, die es ermöglichen, die häufig benötigten Daten im Arbeitsspeicher zu halten. Dort haben sie ihre eigenen Technologien dafür.

Zur Datenbankleistung

Dementsprechend gibt es ein wettbewerbsfähiges Umfeld, das heißt, der „Zabbix“-Server sammelt Daten und schreibt sie. Beim Neustart liest er ebenfalls aus der Historie, um den ValueCache zu füllen usw. Gleichzeitig können Sie Skripte und Berichte haben, die die „Zabbix“-API verwenden, die auf der webbasierten Benutzeroberfläche basiert. Die „Zabbix“-API greift auf die Datenbank zu und erhält die benötigten Daten für Grafiken, Berichte oder eine Liste von Ereignissen, den letzten Problemen.

Auch eine sehr beliebte Lösung zur Visualisierung ist Grafana, die von unseren Nutzern verwendet wird. Es kann sowohl direkt über die „Zabbix“-API als auch über die Datenbank eingreifen. Es schafft ebenfalls einen gewissen Wettbewerb um den Datenzugriff: Eine feinere, gute Datenbankkonfiguration ist erforderlich, um schnelle Ergebnisse und Tests zu gewährleisten.

Geschichte löschen. In Zabbix gibt es den Housekeeper

Ein dritter Aufruf, der in "Zabbix" verwendet wird, ist das Löschen der Geschichte mithilfe des Housekeepers. Der "Housekeeper" beachtet alle Einstellungen, das heißt, in unseren Datenelementen ist angegeben, wie lange (in Tagen) die Daten gespeichert werden sollen, wie lange Trends und Änderungsdynamiken gespeichert werden.

Ich habe nichts über den TrendCache gesagt, den wir in Echtzeit berechnen: Daten kommen herein, wir aggregieren sie über eine Stunde (hauptsächlich handelt es sich um Zahlen der letzten Stunde), die durchschnittliche/minimale Anzahl und schreiben dies einmal pro Stunde in die Änderungsdynamikstabelle ("Trends"). Der "Housekeeper" wird gestartet und löscht die Daten mit normalen Selects aus der DB, was nicht immer effizient ist.

Wie erkennt man, dass das ineffizient ist? Sie können in den Performancegrafiken der internen Prozesse folgendes Bild sehen:

Ihr History syncer ist ständig beschäftigt (rote Grafik). Und die "orange" Linie, die oben verläuft, ist der "Housekeeper", der gestartet wird und darauf wartet, dass die DB alle Zeilen löscht, die er festgelegt hat.

Nehmen wir eine beliebige Item-ID: Die letzten 5000 müssen gelöscht werden; natürlich nach Indizes. Aber normalerweise ist das Dataset recht groß – die Datenbank liest dies trotzdem von der Festplatte und hebt es in den Cache, und das ist eine sehr kostspielige Operation für die DB. Je nach Größe kann dies zu bestimmten Performanceproblemen führen.

Der "Housekeeper" lässt sich einfach deaktivieren – wir haben die allen bekannten Weboberfläche. Die Einstellung in der Administration general (Einstellungen für den "Housekeeper") deaktiviert das interne Housekeeping für die interne Geschichte und die Trends. Folglich verwaltet der "Housekeeper" dies nicht mehr:

Was kann man als Nächstes tun? Sie haben ihn deaktiviert, Ihre Grafiken haben sich eingependelt... Welche Probleme können in diesem Fall noch auftreten? Was kann helfen?

Partitionierung

Normalerweise wird dies auf jeder relationalen Datenbank, die ich aufgezählt habe, auf unterschiedliche Weise eingerichtet. MySQL hat seine eigene Technologie. Aber insgesamt sind sie sehr ähnlich, wenn wir über PostgreSQL 10 und MySQL sprechen. Natürlich gibt es viele interne Unterschiede, wie das alles umgesetzt wird und wie sich das auf die Performance auswirkt. Aber insgesamt führt das Anlegen einer neuen Partition oft ebenfalls zu bestimmten Problemen.

Je nach Ihrem Setup (wie viele Daten Sie an einem Tag generieren) wird normalerweise das Minimum festgelegt – das sind 1 Tag/Partition, und für „Trends“, Veränderungen – 1 Monat/neue Partition. Dies kann sich ändern, wenn Ihr Setup sehr groß ist.

Lassen Sie mich gleich zu den Größen des Setups sagen: Bis zu 5.000 neue Werte pro Sekunde (nvps, wie man so schön sagt) gelten als kleines „Setup“. Mittelgroß sind 5 bis 25 Tausend Werte pro Sekunde. Alles darüber hinaus ist bereits große und sehr große Installationen, die eine sehr sorgfältige Datenbankkonfiguration erfordern.

Bei sehr großen Installationen ist 1 Tag möglicherweise nicht optimal. Ich habe persönlich auf MySQL Partitionen von 40 Gigabyte pro Tag (und mehr) gesehen. Dies ist ein sehr großes Datenvolumen, das zu Problemen führen kann. Es muss reduziert werden.

Warum ist Partitionierung notwendig?

Was Partitionierung bietet, denke ich, wissen alle – das ist die Zerlegung von Tabellen. Oft sind das separate Dateien auf der Festplatte und span-abfragen. Es wählt eine Partition optimaler aus, wenn es in die normale Partitionierung passt.

Für „Zabbix“ wird insbesondere nach Reichweite, das heißt nach Zeitstempel (eine gewöhnliche Zahl, Zeit seit Beginn der Epoche) partitioniert. Sie setzen den Beginn des Tages/Ende des Tages, und dies bildet die Partition. Entsprechend, wenn Sie auf Daten von vor zwei Tagen zugreifen, wird alles schneller aus der Datenbank abgerufen, weil nur eine Datei in den Cache geladen und ausgegeben werden muss (nicht eine große Tabelle).

Viele DBs arbeiten auch bei Inserts (Einfügungen in eine Child-Tabelle) schneller. Während ich abstrakt spreche, ist das auch möglich. Partitionierung hilft oft.

Elasticsearch für NoSQL

Neu in 3.4 haben wir eine Lösung für NoSQL implementiert. Wir haben die Möglichkeit hinzugefügt, in Elasticsearch zu schreiben. Sie können bestimmte Typen wählen: entweder Zahlen oder bestimmte Zeichen; wir haben String-Text, Logs können Sie in Elasticsearch schreiben… Entsprechend wird das Web-Interface auch auf Elasticsearch zugreifen. Das funktioniert in manchen Fällen hervorragend, kann aber momentan genutzt werden.

TimescaleDB. Hypertabellen

Für 4.4.2 haben wir auf eine Sache geachtet, wie TimescaleDB. Was ist das? Es ist eine Erweiterung für PostgreSQL, das bedeutet, es hat eine native PostgreSQL-Schnittstelle. Darüber hinaus ermöglicht diese Erweiterung eine viel effizientere Arbeit mit Zeitserien-Daten und hat ein automatisches Partionierungssystem. So sieht das aus:

Das ist ein Hypertable – ein Konzept in Timescale. Das ist die Hypertabelle, die Sie erstellen, und darin befinden sich Chunks. Chunks sind Partitionen, dies sind Kind-Tabellen, wenn ich mich nicht irre. Das ist wirklich effizient.

TimescaleDB und PostgreSQL

Die Hersteller von TimescaleDB versichern, dass sie einen besseren Algorithmus zur Bearbeitung von Anfragen verwenden, insbesondere von Inserts, der es ermöglicht, eine nahezu konstante Leistung bei wachsendem Datensatzvolumen zu gewährleisten. Nach 200 Millionen Zeilen beginnt ein gewöhnliches PostgreSQL-System, erheblich langsamer zu werden und verliert seine Leistung fast auf null, während Timescale es ermöglicht, Inserts so effizient wie möglich bei beliebiger Datenmenge einzufügen.

Wie installiere ich TimescaleDB? Ganz einfach!

In der Dokumentation gibt es es, es ist beschrieben – Sie können es aus den Paketen für alle installieren… Es hängt von den offiziellen PostgreSQL-Paketen ab. Man kann es manuell kompilieren. So kam es, dass ich für die Datenbank kompilieren musste.

In Zabbix aktivieren wir einfach die Extension. Ich denke, dass diejenigen, die die Extension in PostgreSQL verwendet haben… Sie aktivieren einfach die Extension, erstellen sie für die Zabbix-Datenbank, die Sie nutzen.

Und der letzte Schritt…

TimescaleDB. Migration von Historientabellen

Sie müssen einen Hypertable erstellen. Dafür gibt es eine spezielle Funktion – Create hypertable. Im ersten Parameter geben Sie die Tabelle an, die in dieser Datenbank benötigt wird (für die die Hypertabelle erstellt werden soll).

Feld, nach dem erstellt werden soll, und chunk_time_interval (dies ist der Chunk-Zeitintervall (Partitionen, die verwendet werden sollen). 86.400 – das ist ein Tag.

Parameter migrate_data: Wenn Sie ihn auf true setzen, werden alle aktuellen Daten in die zuvor erstellten Chunks verschoben.

Ich habe selbst migrate_data verwendet – es dauert eine beträchtliche Zeit, je nach Größe Ihrer Datenbank. Ich hatte mehr als ein Terabyte – die Erstellung dauerte mehr als eine Stunde. In einigen Fällen habe ich während der Tests historische Daten für den Text (history_text) und den String (history_str) gelöscht, um sie nicht zu übertragen – sie waren mir tatsächlich nicht interessant.

Und das letzte Update nehmen wir in unserer db_extension vor: Wir installieren TimescaleDB, damit die DB und insbesondere unser „Zabbix“ verstehen, dass es eine db_extension gibt. Diese aktiviert es und verwendet die Syntax und Abfragen zur DB korrekt, indem es die bereits erforderlichen „Features“ für TimescaleDB nutzt.

Serverkonfiguration

Ich habe zwei Server verwendet. Der erste Server ist eine ziemlich kleine virtuelle Maschine mit 20 Prozessoren und 16 Gigabyte RAM. Ich habe darauf PostgreSQL 10.8 eingerichtet:

Das Betriebssystem war Debian, das Dateisystem – xfs. Ich habe minimale Einstellungen vorgenommen, um genau diese Datenbank zu verwenden, abgesehen davon, dass auch „Zabbix“ selbst verwendet wird. Auf demselben Rechner waren der „Zabbix“-Server, PostgreSQL und Lastagenten installiert.

Ich habe 50 aktive Agenten verwendet, die LoadableModule nutzen, um schnell verschiedene Ergebnisse zu generieren. Diese erzeugten Zeilen, Zahlen und so weiter. Ich habe die DB mit einer großen Menge Daten gefüllt. Die anfängliche Konfiguration umfasste 5.000 Datenelemente pro Host, und ungefähr jedes Datenelement hatte einen Trigger – um eine reale Konfiguration zu erstellen. Manchmal ist sogar mehr als ein Trigger erforderlich.

Ich habe das Update-Intervall geregelt, indem ich nicht nur 50 Agenten verwendet habe (ich habe weitere hinzugefügt), sondern auch mit Hilfe dynamischer Datenelemente und das Update-Intervall auf 4 Sekunden reduziert.

Leistungstest. PostgreSQL: 36.000 NVPs

Der erste Lauf, die erste Konfiguration war auf einer reinen PostgreSQL 10-Installation auf dieser Hardware (35.000 Werte pro Sekunde). Im Allgemeinen, wie auf dem Bildschirm sichtbar, dauert das Einfügen von Daten Bruchteile einer Sekunde – alles läuft gut und schnell, SSD-Festplatten (200 Gigabyte). Das Einzige, was ist, dass 20 GB ziemlich schnell gefüllt werden.

Es wird weiterhin viele solcher Diagramme geben. Dies ist das Standard-Dashboard für die Leistung des „Zabbix“-Servers.

Das erste Diagramm – die Anzahl der Werte pro Sekunde (blau, oben links), 35.000 Werte in diesem Fall. Dies (oben in der Mitte) ist die Auslastung der Sammlungsprozesse, und dies (oben rechts) ist die Auslastung der internen Prozesse: History Syncers und Housekeeper, der hier (unten in der Mitte) eine beträchtliche Zeit in Anspruch nahm.

Dieses Diagramm (unten in der Mitte) zeigt die Nutzung des ValueCache – wie viele ValueCache-Treffer für Trigger (einige tausend Werte pro Sekunde). Ein weiteres wichtiges Diagramm ist das vierte (unten links), das die Nutzung des HistoryCache zeigt, von dem ich gesprochen habe, der ein Puffer vor dem Einfügen in die DB ist.

Leistungstest. PostgreSQL: 50 Tausend NVPs

Danach habe ich die Belastung auf 50 Tausend Werte pro Sekunde auf derselben Hardware erhöht. Beim Laden mit dem „Hauskeeper“ wurden 10 Tausend Werte bereits in 2-3 Sekunden mit Berechnung geschrieben. Das wird im nächsten Screenshot gezeigt:

Der „Hauskeeper“ fängt an, die Arbeit zu stören, aber insgesamt liegt die Auslastung der History-Sync-Server noch bei 60 % (drittes Diagramm, oben rechts). Der HistoryCache beginnt während der Arbeit des „Hauskeepers“ aktiv gefüllt zu werden (unten links). Er lag bei etwa einem halben Gigabyte und füllte sich um 20%.

Leistungstest. PostgreSQL: 80 Tausend NVPs

Ich habe die Belastung auf 80 Tausend Werte pro Sekunde erhöht:

Das waren etwa 400 Tausend Datenelemente, 280 Tausend Trigger. Wie Sie sehen können, war die Einfügebelastung der History-Sync-Server (es gab 30 Stück) bereits ziemlich hoch. Danach habe ich verschiedene Parameter erhöht: History-Sync-Server, Cache... Auf dieser Hardware begann die Auslastung der History-Sync-Server, sich dem Maximum zu nähern, praktisch „in die Höhe“ – entsprechend stieg die Auslastung des HistoryCache sehr stark an:

Während dieser ganzen Zeit habe ich alle Systemparameter überwacht (wie CPU und RAM genutzt werden) und festgestellt, dass die Festplattenauslastung maximal war – ich hatte die maximale Kapazität dieser Festplatte auf dieser Hardware, auf dieser virtuellen Maschine, erreicht. PostgreSQL begann bei solcher Intensität, Daten ziemlich aktiv abzulehnen, und die Festplatte konnte nicht schnell genug schreiben und lesen...

Ich habe einen anderen Server genommen, der bereits 48 Prozessoren und 128 Gigabyte RAM hatte:

Außerdem habe ich ihn „aufgerüstet“ – ich habe 60 History-Sync-Server installiert und eine akzeptable Leistung erreicht. Tatsächlich sind wir nicht „in die Höhe“, aber das ist wahrscheinlich schon das Leistungslimit, wo man damit etwas unternehmen muss.

Leistungstest. TimescaleDB: 80 Tausend NVPs

Ich hatte die Hauptaufgabe – TimescaleDB zu nutzen. In jedem Diagramm ist ein Einbruch zu sehen:

Diese Ausfälle entsprechen genau der Migration von Daten. Danach hat sich das Profil des History-Sinkers auf dem 'Zabbix'-Server, wie Sie sehen, deutlich verändert. Es erlaubt, Daten fast dreimal schneller einzufügen und benötigt weniger HistoryCache – entsprechend werden Ihnen die Daten rechtzeitig bereitgestellt. Wieder einmal: 80.000 Werte pro Sekunde – das ist eine ziemlich hohe Rate (natürlich nicht für 'Yandex'). Insgesamt handelt es sich um ein recht großes Setup mit einem Server.

Leistungstest von PostgreSQL: 120.000 NVPs

Dann habe ich die Anzahl der Datenelemente auf eine halbe Million erhöht und einen berechneten Wert von 125.000 pro Sekunde erhalten:

Und ich habe solche Grafiken erhalten:

Im Prinzip ist dies ein funktionierendes Setup, es kann eine recht lange Zeit arbeiten. Aber da ich nur eine Festplatte mit 1,5 Terabyte hatte, habe ich sie in ein paar Tagen verbraucht. Das Wichtigste ist, dass zur gleichen Zeit neue Partitionen auf TimescaleDB erstellt wurden und das für die Leistung vollkommen unauffällig war, was man von MySQL nicht sagen kann.

Normalerweise werden Partitionen nachts erstellt, da dies das Einfügen und die Arbeit mit Tabellen insgesamt blockiert und zu einer Verschlechterung des Services führen kann. In diesem Fall ist das nicht der Fall! Die Hauptaufgabe war es – die Möglichkeiten von TimescaleDB zu überprüfen. Es ergab sich eine Zahl von 120.000 Werten pro Sekunde.

Es gibt auch Beispiele in der 'Community':

Eine Person hat ebenfalls TimescaleDB aktiviert und die Belastung durch die Verwendung von io.weight ist auf dem Prozessor gesunken; auch die Nutzung interner Prozesse wurde durch die Aktivierung von TimescaleDB verringert. Dabei handelt es sich um normale HDDs, also um eine normale virtuelle Maschine auf normalen Festplatten (nicht SSD)!

Für einige kleine Setups, die an der Leistung der Festplatte scheitern, scheint mir TimescaleDB eine sehr gute Lösung zu sein. Es wird es recht gut ermöglichen, bis zur Migration auf schnellere Hardware für die Datenbank weiter zu arbeiten.

Ich lade Sie alle zu unseren Veranstaltungen ein: Conference – in Moskau, Summit – in Riga. Nutzen Sie unsere Kanäle – 'Telegram', Forum, IRC. Wenn Sie Fragen haben – kommen Sie zu unserem Stand, wir können über alles sprechen.

Fragen aus dem Publikum

Frage aus dem Publikum (im Folgenden – A): – Wenn TimescaleDB so einfach einzurichten ist und so viel Leistungsteigerung bietet, wäre es dann vielleicht eine gute Idee, dies als beste Praxis für die Einrichtung von "Zabbix" mit "Postgres" zu verwenden? Gibt es irgendwelche potenziellen Fallen oder Nachteile dieser Lösung, oder kann ich, wenn ich mich für "Zabbix" entschieden habe, beruhigt "Postgres" nehmen, direkt "Timescale" installieren, es nutzen und mir keine Sorgen um irgendwelche Probleme machen?

AG: – Ja, ich würde sagen, dass dies eine gute Empfehlung ist: Verwenden Sie "Postgres" gleich mit der Erweiterung TimescaleDB. Wie ich bereits erwähnt habe, gibt es viele gute Rückmeldungen, obwohl dieses "Feature" experimentell ist. Aber die Tests zeigen tatsächlich, dass es eine hervorragende Lösung (mit TimescaleDB) ist, und ich denke, dass es sich weiterentwickeln wird! Wir beobachten, wie sich diese Erweiterung entwickelt, und werden anpassen, was notwendig ist.

Selbst während der Entwicklung haben wir uns auf eines ihrer bekannten "Features" gestützt: dort konnte man mit Chunks etwas anders arbeiten. Aber dann haben sie es in der nächsten Version entfernt, und wir mussten uns nicht mehr auf diesen Code stützen. Ich würde empfehlen, diese Lösung in vielen Setups zu verwenden. Wenn Sie MySQL verwenden... Für mittlere Setups funktioniert jede Lösung ganz gut.

A: – In den letzten Diagrammen, die von der Community stammen, gab es ein Diagramm mit "Housekeeping":

Es hat weiter funktioniert. Was macht "Housekeeping" im Fall von TimescaleDB?

AG: – Im Moment kann ich das nicht genau sagen – ich werde den Code anschauen und genauer darauf eingehen. Es verwendet Anfragen von TimescaleDB nicht zum Löschen von Chunks, sondern aggregiert irgendwie. Ich bin nicht bereit, diese technische Frage jetzt zu beantworten. Wir werden es heute oder morgen am Stand klären.

A: – Ich habe eine ähnliche Frage – zur Leistung der Löschoperation in "Timescale".
A (Antwort aus dem Publikum): – Wenn Sie Daten aus einer Tabelle löschen, und wenn Sie das über delete tun, müssen Sie die Tabelle durchgehen – löschen, aufräumen, alles für die zukünftige Vakuumierung markieren. In "Timescale" können Sie, da Sie Chunks haben, diese einfach entsorgen. Grob gesagt, sagen Sie nur zur Datei, die in den Big Data liegt: „Löschen!“

„Timescale“ versteht einfach, dass es diesen Chunk nicht mehr gibt. Da es in den Abfrageplaner integriert ist, erfasst es Ihre Bedingungen im Select oder in anderen Operationen und erkennt sofort, dass es diesen Chunk nicht mehr gibt – „Ich gehe dort nicht mehr hin!“ (Daten fehlen). Das ist alles! Das bedeutet, das Scannen der Tabelle wird durch das Löschen der Binärdatei ersetzt, deshalb ist das schnell.

A: – Wir haben das Thema NoSQL bereits angesprochen. Soweit ich verstehe, ist es für „Zabbix“ nicht unbedingt nötig, Daten zu modifizieren, denn das ist alles eher eine Art Log. Kann man spezialisierte Datenbanken verwenden, die ihre Daten nicht ändern können, aber dabei viel schneller speichern, sammeln und bereitstellen – Clickhouse zum Beispiel, oder etwas Kafka-ähnliches? .. Kafka ist doch auch ein Log! Kann man die irgendwie integrieren?

AG: – Einen Export kann man machen. Wir haben ab Version 3.4 eine bestimmte „Funktion“: Sie können alle historischen Dateien, Events und alles andere in Dateien schreiben; und dann mit einem Handler an jede andere Datenbank senden. Tatsächlich machen viele das und schreiben direkt in die Datenbank. Die Histogramm-Synchronisatoren schreiben das alles in Dateien, rotieren diese Dateien usw., und das können Sie in „Clickhouse“ übertragen. Ich kann nichts zu den Plänen sagen, aber vielleicht wird die weitere Unterstützung von NoSQL-Lösungen (wie „Clickhouse“) fortgesetzt.

A: – Also, kann man im Grunde ganz auf PostgreSQL verzichten?

AG: – Natürlich, der schwierigste Teil bei „Zabbix“ sind die historischen Tabellen, die die meisten Probleme verursachen, und die Events. In diesem Fall, wenn Sie Events nicht lange speichern und die Historie mit Trends in einem anderen schnellen Speicher aufbewahren, denke ich, dass es im Allgemeinen keine Probleme geben wird.

A: – Können Sie einschätzen, wie viel schneller alles funktionieren wird, wenn man auf „Clickhouse“ umschaltet?

AG: – Ich habe das nicht getestet. Ich denke, dass man mindestens dieselben Zahlen relativ einfach erreichen kann, wenn man bedenkt, dass „Clickhouse“ seine eigene Schnittstelle hat, aber ich kann nicht eindeutig sagen. Es ist besser, es zu testen. Alles hängt von der Konfiguration ab: wie viele Hosts Sie haben usw. Das Einfügen ist das eine, aber man muss diese Daten auch abholen – entweder mit Grafana oder etwas anderem.

A: – Also geht es um einen gleichwertigen Wettbewerb und nicht um einen großen Vorteil dieser schnellen Datenbanken?

AG: – Ich denke, wenn wir integrieren, wird es genauere Tests geben.

A: – Wo ist das alte, gute RRD hingekommen? Was hat dazu geführt, dass auf SQL-Datenbanken umgestiegen wurde? Ursprünglich wurden alle Metriken ja auf RRD gesammelt.

AG: – In "Zabbix" gab es RRD vielleicht in einer sehr alten Version. SQL-Datenbanken waren immer vorhanden – der klassische Ansatz. Der klassische Ansatz sind MySQL, PostgreSQL (existiert schon seit sehr langer Zeit). Wir haben die gemeinsame Schnittstelle für SQL-Datenbanken und RRD praktisch nie genutzt.

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