Zabbix ist ein Überwachungssystem. Wie jedes andere System steht es vor drei Hauptproblemen aller Überwachungssysteme: Sammeln und Verarbeiten von Daten, Speichern des Verlaufs und Löschen dieser.
Die Phasen des Empfangens, Verarbeitens und Aufzeichnens von Daten nehmen Zeit in Anspruch. Nicht viel, aber bei einem großen System kann dies zu großen Verzögerungen führen. Das Speicherproblem ist eine Frage des Datenzugriffs. Sie werden für Berichte, Prüfungen und Auslöser verwendet. Verzögerungen beim Datenzugriff wirken sich auch auf die Leistung aus. Wenn die Datenbank wächst, müssen irrelevante Daten gelöscht werden. Das Löschen ist ein aufwändiger Vorgang, der auch einige Ressourcen verbraucht.
Probleme bei der Erfassung und Speicherverzögerung in Zabbix werden durch Caching gelöst: verschiedene Arten von Caches, Caching in der Datenbank. Um das dritte Problem zu lösen, ist Caching nicht geeignet, daher wurde in Zabbix TimescaleDB verwendet. Werde davon erzählen Andrej Guschtschin - Technischer Support-Ingenieur . Andrey unterstützt Zabbix seit über 6 Jahren und ist direkt an der Performance beteiligt.
Wie funktioniert TimescaleDB, welche Leistung kann es im Vergleich zu normalem PostgreSQL bieten? Welche Rolle spielt Zabbix in TimescaleDB? Wie fange ich bei Null an, wie migriere ich von PostgreSQL und welche Konfigurationsleistung ist besser? Das alles unter dem Strich.
Leistungsherausforderungen
Jedes Überwachungssystem steht vor bestimmten Leistungsherausforderungen. Ich werde über drei davon sprechen: Datenerfassung und -verarbeitung, Speicherung, Verlaufsbereinigung.
Schnelle Datenerfassung und -verarbeitung. Ein gutes Überwachungssystem sollte alle Daten schnell empfangen und nach Triggerausdrücken verarbeiten – nach seinen eigenen Kriterien. Nach der Verarbeitung muss das System diese Daten auch schnell in der Datenbank speichern, um sie später verwenden zu können.
Verlaufsspeicher. Ein gutes Überwachungssystem sollte den Verlauf in einer Datenbank speichern und einen einfachen Zugriff auf Metriken ermöglichen. Der Verlauf wird benötigt, um in Berichten, Diagrammen, Auslösern, Schwellenwerten und berechneten Alarmelementen verwendet zu werden.
Verlauf löschen. Manchmal kommt der Tag, an dem Sie keine Messwerte mehr speichern müssen. Warum benötigen Sie Daten, die vor 5 Jahren, ein oder zwei Monaten gesammelt wurden: Einige Knoten wurden entfernt, einige Hosts oder Metriken werden nicht mehr benötigt, weil sie veraltet sind und nicht mehr erfasst werden. Ein gutes Überwachungssystem sollte historische Daten speichern und von Zeit zu Zeit löschen, damit die Datenbank nicht wächst.
Das Bereinigen veralteter Daten ist ein heikles Thema, das große Auswirkungen auf die Datenbankleistung hat.
Caching in Zabbix
In Zabbix werden der erste und der zweite Aufruf mithilfe von Caching aufgelöst. RAM wird zum Sammeln und Verarbeiten von Daten verwendet. Zur Speicherung – Verlauf in Triggern, Diagrammen und berechneten Elementen. Auf der DB-Seite gibt es etwas Caching für grundlegende Auswahlmöglichkeiten, wie zum Beispiel Diagramme.
Das Caching auf der Seite des Zabbix-Servers selbst ist:
- Konfigurationscache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Lassen Sie uns sie genauer betrachten.
Konfigurationscache
Dies ist der Hauptcache, in dem wir Metriken, Hosts, Datenelemente, Trigger speichern – alles, was für die Vorverarbeitung und Datenerfassung benötigt wird.
All dies wird im ConfigurationCache gespeichert, um keine unnötigen Abfragen in der Datenbank zu erzeugen. Nach dem Serverstart aktualisieren wir diesen Cache, erstellen und aktualisieren regelmäßig Konfigurationen.
Datensammlung
Das Schema ist ziemlich groß, aber das Wichtigste darin ist Sammler. Dabei handelt es sich um verschiedene „Poller“ – Montageprozesse. Sie sind für verschiedene Montagearten verantwortlich: Sie sammeln Daten über SNMP, IPMI und übertragen sie an PreProcessing.
Pflücker sind orange eingekreist.
Zabbix hat Aggregationselemente berechnet, die zum Aggregieren von Schecks erforderlich sind. Wenn wir welche haben, beziehen wir die Daten dafür direkt aus dem ValueCache.
Vorverarbeitungs-HistoryCache
Alle Collectors verwenden den ConfigurationCache, um Jobs zu empfangen. Anschließend geben sie diese an das PreProcessing weiter.
PreProcessing verwendet ConfigurationCache, um PreProcessing-Schritte abzurufen. Es verarbeitet diese Daten auf verschiedene Weise.
Nachdem wir die Daten mit PreProcessing verarbeitet haben, speichern wir sie im HistoryCache, um sie zu verarbeiten. Damit ist die Datenerfassung abgeschlossen und wir fahren mit dem Hauptprozess in Zabbix fort – Verlaufssynchronisierung, da es sich um eine monolithische Architektur handelt.
Hinweis: Die Vorverarbeitung ist ein ziemlich aufwändiger Vorgang. Seit Version 4.2 wurde es auf einen Proxy verschoben. Wenn Sie einen sehr großen Zabbix mit einer großen Anzahl an Artikeln und einer hohen Abholhäufigkeit haben, erleichtert dies die Sache erheblich.
ValueCache, Verlaufs- und Trend-Cache
Der History Syncer ist der Hauptprozess, der jedes Datenelement, also jeden Wert, atomar verarbeitet.
Der History-Syncer übernimmt Werte aus dem HistoryCache und überprüft die Konfiguration auf Auslöser für Berechnungen. Wenn ja, wird berechnet.
Der Verlaufssynchronisierer erstellt ein Ereignis, eskaliert es, um Warnungen zu erstellen, wenn die Konfiguration dies erfordert, und zeichnet es auf. Wenn Auslöser für die weitere Verarbeitung vorhanden sind, merkt es sich diesen Wert im ValueCache, um nicht auf die Verlaufstabelle zu verweisen. Auf diese Weise wird der ValueCache mit den Daten gefüllt, die zur Berechnung von Triggern, berechneten Elementen, benötigt werden.
Der History Syncer schreibt alle Daten in die Datenbank und auf die Festplatte. Der Bearbeitungsprozess endet hier.
DB-Caching
Wenn Sie sich Diagramme oder Ereignisberichte ansehen möchten, gibt es auf der DB-Seite verschiedene Caches:
Innodb_buffer_poolauf der MySQL-Seite;shared_buffersauf der PostgreSQL-Seite;effective_cache_sizeauf der Oracle-Seite;shared_poolauf der DB2-Seite.
Es gibt viele andere Caches, aber diese sind die wichtigsten für alle Datenbanken. Sie ermöglichen es Ihnen, Daten im RAM zu behalten, die häufig für Abfragen benötigt werden. Sie haben dafür ihre eigene Technologie.
Die Datenbankleistung ist entscheidend
Der Zabbix-Server sammelt ständig Daten und schreibt sie auf. Beim Neustart liest es auch aus dem Verlauf, um den ValueCache zu füllen. Verwendung von Skripten und Berichten Zabbix-API, das auf Basis der Weboberfläche aufgebaut ist. Die Zabbix-API greift auf die Datenbank zu und ruft die erforderlichen Daten für Diagramme, Berichte, Ereignislisten und aktuelle Probleme ab.
Zur Visualisierung - Grafana. Dies ist eine beliebte Lösung bei unseren Benutzern. Sie kann Anfragen direkt über die Zabbix-API und an die Datenbank senden und schafft eine gewisse Parallelität zum Abrufen von Daten. Daher ist eine feinere und bessere Datenbankabstimmung erforderlich, um die schnelle Bereitstellung von Ergebnissen und Tests zu ermöglichen.
Housekeeper
Die dritte Leistungsherausforderung in Zabbix ist die Reinigungsgeschichte mit Housekeeper. Es berücksichtigt alle Einstellungen – die Datenelemente geben an, wie lange die Dynamik von Änderungen (Trends) in Tagen gespeichert werden soll.
TrendsCache berechnen wir im laufenden Betrieb. Wenn die Daten eingehen, aggregieren wir sie in einer Stunde und stellen sie in Tabellen für die Dynamik von Trendänderungen zusammen.
Housekeeper startet und entfernt Informationen aus der Datenbank mit den üblichen „Auswahlvorgängen“. Dies ist nicht immer effizient, was aus den Leistungsdiagrammen interner Prozesse ersichtlich ist.
Die rote Grafik zeigt, dass der History-Syncer ständig ausgelastet ist. Das orangefarbene Diagramm oben ist „Housekeeper“, das ständig läuft. Es wartet darauf, dass die Datenbank alle angegebenen Zeilen löscht.
Wann sollten Sie Housekeeper deaktivieren? Beispielsweise gibt es eine „Artikel-ID“ und Sie müssen die letzten 5 Zeilen in einer bestimmten Zeit löschen. Dies geschieht natürlich durch Indizes. Normalerweise ist der Datensatz jedoch sehr groß und die Datenbank liest immer noch von der Festplatte und legt sie im Cache ab. Dies ist für die Datenbank immer ein sehr kostspieliger Vorgang und kann je nach Größe der Datenbank zu Performance-Problemen führen.
Housekeeper ist einfach zu deaktivieren. Im Webinterface gibt es unter „Administration Allgemein“ eine Einstellung für Housekeeper. Wenn Sie die interne Verwaltung für den internen Trendverlauf deaktivieren, wird dieser nicht mehr gesteuert.
Housekeeper wurde deaktiviert, die Grafik hat sich eingependelt – was könnten in diesem Fall die Probleme sein und was kann bei der Lösung der dritten Leistungsherausforderung helfen?
Partitionierung – Partitionierung oder Partitionierung
Die Partitionierung wird normalerweise in jeder von mir aufgelisteten relationalen Datenbank unterschiedlich konfiguriert. Jedes hat seine eigene Technologie, aber im Allgemeinen sind sie ähnlich. Das Erstellen einer neuen Partition führt häufig zu bestimmten Problemen.
Typischerweise werden Partitionen abhängig vom „Setup“ konfiguriert – der Datenmenge, die an einem Tag erstellt wird. In der Regel wird die Partitionierung an einem Tag eingerichtet, dies ist das Minimum. Für neue Partitionstrends – 1 Monat.
Bei einem sehr großen „Setup“ können sich die Werte ändern. Wenn ein kleines „Setup“ bis zu 5 nvps (neue Werte pro Sekunde) beträgt, liegt ein durchschnittliches zwischen 000 und 5, dann liegt ein großes über 000 nvps. Dabei handelt es sich um große und sehr große Installationen, die eine sorgfältige Konfiguration der Datenbank selbst erfordern.
Bei sehr großen Installationen ist ein Tag möglicherweise nicht optimal. Ich habe MySQL-Partitionen von 40 GB oder mehr pro Tag gesehen. Dabei handelt es sich um eine sehr große Datenmenge, die zu Problemen führen kann und reduziert werden sollte.
Was gibt Partitionierung?
Partitionierungstabellen. Oft handelt es sich dabei um separate Dateien auf der Festplatte. Der Abfrageplan wählt eine Partition optimaler aus. Normalerweise wird die Partitionierung nach Bereich verwendet – dies gilt auch für Zabbix. Wir verwenden dort „Zeitstempel“ – die Zeit seit Beginn der Epoche. Wir haben regelmäßige Nummern. Sie legen den Anfang und das Ende des Tages fest – dies ist eine Partition.
Schnelle Entfernung - DELETE. Es wird eine Datei/Untertabelle ausgewählt, nicht eine Auswahl von Zeilen zum Löschen.
Beschleunigt die Datenerfassung erheblich SELECT – Verwendet eine oder mehrere Partitionen, nicht die gesamte Tabelle. Wenn Sie auf zwei Tage alte Daten zugreifen, werden diese schneller aus der Datenbank abgerufen, da Sie sie nur in den Cache laden müssen und nur eine Datei und keine große Tabelle zurückgeben.
Oft werden auch viele Datenbanken schneller INSERT - fügt in die untergeordnete Tabelle ein.
ZeitskalaDB
Für Version 4.2 haben wir unsere Aufmerksamkeit auf TimescaleDB gerichtet. Dies ist eine PostgreSQL-Erweiterung mit einer nativen Schnittstelle. Die Erweiterung arbeitet effizient mit Zeitreihendaten, ohne die Vorteile relationaler Datenbanken zu verlieren. TimescaleDB partitioniert auch automatisch.
TimescaleDB hat ein Konzept hypertisch (Hypertabelle), die Sie erstellen. Darin sind Brocken - Partitionen. Chunks sind automatisch verwaltete Fragmente einer Hypertabelle, die keine Auswirkungen auf andere Fragmente haben. Jeder Block hat seinen eigenen Zeitbereich.
TimescaleDB vs. PostgreSQL
TimescaleDB ist wirklich effizient. Die Hersteller der Erweiterung behaupten, dass sie einen korrekteren Abfrageverarbeitungsalgorithmus verwenden, insbesondere inserts . Mit zunehmender Größe der Datensatzeinfügung behält der Algorithmus eine konstante Leistung bei.
Nach 200 Millionen Zeilen beginnt PostgreSQL normalerweise stark einzubrechen und die Leistung auf 0 zu verlieren. Mit TimescaleDB können Sie „Einfügungen“ mit jeder Datenmenge effizient einfügen.
Einstellung
Die Installation von TimescaleDB ist für alle Pakete einfach genug. IN Alles ist detailliert - es hängt von den offiziellen PostgreSQL-Paketen ab. TimescaleDB kann auch manuell erstellt und kompiliert werden.
Für die Zabbix-Datenbank aktivieren wir einfach die Erweiterung:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
Du aktivierst extension und erstellen Sie es für die Zabbix-Datenbank. Der letzte Schritt besteht darin, eine Hypertabelle zu erstellen.
Verlaufstabellen nach TimescaleDB migrieren
Dafür gibt es eine spezielle Funktion. create_hypertable:
SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1
Die Funktion hat drei Parameter. Erste - Tabelle in der DatenbankDie, für die Sie eine Hypertabelle erstellen möchten. Zweite - Bereich, nach dem es notwendig ist zu erstellen chunk_time_interval — Intervall der zu verwendenden Partitionsblöcke. In meinem Fall beträgt das Intervall einen Tag – 86.
Der dritte Parameter ist migrate_data. Wenn festgelegt true, dann werden alle aktuellen Daten in vorab erstellte Chunks übertragen. Ich selbst habe es verwendet migrate_data. Ich hatte ungefähr 1 TB, was über eine Stunde dauerte. In einigen Fällen habe ich beim Testen sogar die historischen Daten von Charaktertypen gelöscht, die optional für die Speicherung sind, um sie nicht zu übertragen.
Letzter Schritt - UPDATE: in db_extension setzen timescaledbdamit die Datenbank versteht, dass es diese Erweiterung gibt. Zabbix aktiviert es und verwendet die Syntax und Abfragen bereits korrekt an die Datenbank – also die Funktionen, die für TimescaleDB erforderlich sind.
Hardwarekonfiguration
Ich habe zwei Server verwendet. Erste - VMware-Maschine. Es ist klein genug: 20 Intel® Xeon® CPU E5-2630 v 4 bei 2.20 GHz, 16 GB RAM und ein 200 GB SSD-Laufwerk.
Ich habe darauf PostgreSQL 10.8 mit Debian OS 10.8-1.pgdg90+1 und dem xfs-Dateisystem installiert. Ich habe alles minimal konfiguriert, um diese spezielle Datenbank zu verwenden, abzüglich dessen, was Zabbix selbst verwenden wird.
Auf derselben Maschine befanden sich ein Zabbix-Server, PostgreSQL und Ladeagenten. Ich hatte 50 Wirkstoffe, die es verwendeten LoadableModuleum sehr schnell verschiedene Ergebnisse zu generieren: Zahlen, Zeichenfolgen. Ich habe die Datenbank mit vielen Daten gefüllt.
Ursprünglich enthielt die Konfiguration 5 Elemente Daten pro Host. Fast jedes Element enthielt einen Auslöser, um es wie echte Installationen aussehen zu lassen. In einigen Fällen gab es mehr als einen Auslöser. Ein Netzwerkknoten hatte 3–000 Auslöser.
Elementaktualisierungsintervall − 4-7 Sekunden. Ich habe die Belastung selbst reguliert, indem ich nicht nur 50 Wirkstoffe eingesetzt, sondern noch mehr hinzugefügt habe. Außerdem habe ich mithilfe von Datenelementen die Last dynamisch reguliert und das Aktualisierungsintervall auf 4 s reduziert.
PostgreSQL. 35 NVPs
Mein erster Lauf auf dieser Hardware war reines PostgreSQL – 35 Werte pro Sekunde. Wie Sie sehen, dauert das Einfügen von Daten Sekundenbruchteile – alles funktioniert einwandfrei und schnell. Das Einzige ist, dass das 200-GB-SSD-Laufwerk schnell voll ist.
Dies ist ein standardmäßiges Zabbix-Serverleistungs-Dashboard.
Das erste blaue Diagramm zeigt die Anzahl der Werte pro Sekunde. Das zweite Diagramm auf der rechten Seite zeigt das Laden von Build-Prozessen. Der dritte ist das Laden interner Build-Prozesse: History Syncers und Housekeeper, der hier schon seit geraumer Zeit läuft.
Die vierte Grafik zeigt die Verwendung von HistoryCache. Dies ist eine Art Puffer vor dem Einfügen in die Datenbank. Das grüne fünfte Diagramm zeigt die Nutzung von ValueCache, d. h. wie viele ValueCache-Treffer für Trigger mehrere tausend Werte pro Sekunde betragen.
PostgreSQL. 50 NVPs
Dann habe ich die Last auf derselben Hardware auf 50 Werte pro Sekunde erhöht.
Beim Laden aus Housekeeper dauerte das Einfügen von 10 Werten 2-3 Sekunden.
Die Haushälterin fängt bereits an, in die Quere zu kommen.
Die dritte Grafik zeigt, dass die Auslastung von Trappern und History-Syncern im Allgemeinen immer noch bei 60 % liegt. Im vierten Diagramm beginnt sich der HistoryCache während des Betriebs von Housekeeper bereits recht aktiv zu füllen. Es ist zu 20 % voll – etwa 0,5 GB.
PostgreSQL. 80 NVPs
Dann habe ich die Last auf 80 Werte pro Sekunde erhöht. Das sind etwa 400 Datenelemente und 280 Trigger.
Der Ladeaufwand von dreißig History-Syncern ist schon recht hoch.
Ich habe auch verschiedene Parameter erhöht: History-Syncer, Caches.
Auf meiner Hardware ist das Laden der History-Syncer auf das Maximum angestiegen. Der HistoryCache füllte sich schnell mit Daten – der Puffer hat Daten zur Verarbeitung angesammelt.
Die ganze Zeit über habe ich beobachtet, wie Prozessor, RAM und andere Systemparameter genutzt wurden, und festgestellt, dass die Festplattenauslastung maximal war.
Ich habe davon Gebrauch gemacht maximale Festplattenkapazität auf dieser Hardware und auf dieser virtuellen Maschine. Mit dieser Intensität begann PostgreSQL, Daten ziemlich aktiv zu sichern, und die Festplatte hatte keine Zeit mehr zum Schreiben und Lesen.
Zweiter Server
Ich habe einen anderen Server genommen, der bereits über 48 Prozessoren und 128 GB RAM verfügte. Ich habe es optimiert – den History-Syncer auf 60 eingestellt und eine akzeptable Leistung erzielt.
Tatsächlich ist dies bereits eine Leistungsgrenze, an der etwas getan werden muss.
timescaledb. 80 NVPs
Meine Hauptaufgabe besteht darin, die Fähigkeiten von TimescaleDB anhand einer Zabbix-Last zu testen. 80 Werte pro Sekunde sind eine Menge, die Häufigkeit der Erfassung von Metriken (außer natürlich bei Yandex) und ein ziemlich großes „Setup“.
In jedem Diagramm gibt es einen Rückgang – das ist nur eine Datenmigration. Nach den Ausfällen im Zabbix-Server hat sich das Ladeprofil des History-Syncers stark verändert – es fiel dreimal aus.
Mit TimescaleDB können Sie Daten fast dreimal schneller einfügen und weniger HistoryCache verbrauchen.
Dementsprechend erhalten Sie die Daten zeitnah.
timescaledb. 120 NVPs
Dann habe ich die Anzahl der Datenelemente auf 500 erhöht. Die Hauptaufgabe bestand darin, die Fähigkeiten von TimescaleDB zu überprüfen – ich habe einen berechneten Wert von 125 Werten pro Sekunde erhalten.
Dies ist ein funktionierendes „Setup“, dessen Funktionsfähigkeit lange dauern kann. Aber da meine Festplatte nur 1,5 TB groß war, habe ich sie in ein paar Tagen aufgefüllt.
Am wichtigsten ist, dass gleichzeitig neue TimescaleDB-Partitionen erstellt wurden.
Für die Leistung ist dies völlig unbemerkt. Anders sieht es beispielsweise bei der Erstellung von Partitionen in MySQL aus. Dies geschieht normalerweise nachts, da es allgemeine Einfügungen und Tabellenmanipulationen blockiert und zu einer Beeinträchtigung des Dienstes führen kann. Dies ist bei TimescaleDB nicht der Fall.
Ich werde zum Beispiel ein Diagramm aus dem Set in der Community zeigen. Im Bild ist TimescaleDB aktiviert, wodurch die Belastung des Prozessors durch die Verwendung von io.weight gesunken ist. Auch der Einsatz von Elementen interner Prozesse ist zurückgegangen. Darüber hinaus handelt es sich um eine gewöhnliche virtuelle Maschine auf gewöhnlichen Pancake-Festplatten und nicht um eine SSD.
Befund
TimescaleDB ist eine gute Lösung für kleine „Setups“, die von der Leistung der Festplatte abhängen. Dadurch können Sie problemlos weiterarbeiten, bis die Datenbank schneller auf die Hardware migriert wird.
TimescaleDB ist einfach einzurichten, steigert die Leistung, funktioniert gut mit Zabbix und hat Vorteile gegenüber PostgreSQL.
Wenn Sie PostgreSQL verwenden und nicht vorhaben, es zu ändern, empfehle ich es Verwenden Sie PostgreSQL mit der TimescaleDB-Erweiterung in Verbindung mit Zabbix. Diese Lösung funktioniert effektiv bis zu einem mittleren „Setup“.
Wir sagen „Hochleistung“ – wir meinen . Es wird nicht lange dauern, bis Sie die Technologien und Praktiken kennenlernen, die es den Diensten ermöglichen, Millionen von Benutzern zu bedienen. Aufführen für den 7. und 8. November haben wir bereits ausgearbeitet, aber Weiteres kann vorgeschlagen werden.
Abonnieren Sie unsere и , in dem wir die Besonderheiten der bevorstehenden Konferenz enthüllen und herausfinden, wie Sie das Beste daraus machen können.
Source: habr.com