Wir werden uns ansehen, wie Zabbix mit der TimescaleDB-Datenbank als Backend funktioniert. Wir zeigen Ihnen, wie Sie bei Null anfangen und von PostgreSQL migrieren. Wir werden auch vergleichende Leistungstests der beiden Konfigurationen anbieten.
HighLoad++ Sibirien 2019. Tomsker Saal. 24. Juni, 16:00 Uhr. Thesen und . Die nächste HighLoad++-Konferenz findet am 6. und 7. April 2020 in St. Petersburg statt. Details und Tickets .
Andrey Gushchin (im Folgenden – AG): – Ich bin ein technischer Support-Ingenieur von ZABBIX (im Folgenden „Zabbix“ genannt) und ein Trainer. Ich arbeite seit mehr als 6 Jahren im technischen Support und habe direkte Erfahrungen mit der Leistung. Heute werde ich über die Leistung sprechen, die TimescaleDB im Vergleich zu regulärem PostgreSQL 10 bieten kann. Außerdem gibt es einen einführenden Teil darüber, wie es im Allgemeinen funktioniert.
Die größten Produktivitätsherausforderungen: von der Datenerfassung bis zur Datenbereinigung
Zunächst einmal gibt es bestimmte Leistungsherausforderungen, mit denen jedes Überwachungssystem konfrontiert ist. Die erste Produktivitätsherausforderung besteht darin, Daten schnell zu sammeln und zu verarbeiten.
Ein gutes Überwachungssystem sollte alle Daten schnell und zeitnah empfangen, sie nach Triggerausdrücken verarbeiten, d Zukunft.
Die zweite Leistungsherausforderung ist die Speicherung des Verlaufs. Speichern Sie diese Metriken, die über einen bestimmten Zeitraum gesammelt wurden, häufig in einer Datenbank und haben Sie schnellen und bequemen Zugriff darauf. Das Wichtigste ist, dass diese Daten bequem zu erhalten sind und dass sie in Berichten, Diagrammen, Auslösern, in einigen Schwellenwerten, für Warnungen usw. verwendet werden können.
Die dritte Leistungsherausforderung ist das Löschen des Verlaufs, d. h. wenn Sie den Punkt erreichen, an dem Sie keine detaillierten Metriken mehr speichern müssen, die über einen Zeitraum von fünf Jahren (sogar Monaten oder zwei Monaten) gesammelt wurden. Einige Netzwerkknoten wurden gelöscht oder einige Hosts. Die Metriken werden nicht mehr benötigt, da sie bereits veraltet sind und nicht mehr erfasst werden. All dies muss bereinigt werden, damit Ihre Datenbank nicht zu groß wird. Im Allgemeinen ist das Löschen des Verlaufs meist ein ernsthafter Test für den Speicher – es hat oft einen sehr starken Einfluss auf die Leistung.
Wie löst man Caching-Probleme?
Ich werde jetzt speziell auf Zabbix eingehen. In Zabbix werden der erste und der zweite Aufruf mithilfe von Caching gelöst.
Datenerfassung und -verarbeitung – Wir verwenden RAM, um alle diese Daten zu speichern. Auf diese Daten wird nun näher eingegangen.
Auch auf der Datenbankseite gibt es etwas Caching für Hauptauswahlen – für Grafiken und andere Dinge.
Caching auf der Seite des Zabbix-Servers selbst: Wir haben ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Was ist das?
ConfigurationCache ist der Hauptcache, in dem wir Metriken, Hosts, Datenelemente und Trigger speichern. Alles, was Sie zum Vorverarbeiten, Sammeln von Daten und von welchen Hosts mit welcher Häufigkeit benötigen. All dies wird im ConfigurationCache gespeichert, um nicht in die Datenbank zu gelangen und unnötige Abfragen zu erstellen. Nachdem der Server gestartet ist, aktualisieren wir diesen Cache (erstellen ihn) und aktualisieren ihn regelmäßig (abhängig von den Konfigurationseinstellungen).
Caching in Zabbix. Datensammlung
Hier ist das Diagramm ziemlich groß:
Die wichtigsten im Schema sind diese Sammler:
Dies sind die Montageprozesse selbst, verschiedene „Poller“, die für verschiedene Arten von Baugruppen verantwortlich sind. Sie sammeln Daten über ICMP, IPMI und verschiedene Protokolle und übergeben sie an die Vorverarbeitung.
Vorverarbeitungs-HistoryCache
Wenn wir außerdem berechnete Datenelemente haben (wer mit Zabbix vertraut ist, wissen es), also berechnete Aggregationsdatenelemente, übernehmen wir diese direkt aus ValueCache. Wie es gefüllt wird, erzähle ich euch später. Alle diese Collectors verwenden ConfigurationCache, um ihre Jobs zu empfangen und sie dann an die Vorverarbeitung weiterzuleiten.
Die Vorverarbeitung verwendet auch ConfigurationCache, um Vorverarbeitungsschritte abzurufen, und verarbeitet diese Daten auf verschiedene Weise. Ab Version 4.2 haben wir es auf einen Proxy verschoben. Dies ist sehr praktisch, da die Vorverarbeitung selbst ein ziemlich schwieriger Vorgang ist. Und wenn Sie über ein sehr großes Zabbix mit einer großen Anzahl von Datenelementen und einer hohen Erfassungshäufigkeit verfügen, vereinfacht dies die Arbeit erheblich.
Dementsprechend speichern wir diese Daten, nachdem wir sie in irgendeiner Weise durch Vorverarbeitung verarbeitet haben, im HistoryCache, um sie weiter zu verarbeiten. Damit ist die Datenerhebung abgeschlossen. Wir gehen zum Hauptprozess über.
Die Arbeit des History Syncers
Der Hauptprozess in Zabbix (da es sich um eine monolithische Architektur handelt) ist der History Syncer. Dies ist der Hauptprozess, der sich speziell mit der atomaren Verarbeitung jedes Datenelements, also jedes Werts, befasst:
- der Wert kommt (er übernimmt ihn vom HistoryCache);
- prüft im Konfigurations-Syncer, ob Auslöser für die Berechnung vorhanden sind – berechnet diese;
falls vorhanden - erstellt Ereignisse, erstellt eine Eskalation, um eine Warnung zu erstellen, ggf. entsprechend der Konfiguration; - zeichnet Auslöser für die nachfolgende Verarbeitung und Aggregation auf; Wenn Sie über die letzte Stunde usw. aggregieren, wird dieser Wert von ValueCache gespeichert, sodass er nicht in die Verlaufstabelle gelangt. Somit wird der ValueCache mit den notwendigen Daten gefüllt, die zur Berechnung von Triggern, berechneten Elementen usw. notwendig sind;
- dann schreibt der History Syncer alle Daten in die Datenbank;
- die Datenbank schreibt sie auf die Festplatte – hier endet der Verarbeitungsprozess.
Datenbank. Caching
Wenn Sie auf der Datenbankseite Diagramme oder Berichte zu Ereignissen anzeigen möchten, stehen Ihnen verschiedene Caches zur Verfügung. Aber in diesem Bericht werde ich nicht darüber sprechen.
Für MySQL gibt es Innodb_buffer_pool und eine Reihe verschiedener Caches, die ebenfalls konfiguriert werden können.
Aber das sind die wichtigsten:
- shared_buffers;
- effektive_cache_größe;
- Gemeinschaftspool.
Für alle Datenbanken habe ich gesagt, dass es bestimmte Caches gibt, die es ermöglichen, die Daten, die häufig für Abfragen benötigt werden, im RAM zu speichern. Dafür verfügen sie über eigene Technologien.
Informationen zur Datenbankleistung
Dementsprechend herrscht ein Wettbewerbsumfeld, das heißt, der Zabbix-Server sammelt Daten und zeichnet diese auf. Beim Neustart liest es auch aus dem Verlauf, um den ValueCache usw. zu füllen. Hier können Sie Skripte und Berichte erstellen, die die Zabbix-API verwenden, die auf einer Weboberfläche basiert. Die Zabbix-API betritt die Datenbank und empfängt die erforderlichen Daten, um Diagramme, Berichte oder eine Art Liste von Ereignissen und aktuellen Problemen zu erhalten.
Eine sehr beliebte Visualisierungslösung ist auch Grafana, die unsere Benutzer verwenden. Möglichkeit der direkten Anmeldung sowohl über die Zabbix-API als auch über die Datenbank. Es entsteht auch ein gewisser Wettbewerb um die Datenbeschaffung: Eine feinere und bessere Abstimmung der Datenbank ist erforderlich, um die schnelle Lieferung von Ergebnissen und Tests zu ermöglichen.
Verlauf löschen. Zabbix hat eine Haushälterin
Der dritte Aufruf, der in Zabbix verwendet wird, ist das Löschen des Verlaufs mithilfe von Housekeeper. Housekeeper folgt allen Einstellungen, das heißt, unsere Datenelemente geben an, wie lange (in Tagen) gespeichert werden soll, wie lange Trends gespeichert werden sollen und wie die Dynamik der Änderungen ist.
Ich habe nicht über TrendCache gesprochen, den wir im Handumdrehen berechnen: Daten kommen an, wir aggregieren sie für eine Stunde (meistens handelt es sich dabei um Zahlen für die letzte Stunde), die Menge ist Durchschnitt/Minimum und wir zeichnen sie einmal pro Stunde auf Tabelle der Dynamik von Veränderungen („Trends“) . „Housekeeper“ startet und löscht Daten aus der Datenbank mithilfe regelmäßiger Auswahlvorgänge, was nicht immer effektiv ist.
Wie kann man verstehen, dass es unwirksam ist? Auf den Leistungsdiagrammen interner Prozesse können Sie das folgende Bild sehen:
Ihr Verlaufssynchronisierer ist ständig beschäftigt (rote Grafik). Und die „rote“ Grafik oben. Dies ist ein „Housekeeper“, der startet und darauf wartet, dass die Datenbank alle von ihr angegebenen Zeilen löscht.
Nehmen wir eine Artikel-ID: Sie müssen die letzten 5 löschen; natürlich nach Indizes. Aber normalerweise ist der Datensatz ziemlich groß – die Datenbank liest ihn immer noch von der Festplatte und legt ihn in den Cache, und das ist ein sehr kostspieliger Vorgang für die Datenbank. Abhängig von der Größe kann dies zu bestimmten Leistungsproblemen führen.
Sie können Housekeeper auf einfache Weise deaktivieren – wir haben eine vertraute Weboberfläche. Mit den allgemeinen Einstellungen in der Administration (Einstellungen für „Housekeeper“) deaktivieren wir die interne Verwaltung für interne Historie und Trends. Dementsprechend hat die Haushälterin keine Kontrolle mehr über Folgendes:
Was können Sie als nächstes tun? Sie haben es ausgeschaltet, Ihre Grafiken haben sich eingependelt ... Welche weiteren Probleme könnten in diesem Fall auftreten? Was kann helfen?
Partitionierung (Sektionierung)
Normalerweise ist dies in jeder von mir aufgelisteten relationalen Datenbank unterschiedlich konfiguriert. MySQL verfügt über eine eigene Technologie. Aber insgesamt sind sie sich sehr ähnlich, wenn es um PostgreSQL 10 und MySQL geht. Natürlich gibt es viele interne Unterschiede in der Art und Weise, wie alles implementiert wird und wie sich alles auf die Leistung auswirkt. Aber generell führt das Anlegen einer neuen Partition oft auch zu gewissen Problemen.
Abhängig von Ihrem Setup (wie viele Daten Sie an einem Tag erstellen) legen sie normalerweise das Minimum fest – das ist 1 Tag/Charge, und für „Trends“ und die Dynamik von Änderungen – 1 Monat/neue Charge. Dies kann sich ändern, wenn Sie ein sehr großes Setup haben.
Sagen wir gleich die Größe des Setups: bis zu 5 neue Werte pro Sekunde (sogenannte NVPs) – dies wird als kleines „Setup“ betrachtet. Durchschnittlich – von 5 bis 25 Werten pro Sekunde. Alles oben Genannte sind bereits große und sehr große Installationen, die eine sehr sorgfältige Konfiguration der Datenbank erfordern.
Bei sehr großen Installationen ist 1 Tag möglicherweise nicht optimal. Ich persönlich habe Partitionen auf MySQL mit 40 Gigabyte pro Tag gesehen (und es könnten noch mehr sein). Dabei handelt es sich um eine sehr große Datenmenge, die zu einigen Problemen führen kann. Es muss reduziert werden.
Warum brauchen Sie eine Partitionierung?
Was die Partitionierung bietet, ist, glaube ich, jeder weiß, die Tabellenpartitionierung. Oftmals handelt es sich hierbei um separate Dateien auf der Festplatte und um Span-Anfragen. Es wählt eine Partition optimaler aus, wenn sie Teil der normalen Partitionierung ist.
Insbesondere für Zabbix wird es nach Bereich, nach Bereich verwendet, das heißt, wir verwenden einen Zeitstempel (eine reguläre Zahl, Zeit seit Beginn der Epoche). Sie geben den Beginn des Tages/Ende des Tages an, und das ist die Partition. Wenn Sie also Daten anfordern, die zwei Tage alt sind, wird alles schneller aus der Datenbank abgerufen, da Sie nur eine Datei in den Cache laden und zurückgeben müssen (statt einer großen Tabelle).
Viele Datenbanken beschleunigen auch das Einfügen (Einfügen in eine untergeordnete Tabelle). Ich spreche vorerst abstrakt, aber das ist auch möglich. Eine Partitionierung hilft oft.
Elasticsearch für NoSQL
Kürzlich haben wir in 3.4 eine NoSQL-Lösung implementiert. Möglichkeit zum Schreiben in Elasticsearch hinzugefügt. Sie können bestimmte Arten schreiben: Sie wählen – entweder Zahlen oder einige Zeichen schreiben; Wir haben String-Text, Sie können Protokolle in Elasticsearch schreiben ... Dementsprechend greift die Weboberfläche auch auf Elasticsearch zu. Das klappt in manchen Fällen super, im Moment kann es aber genutzt werden.
TimescaleDB. Hypertische
Für 4.4.2 haben wir auf eine Sache wie TimescaleDB geachtet. Was ist das? Dies ist eine Erweiterung für PostgreSQL, das heißt, es verfügt über eine native PostgreSQL-Schnittstelle. Darüber hinaus ermöglicht Ihnen diese Erweiterung ein wesentlich effizienteres Arbeiten mit Zeitreihendaten und eine automatische Partitionierung. Wie es aussieht:
Das ist Hypertable – ein solches Konzept gibt es in Timescale. Dies ist eine von Ihnen erstellte Hypertabelle, die Chunks enthält. Chunks sind Partitionen, das sind untergeordnete Tabellen, wenn ich mich nicht irre. Es ist wirklich effektiv.
TimescaleDB und PostgreSQL
Wie die TimescaleDB-Hersteller versichern, verwenden sie einen korrekteren Algorithmus für die Verarbeitung von Abfragen, insbesondere Einfügungen, was ihnen eine annähernd konstante Leistung mit zunehmender Größe der Datensatzeinfügung ermöglicht. Das heißt, nach 200 Millionen Postgres-Zeilen beginnt das übliche sehr stark durchzuhängen und verliert buchstäblich an Leistung auf Null, während Timescale es Ihnen ermöglicht, Einfügungen bei jeder Datenmenge so effizient wie möglich einzufügen.
Wie installiere ich TimescaleDB? Es ist einfach!
Es steht in der Dokumentation, es wird beschrieben – Sie können es aus Paketen für jedes beliebige installieren... Es hängt von den offiziellen Postgres-Paketen ab. Kann manuell kompiliert werden. So kam es, dass ich für die Datenbank kompilieren musste.
Auf Zabbix aktivieren wir einfach Extention. Ich denke, dass diejenigen, die Extention in Postgres verwendet haben ... Sie aktivieren einfach Extention und erstellen es für die Zabbix-Datenbank, die Sie verwenden.
Und der letzte Schritt...
TimescaleDB. Migration von Verlaufstabellen
Sie müssen eine Hypertabelle erstellen. Dafür gibt es eine spezielle Funktion – Hypertabelle erstellen. Darin ist der erste Parameter die Tabelle, die in dieser Datenbank benötigt wird (für die Sie eine Hypertabelle erstellen müssen).
Das Feld, nach dem erstellt werden soll, und chunk_time_interval (dies ist das Intervall der Chunks (Partitionen, die verwendet werden müssen). 86 ist ein Tag.
Parameter „Migrate_data“: Wenn Sie „true“ einfügen, werden alle aktuellen Daten in vorab erstellte Blöcke migriert.
Ich habe migrate_data selbst verwendet – es dauert ziemlich lange, je nachdem, wie groß Ihre Datenbank ist. Ich hatte über ein Terabyte – die Erstellung dauerte über eine Stunde. In einigen Fällen habe ich während des Tests historische Daten für Text (history_text) und String (history_str) gelöscht, um sie nicht zu übertragen – sie waren für mich nicht wirklich interessant.
Und wir nehmen das letzte Update in unserer db_extention vor: Wir installieren timescaledb, damit die Datenbank und insbesondere unser Zabbix verstehen, dass es db_extention gibt. Er aktiviert es und verwendet die richtige Syntax und Abfragen an die Datenbank, wobei er die „Funktionen“ verwendet, die für TimescaleDB notwendig sind.
Serverkonfiguration
Ich habe zwei Server verwendet. Der erste Server ist eine relativ kleine virtuelle Maschine, 20 Prozessoren, 16 Gigabyte RAM. Ich habe Postgres 10.8 darauf konfiguriert:
Das Betriebssystem war Debian, das Dateisystem war xfs. Ich habe nur minimale Einstellungen vorgenommen, um diese bestimmte Datenbank zu verwenden, abzüglich der Einstellungen, die Zabbix selbst verwenden wird. Auf derselben Maschine befanden sich ein Zabbix-Server, PostgreSQL und Ladeagenten.
Ich habe 50 aktive Agenten verwendet, die LoadableModule verwenden, um schnell unterschiedliche Ergebnisse zu generieren. Sie sind diejenigen, die die Zeichenfolgen, Zahlen usw. generiert haben. Ich habe die Datenbank mit vielen Daten gefüllt. Ursprünglich enthielt die Konfiguration 5 Datenelemente pro Host, und ungefähr jedes Datenelement enthielt einen Trigger – damit es sich um ein echtes Setup handelte. Manchmal benötigen Sie sogar mehr als einen Auslöser.
Ich habe das Aktualisierungsintervall und die Auslastung selbst reguliert, indem ich nicht nur 50 Agenten verwendet habe (mehr hinzugefügt), sondern auch dynamische Datenelemente verwendet und das Aktualisierungsintervall auf 4 Sekunden reduziert habe.
Leistungstest. PostgreSQL: 36 NVPs
Der erste Start, das erste Setup, das ich hatte, war reines PostreSQL 10 auf dieser Hardware (35 Werte pro Sekunde). Im Allgemeinen dauert das Einfügen von Daten, wie Sie auf dem Bildschirm sehen können, Sekundenbruchteile - alles ist gut und schnell, SSD-Laufwerke (200 Gigabyte). Das Einzige ist, dass 20 GB recht schnell voll sind.
Von solchen Grafiken wird es in Zukunft noch eine ganze Menge geben. Dies ist ein standardmäßiges Zabbix-Serverleistungs-Dashboard.
Das erste Diagramm zeigt die Anzahl der Werte pro Sekunde (blau, oben links), in diesem Fall 35 Werte. Dies (oben in der Mitte) ist das Laden von Build-Prozessen und dies (oben rechts) ist das Laden von internen Prozessen: History Syncers und Housekeeper, die hier (unten in der Mitte) schon seit einiger Zeit laufen.
Dieses Diagramm (unten in der Mitte) zeigt die ValueCache-Nutzung – wie viele ValueCache-Treffer für Trigger (mehrere tausend Werte pro Sekunde). Ein weiteres wichtiges Diagramm ist das vierte (unten links), das die Verwendung des HistoryCache zeigt, über den ich gesprochen habe, bei dem es sich um einen Puffer vor dem Einfügen in die Datenbank handelt.
Leistungstest. PostgreSQL: 50 NVPs
Als nächstes habe ich die Last auf derselben Hardware auf 50 Werte pro Sekunde erhöht. Beim Laden durch Housekeeper wurden 10 Werte in 2-3 Sekunden mit Berechnung erfasst. Was tatsächlich im folgenden Screenshot gezeigt wird:
Die „Haushälterin“ fängt bereits an, sich in die Arbeit einzumischen, aber im Allgemeinen liegt die Belastung der geschichtsträchtigen Fallensteller immer noch bei 60 % (dritte Grafik oben rechts). HistoryCache beginnt sich bereits aktiv zu füllen, während Housekeeper läuft (unten links). Es war etwa ein halbes Gigabyte, 20 % voll.
Leistungstest. PostgreSQL: 80 NVPs
Dann habe ich es auf 80 Werte pro Sekunde erhöht:
Es handelte sich um etwa 400 Datenelemente und 280 Auslöser. Wie Sie sehen, war der Einsatz in Bezug auf die Belastung durch Geschichtsverlierer (es waren 30) bereits recht hoch. Dann habe ich verschiedene Parameter erhöht: History Sinker, Cache... Auf dieser Hardware begann die Belastung der History Sinker auf ein Maximum anzusteigen, fast „im Regal“ – dementsprechend geriet HistoryCache in eine sehr hohe Belastung:
Die ganze Zeit über habe ich alle Systemparameter überwacht (wie der Prozessor verwendet wird, RAM) und festgestellt, dass die Festplattenauslastung maximal war – ich habe die maximale Kapazität dieser Festplatte auf dieser Hardware, auf dieser virtuellen Maschine erreicht. „Postgres“ begann mit dieser Intensität ziemlich aktiv Daten auszugeben, und die Festplatte hatte keine Zeit mehr zum Schreiben, Lesen ...
Ich habe einen anderen Server genommen, der bereits 48 Prozessoren und 128 Gigabyte RAM hatte:
Ich habe es auch „abgestimmt“ – den History Syncer installiert (60 Stück) und eine akzeptable Leistung erzielt. Tatsächlich sind wir nicht „im Regal“, aber das ist wahrscheinlich die Grenze der Produktivität, an der es bereits notwendig ist, etwas dagegen zu unternehmen.
Leistungstest. TimescaleDB: 80 NVPs
Meine Hauptaufgabe bestand darin, TimescaleDB zu verwenden. Jede Grafik zeigt einen Rückgang:
Bei diesen Fehlern handelt es sich genau um die Datenmigration. Danach hat sich auf dem Zabbix-Server das Ladeprofil der Verlaufssenker, wie Sie sehen können, stark verändert. Damit können Sie Daten fast dreimal schneller einfügen und weniger HistoryCache verbrauchen – entsprechend werden Ihnen die Daten pünktlich geliefert. Auch hier sind 3 Werte pro Sekunde eine ziemlich hohe Rate (natürlich nicht für Yandex). Insgesamt handelt es sich um ein ziemlich großes Setup mit einem Server.
PostgreSQL-Leistungstest: 120 NVPs
Als nächstes habe ich den Wert der Anzahl der Datenelemente auf eine halbe Million erhöht und einen berechneten Wert von 125 pro Sekunde erhalten:
Und ich habe diese Grafiken:
Im Prinzip handelt es sich hierbei um ein funktionierendes Setup, es kann ziemlich lange funktionieren. Da ich jedoch nur eine 1,5-Terabyte-Festplatte hatte, war diese innerhalb weniger Tage aufgebraucht. Das Wichtigste ist, dass gleichzeitig neue Partitionen auf TimescaleDB erstellt wurden, und dies völlig unbemerkt von der Leistung, was man von MySQL nicht sagen kann.
Typischerweise werden Partitionen nachts erstellt, da dies im Allgemeinen das Einfügen und Arbeiten mit Tabellen blockiert und zu einer Beeinträchtigung des Dienstes führen kann. In diesem Fall ist dies nicht der Fall! Die Hauptaufgabe bestand darin, die Fähigkeiten von TimescaleDB zu testen. Das Ergebnis war folgender Wert: 120 Werte pro Sekunde.
Es gibt auch Beispiele in der Community:
Die Person schaltete auch TimescaleDB ein und die Belastung des Prozessors durch die Verwendung von io.weight sank; und auch der Einsatz interner Prozesselemente ist durch die Einbindung von TimescaleDB zurückgegangen. Darüber hinaus handelt es sich um gewöhnliche Pancake-Festplatten, also eine gewöhnliche virtuelle Maschine auf gewöhnlichen Festplatten (keine SSDs)!
Für einige kleine Setups, die durch die Festplattenleistung eingeschränkt sind, ist TimescaleDB meiner Meinung nach eine sehr gute Lösung. Dadurch können Sie weiterarbeiten, bevor Sie auf schnellere Hardware für die Datenbank migrieren.
Ich lade Sie alle zu unseren Veranstaltungen ein: Konferenz in Moskau, Gipfel in Riga. Nutzen Sie unsere Kanäle – Telegram, Forum, IRC. Wenn Sie Fragen haben, kommen Sie an unseren Schreibtisch, wir können über alles reden.
Fragen des Publikums
Frage aus dem Publikum (im Folgenden – A): – Wenn TimescaleDB so einfach zu konfigurieren ist und eine solche Leistungssteigerung bietet, sollte dies dann vielleicht als Best Practice für die Konfiguration von Zabbix mit Postgres verwendet werden? Und gibt es irgendwelche Fallstricke und Nachteile dieser Lösung, oder kann ich, wenn ich mich entscheide, Zabbix selbst zu erstellen, einfach Postgres nehmen, Timescale sofort dort installieren, es verwenden und nicht über irgendwelche Probleme nachdenken?
AG: – Ja, ich würde sagen, dass dies eine gute Empfehlung ist: Verwenden Sie Postgres sofort mit der TimescaleDB-Erweiterung. Wie ich bereits sagte, viele gute Kritiken, obwohl dieses „Feature“ experimentell ist. Aber tatsächlich zeigen Tests, dass dies eine großartige Lösung ist (mit TimescaleDB) und ich denke, dass sie sich weiterentwickeln wird! Wir beobachten die Entwicklung dieser Erweiterung und werden bei Bedarf Änderungen vornehmen.
Schon bei der Entwicklung haben wir auf eines ihrer bekannten „Features“ gesetzt: Es war möglich, mit Chunks etwas anders zu arbeiten. Aber dann haben sie es in der nächsten Version gestrichen und wir mussten aufhören, uns auf diesen Code zu verlassen. Ich würde die Verwendung dieser Lösung für viele Setups empfehlen. Wenn Sie MySQL verwenden... Für durchschnittliche Setups funktioniert jede Lösung gut.
A: – Auf den letzten Grafiken aus der Community gab es eine Grafik mit „Housekeeper“:
Er arbeitete weiter. Was macht Housekeeper mit TimescaleDB?
AG: – Jetzt kann ich es nicht sicher sagen – ich schaue mir den Code an und erzähle es Ihnen genauer. Es verwendet TimescaleDB-Abfragen nicht, um Blöcke zu löschen, sondern um sie irgendwie zu aggregieren. Ich bin noch nicht bereit, diese technische Frage zu beantworten. Mehr erfahren wir heute oder morgen am Stand.
A: – Ich habe eine ähnliche Frage – zur Leistung des Löschvorgangs in Timescale.
A (Antwort aus dem Publikum): – Wenn Sie Daten aus einer Tabelle löschen, wenn Sie dies über „Löschen“ tun, müssen Sie die Tabelle durchgehen – löschen, bereinigen, alles für die zukünftige Löschung markieren. Da Sie in Timescale Chunks haben, können Sie diese löschen. Grob gesagt sagen Sie der Datei, die sich in Big Data befindet, einfach: „Löschen!“
Timescale versteht einfach, dass ein solcher Teil nicht mehr existiert. Und da es in den Abfrageplaner integriert ist, verwendet es Hooks, um Ihre Bedingungen in ausgewählten oder anderen Vorgängen abzufangen, und erkennt sofort, dass dieser Block nicht mehr existiert – „Da gehe ich nicht mehr hin!“ (keine Daten verfügbar). Das ist alles! Das heißt, ein Tabellenscan wird durch das Löschen einer Binärdatei ersetzt, sodass es schnell geht.
A: – Das Thema Non-SQL haben wir bereits angesprochen. Soweit ich weiß, muss Zabbix die Daten nicht wirklich ändern, und das alles ist so etwas wie ein Protokoll. Ist es möglich, spezialisierte Datenbanken zu verwenden, die ihre Daten nicht ändern können, aber gleichzeitig viel schneller speichern, akkumulieren und verteilen – Clickhouse zum Beispiel, etwas Kafka-ähnliches? … Kafka ist auch ein Protokoll! Ist es möglich, sie irgendwie zu integrieren?
AG: - Das Entladen kann durchgeführt werden. Wir haben seit Version 3.4 eine bestimmte „Funktion“: Sie können alle historischen Dateien, Ereignisse und alles andere in Dateien schreiben; und dann mit einem Handler an eine andere Datenbank senden. Tatsächlich überarbeiten viele Leute und schreiben direkt in die Datenbank. Im Handumdrehen schreiben History-Senker all dies in Dateien, rotieren diese Dateien und so weiter, und Sie können dies an Clickhouse übertragen. Zu den Plänen kann ich noch nichts sagen, aber vielleicht wird es weiterhin Unterstützung für NoSQL-Lösungen (wie Clickhouse) geben.
A: – Generell stellt sich heraus, dass man Postgres komplett loswerden kann?
AG: – Der schwierigste Teil in Zabbix sind natürlich die historischen Tabellen, die die meisten Probleme und Ereignisse verursachen. Wenn Sie in diesem Fall die Ereignisse längere Zeit nicht speichern und den Verlauf mit Trends in einem anderen schnellen Speicher speichern, wird es meiner Meinung nach im Allgemeinen keine Probleme geben.
A: – Können Sie abschätzen, wie viel schneller alles funktionieren wird, wenn Sie beispielsweise auf Clickhouse umsteigen?
AG: – Ich habe es nicht getestet. Ich denke, dass mindestens die gleichen Zahlen ganz einfach erreicht werden können, da Clickhouse über eine eigene Schnittstelle verfügt, aber ich kann es nicht mit Sicherheit sagen. Es ist besser zu testen. Es hängt alles von der Konfiguration ab: wie viele Hosts Sie haben und so weiter. Das Einfügen ist eine Sache, aber Sie müssen diese Daten auch abrufen – Grafana oder etwas anderes.
A: – Es geht also um einen gleichberechtigten Kampf und nicht um den großen Vorteil dieser schnellen Datenbanken?
AG: – Ich denke, wenn wir integrieren, wird es genauere Tests geben.
A: – Wo ist der gute alte RRD geblieben? Was hat Sie dazu bewogen, auf SQL-Datenbanken umzusteigen? Zunächst wurden alle Kennzahlen auf RRD erfasst.
AG: – Zabbix hatte RRD, vielleicht in einer sehr alten Version. SQL-Datenbanken gab es schon immer – ein klassischer Ansatz. Der klassische Ansatz ist MySQL, PostgreSQL (es gibt sie schon sehr lange). Wir haben fast nie eine gemeinsame Schnittstelle für SQL- und RRD-Datenbanken verwendet.
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