Hohe Leistung und natives Partitionieren: Zabbix mit Unterstützung für TimescaleDB

Zabbix ist ein Monitoring-System. Wie jedes andere System sieht es sich drei Hauptproblemen gegenüber, die alle Monitoring-Systeme betreffen: Datenerfassung und -verarbeitung, Historienverwaltung und deren Bereinigung.

Die Phasen der Datenerfassung, -verarbeitung und -speicherung benötigen Zeit. Etwas, aber bei einem großen System kann dies zu erheblichen Verzögerungen führen. Das Speicherproblem betrifft den Datenzugriff. Diese Daten werden für Berichte, Prüfungen und Trigger verwendet. Verzögerungen beim Datenzugriff wirken sich ebenfalls auf die Leistung aus. Wenn Datenbanken wachsen, müssen veraltete Daten gelöscht werden. Das Löschen ist ein ressourcenintensiver Vorgang.

Die Probleme bei Verzögerungen in der Datensammlung und -speicherung in Zabbix werden durch Caching gelöst: verschiedene Cache-Arten, Caching in der Datenbank. Für das dritte Problem eignet sich Caching jedoch nicht, daher wird in Zabbix TimescaleDB eingesetzt. Dazu wird unser Experten- Andrei Gushchin — technischer Support-Ingenieur Zabbix SIA. Andrei arbeitet seit über 6 Jahren im Zabbix-Support und ist direkt mit der Leistungsoptimierung konfrontiert.

Wie funktioniert TimescaleDB und welche Leistung kann es im Vergleich zu herkömmlichem PostgreSQL bieten? Welche Rolle spielt Zabbix für die TimescaleDB? Wie startet man von Grund auf und wie migriert man von PostgreSQL, und welche Konfiguration bietet die beste Leistung? All das erfahren Sie im Folgenden.

Leistungsherausforderungen

Jedes Überwachungssystem steht vor bestimmten Leistungsherausforderungen. Ich werde über drei davon sprechen: Datenerfassung und -verarbeitung, Speicherung und die Bereinigung von Verlauf.

Schnelle Datenerfassung und -verarbeitung. Ein gutes Überwachungssystem muss schnell alle Daten erfassen und sie gemäß den Trigger-Ausdrücken — nach eigenen Kriterien — verarbeiten. Nach der Verarbeitung sollte das System die Daten auch zügig in der Datenbank speichern, um sie später nutzen zu können.

Speicherung der Historie. Ein gutes Überwachungssystem sollte die Historie in der Datenbank speichern und einfachen Zugriff auf die Metriken bieten. Die Historie ist erforderlich, um sie in Berichten, Grafiken, Triggern, Schwellenwerten und berechneten Datenpunkten für Benachrichtigungen zu verwenden.

Bereinigung der Historie. Manchmal kommt der Tag, an dem Sie keine Metriken mehr speichern müssen. Wozu benötigen Sie Daten, die vor 5 Jahren gesammelt wurden, oder solche aus einem Monat oder zwei? Einige Knoten wurden entfernt, einige Hosts oder Metriken sind nicht mehr erforderlich, da sie veraltet sind und nicht mehr erfasst werden. Ein gutes Monitoringsystem sollte historische Daten speichern und diese von Zeit zu Zeit löschen, um das Datenbankwachstum zu kontrollieren.

Die Bereinigung veralteter Daten ist ein drängendes Thema, das die Datenbankleistung erheblich beeinflusst.

Caching in Zabbix

In Zabbix werden die erste und zweite Abfrage durch Caching gelöst. Zur Sammlung und Verarbeitung von Daten wird der Arbeitsspeicher genutzt. Für die Speicherung gibt es Historien in Triggern, Grafiken und berechneten Datenelementen. Auf der Datenbankseite gibt es ein bestimmtes Caching für grundlegende Abfragen, wie beispielsweise Grafiken.

Caching auf der Seite des Zabbix-Servers umfasst:

• ConfigurationCache;
• ValueCache;
• HistoryCache;
• TrendsCache.

Betrachten wir sie im Detail.

ConfigurationCache

Dies ist der Hauptcache, in dem wir Metriken, Hosts, Datenelemente und Trigger speichern – alles, was für die Vorverarbeitung und das Sammeln von Daten benötigt wird.

All dies wird im ConfigurationCache gespeichert, um überflüssige Datenbankanfragen zu vermeiden. Nach dem Start des Servers aktualisieren wir diesen Cache, erstellen und aktualisieren die Konfigurationen regelmäßig.

Daten sammeln

Das Schema ist recht umfangreich, aber das Wichtigste daran ist Sammler. Dies sind verschiedene "Poller" — Sammelprozesse. Sie sind für verschiedene Arten der Datensammlung verantwortlich: sie sammeln Daten über SNMP, IPMI und leiten alles an PreProcessing weiter.

Die Sammler sind durch eine orange Linie umrandet.

In Zabbix gibt es berechnete aggregierte Datenelemente, die benötigt werden, um Prüfungen zu aggregieren. Wenn wir diese haben, holen wir die Daten direkt aus ValueCache.

PreProcessing HistoryCache

Alle Sammler verwenden ConfigurationCache, um Aufgaben zu erhalten. Dann leiten sie diese an PreProcessing weiter.

PreProcessing nutzt ConfigurationCache, um Schritte des PreProcessings zu erhalten. Es verarbeitet diese Daten auf verschiedene Weise.

Nach der Datenverarbeitung mit PreProcessing speichern wir sie im HistoryCache, um sie zu verarbeiten. Damit endet die Datensammlung und wir gehen zum Hauptprozess in Zabbix über — history syncer, da es sich um eine monolithische Architektur handelt.

Hinweis: PreProcessing ist eine rechenintensive Operation. Ab Version 4.2 wurde sie auf den Proxy ausgelagert. Wenn Sie ein sehr großes Zabbix mit vielen Datenelementen und hoher Erfassungsfrequenz haben, erleichtert dies die Arbeit erheblich.

ValueCache, Verlauf & Trends Cache

Der History Syncer ist der Hauptprozess, der jedes Datenelement atomar verarbeitet, d.h. jeden Wert.

Der History Syncer entnimmt Werte aus dem HistoryCache und prüft in der Konfiguration, ob Trigger für Berechnungen vorhanden sind. Wenn ja, führt er die Berechnungen durch.

Der History Syncer erstellt ein Ereignis, eine Eskalation, um Benachrichtigungen zu generieren, wenn dies in der Konfiguration erforderlich ist, und zeichnet es auf. Wenn Trigger für weitere Verarbeitung vorhanden sind, speichert er diesen Wert im ValueCache, um nicht auf die Verlaufstabelle zugreifen zu müssen. So wird der ValueCache mit den benötigten Daten für die Triggerberechnungen gefüllt.

Der History Syncer zeichnet alle Daten in der Datenbank auf, die wiederum auf die Festplatte geschrieben wird. Der Verarbeitungsprozess endet hier.

Caching in der Datenbank

Auf der Seite der Datenbank gibt es verschiedene Caches, wenn Sie Grafiken oder Berichte zu Ereignissen betrachten möchten:

• Innodb_buffer_pool auf der MySQL-Seite;
• shared_buffers auf der PostgreSQL-Seite;
• effective_cache_size auf der Oracle-Seite;
• shared_pool auf der DB2-Seite.

Es gibt viele andere Caches, aber dies sind die wichtigsten für alle Datenbanken. Sie ermöglichen es, Daten, die häufig für Abfragen benötigt werden, im Arbeitsspeicher zu halten. Dafür gibt es spezielle Technologien.

Die Leistung der Datenbank ist entscheidend.

Der Zabbix-Server sammelt ständig Daten und speichert sie. Beim Neustart liest er ebenfalls aus der Historie, um den ValueCache zu füllen. Skripte und Berichte werden verwendet. Zabbix API, das auf dem Web-Interface basiert. Die Zabbix API greift auf die Datenbank zu und erhält die benötigten Daten für Diagramme, Berichte, Ereignisliste und aktuelle Probleme.

Für die Visualisierung — Grafana. Unter unseren Nutzern ist dies eine beliebte Lösung. Sie kann direkt über die Zabbix API Abfragen sowohl an die Datenbank senden und schafft eine gewisse Konkurrenz um die Datenabfrage. Daher ist eine feinere und bessere Datenbankkonfiguration erforderlich, um eine schnelle Ergebnislieferung und Tests zu gewährleisten.

Housekeeper

Der dritte Leistungsaspekt in Zabbix ist die Datenhistorienbereinigung durch Housekeeper. Er beachtet alle Einstellungen – in den Datenelementen ist angegeben, wie viele Tage die Änderungsdynamik (Trends) aufbewahrt werden soll.

TrendsCache wird in Echtzeit berechnet. Wenn Daten eintreffen, aggregieren wir sie über einen Zeitraum von einer Stunde und speichern sie in Tabellen, um die Dynamik der Trendveränderungen zu verfolgen.

Housekeeper wird gestartet und entfernt Informationen aus der Datenbank mit herkömmlichen „Selects“. Dies ist nicht immer effizient, wie man an den Diagrammen zur Leistung der internen Prozesse erkennen kann.

Das rote Diagramm zeigt, dass der History Syncer ständig beschäftigt ist. Das orange Diagramm oben zeigt den Housekeeper, der immer wieder gestartet wird. Er wartet darauf, dass die Datenbank alle Zeilen löscht, die er festgelegt hat.

Wann sollte man den Housekeeper deaktivieren? Zum Beispiel, wenn es eine „Item ID“ gibt und die letzten 5.000 Zeilen über einen bestimmten Zeitraum gelöscht werden müssen. Natürlich erfolgt dies über Indizes. Aber in der Regel ist das Dataset sehr groß, und die Datenbank liest dennoch von der Festplatte und lädt in den Cache. Das ist immer eine sehr kostspielige Operation für die Datenbank und kann, je nach Größe der DB, zu Leistungsproblemen führen.

Der Housekeeper kann einfach deaktiviert werden. Im Web-Interface gibt es eine Einstellung unter „Allgemeine Verwaltung“ für den Housekeeper. Wir deaktivieren die interne Haushaltsführung für die interne History der Trends, wodurch er nicht mehr dafür zuständig ist.

Housekeeper wurde deaktiviert, die Zeitpläne haben sich angeglichen – welche Probleme können in diesem Fall auftreten und wie kann man bei der dritten Leistungsanfrage helfen?

Partitionierung – Sektionierung oder Partionierung

In der Regel wird Partitionierung unterschiedlich in jeder relationalen Datenbank eingerichtet, die ich aufgelistet habe. Jede hat ihre eigene Technologie, aber grundsätzlich sind sie ähnlich. Das Erstellen einer neuen Partition führt oft zu bestimmten Problemen.

In der Regel wird die Partitionierung je nach 'Setup' – der Menge an Daten, die an einem Tag erstellt werden – konfiguriert. Normalerweise wird Partitionierung für einen Tag eingestellt, das ist das Minimum. Für die Trends einer neuen Partition – für 1 Monat.

Die Werte können sich bei einem sehr großen 'Setup' ändern. Wenn ein kleines 'Setup' bis zu 5.000 nvps (neue Werte pro Sekunde) beträgt, ist das mittlere von 5.000 bis 25.000, und das große über 25.000 nvps. Dies sind große und sehr große Installationen, die eine sorgfältige Datenbankkonfiguration erfordern.

Bei sehr großen Installationen kann ein Tagesabschnitt suboptimal sein. Ich habe in MySQL Partitionen gesehen, die über 40 GB und mehr pro Tag umfassen. Das ist ein enormer Datenumfang, der zu Problemen führen kann und muss reduziert werden.

Was bringt Partitionierung?

Tabellenpartitionierung. Oft handelt es sich um separate Dateien auf der Festplatte. Der Abfrageplan wählt optimierter eine Partition aus. In der Regel wird Partitionierung basierend auf einem Bereich verwendet — das gilt auch für Zabbix. Wir verwenden dort den „timestamp“ — die Zeit seit der Epoche. In unserem Fall sind das gängige Zahlen. Sie geben den Beginn und das Ende des Tages an — das ist die Partition.

Schnelles Löschen — DELETE. Es wird eine Datei/Subtabelle ausgewählt, nicht eine Zeilenabfrage zum Löschen.

Beschleunigt die Datenauswahl deutlich SELECT — es werden eine oder mehrere Partitionen verwendet, nicht die gesamte Tabelle. Wenn Sie auf Daten von vor zwei Tagen zugreifen, werden diese schneller aus der DB abgerufen, da nur eine Datei geladen und im Cache bereitgestellt wird, anstatt eine große Tabelle.

Oft beschleunigt das auch viele DBs INSERT — Einfügungen in die Child-Tabelle.

TimescaleDB

Für v 4.2 haben wir uns mit TimescaleDB beschäftigt. Dies ist ein PostgreSQL-Erweiterung mit einer nativen Schnittstelle. Die Erweiterung arbeitet effizient mit Zeitreihendaten, ohne die Vorteile von relationalen Datenbanken zu verlieren. TimescaleDB partitioniert auch automatisch.

In TimescaleDB gibt es das Konzept der Hypertabelle (hypertable), die Sie erstellen. In ihr befinden sich Chunks — Partitionen. Chunks sind automatisch verwaltete Fragmente der Hypertabelle, die nicht die anderen Fragmente beeinflussen. Jeder Chunk hat seinen eigenen Zeitbereich.

TimescaleDB vs PostgreSQL

TimescaleDB funktioniert wirklich effizient. Die Entwickler der Erweiterung behaupten, dass sie einen besseren Algorithmus zur Abwicklung von Anfragen verwenden, insbesondere für <code>Inserts</code>. Wenn die Größen der Dataset-Einfügungen wachsen, unterstützt der Algorithmus konstante Leistung.

Nach 200 Millionen Zeilen beginnt PostgreSQL normalerweise erheblich nachzulassen und verliert die Leistung auf 0. TimescaleDB ermöglicht es, Inserts bei jedem Datenvolumen effektiv einzufügen.

Installation von

Die Installation von TimescaleDB ist für alle Pakete recht einfach. In Dokumentation. wird alles ausführlich beschrieben — es hängt von den offiziellen PostgreSQL-Paketen ab. TimescaleDB kann auch manuell gebaut 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

Sie aktivieren die Erweiterung und erstellen sie für die Zabbix-Datenbank. Der letzte Schritt ist die Erstellung einer Hypertabelle.

Migration der Verlaufstabellen auf TimescaleDB

Es gibt dafür 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. Der erste ist die Tabelle in der Datenbank, für die eine Hypertabelle erstellt werden soll. Der zweite ist das Feld, nach dem die Hypertabelle erstellt werden muss. chunk_time_interval ist das Intervall der Partitionierungs-Chunks, das verwendet werden soll. In meinem Fall beträgt das Intervall einen Tag — 86.400.

Der dritte Parameter ist daten_migrieren. Wenn Sie einstellen true, werden alle aktuellen Daten in vordefinierte Chunks übertragen. Ich habe es selbst verwendet daten_migrieren. Ich hatte etwa 1 TB, das hat mehr als eine Stunde gedauert. In einigen Fällen habe ich beim Testen sogar optionale historische Daten vom Zeichentyp gelöscht, um sie nicht zu übertragen.

Der letzte Schritt — UPDATE: In db_extension stellen wir timescaledb, damit die DB dieses Erweiterung versteht. Zabbix aktiviert es und nutzt die Syntax und Abfragen korrekt — die Funktionen, die für TimescaleDB erforderlich sind.

Konfiguration der Hardware

Ich habe zwei Server verwendet. Der erste — VMware-Maschine. Sie ist ziemlich klein: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2,20 GHz, 16 GB RAM und eine 200 GB SSD.

Ich habe darauf PostgreSQL 10.8 mit Debian 10.8-1.pgdg90+1 und dem Dateisystem xfs installiert. Ich habe es minimal konfiguriert, um genau diese Datenbank zu verwenden, abgesehen davon, was Zabbix selbst verwenden wird.

Auf dieser Maschine liefen der Zabbix-Server, PostgreSQL und Lastagenten. Ich hatte 50 aktive Agenten, die LoadableModule, um sehr schnell verschiedene Ergebnisse zu generieren: Zahlen, Zeichenfolgen. Ich habe die Datenbank mit einer großen Menge Daten gefüllt.

Die ursprüngliche Konfiguration enthielt 5.000 Elemente Daten für jeden Host. Fast jedes Element hatte einen Trigger, um es realen Installationen ähnlich zu machen. In einigen Fällen gab es mehr als einen Trigger. Auf einen Knoten im Netzwerk entfielen 3.000-7.000 Trigger.

Aktualisierungsintervall der Datenelemente — 4-7 Sekunden. Ich regulierte die Last, indem ich nicht nur 50 Agenten verwendete, sondern noch weitere hinzufügte. Außerdem passte ich mit Hilfe der Datenelemente die Last dynamisch an und senkte das Aktualisierungsintervall auf 4 s.

PostgreSQL. 35.000 nvps

Der erste Start auf dieser Hardware war mit reinem PostgreSQL — 35.000 Werte pro Sekunde. Wie man sieht, dauert das Einfügen von Daten Bruchteile von Sekunden — alles funktioniert gut und schnell. Einziges Manko ist, dass die SSD mit 200 GB schnell voll wird.

Das ist das Standard-Performance-Dashboard von Zabbix — Server.

Der erste blaue Graph zeigt die Anzahl der Werte pro Sekunde. Der zweite Graph rechts zeigt die Auslastung der Sammelprozesse. Der dritte zeigt die Auslastung interner Sammelprozesse: History Syncers und Housekeeper, die hier über längere Zeiträume aktiv waren.

Das vierte Diagramm zeigt die Nutzung des HistoryCache. Dies ist ein Puffer vor der Einspeisung in die Datenbank. Das grüne fünfte Diagramm zeigt die Nutzung des ValueCache, das heißt, wie viele Zugriffe der ValueCache für die Trigger hat — das sind mehrere Tausend Werte pro Sekunde.

PostgreSQL. 50.000 nvps

Ich habe die Last auf 50.000 Werte pro Sekunde auf derselben Hardware erhöht.

Beim Laden mit dem Housekeeper wurden 10.000 Werte in 2-3 Sekunden geschrieben.

Der Housekeeper beginnt bereits, die Arbeit zu stören.

Im dritten Diagramm sieht man, dass die Auslastung der Trapper und History Syncers insgesamt noch bei 60% liegt. Im vierten Diagramm beginnt der HistoryCache während der Arbeit des Housekeepers bereits aktiv gefüllt zu werden. Er wurde zu 20% gefüllt — das sind etwa 0,5 GB.

PostgreSQL. 80.000 nvps

Ich habe die Last auf 80.000 Werte pro Sekunde erhöht. Das sind etwa 400.000 Datenelemente und 280.000 Trigger.

Die Einspeisung mit der Last von dreißig History Syncers ist bereits recht hoch.

Ich habe auch verschiedene Parameter angepasst: History Syncers, Caches.

Auf meiner Hardware stieg die Auslastung der History Syncers bis zum Maximum. Der HistoryCache füllte sich schnell mit Daten — im Puffer sammelten sich die Daten zur Verarbeitung.

Während dieser gesamten Zeit habe ich beobachtet, wie die CPU, der Arbeitsspeicher und andere Systemparameter genutzt werden, und festgestellt, dass die Auslastung der Festplatten maximal war.

Ich habe erreicht, dass die maximalen Möglichkeiten der Festplatte genutzt werden auf dieser Hardware und dieser virtuellen Maschine. Bei einer solchen Intensität begann PostgreSQL recht aktiv Daten zu verwalten, und die Festplatte konnte nicht mehr ausreichend lesen und schreiben.

Zweiter Server

Ich habe einen anderen Server genommen, der bereits 48 Prozessoren und 128 GB Arbeitsspeicher hatte. Ich habe ihn optimiert — 60 history syncer installiert und akzeptable Leistung erzielt.

Tatsächlich ist dies bereits das Leistungsmaximum, wo etwas unternommen werden muss.

TimescaleDB. 80.000 nvps

Meine Hauptaufgabe ist es, die Möglichkeiten von TimescaleDB unter der Last von Zabbix zu testen. 80.000 Werte pro Sekunde sind viel, die Frequenz der Metrik-Sammlung (außer bei Yandex, natürlich) und ein ziemlich großes „Setup“.

In jedem Diagramm gibt es einen Einbruch — das ist die Datenmigration. Nach den Einbrüchen im Zabbix-Server hat sich das Profil der Belastung des history syncer erheblich verändert — es ist um das Dreifache gefallen.

TimescaleDB ermöglicht es, Daten nahezu dreimal schneller einzufügen und weniger HistoryCache zu verwenden.

Somit werden Ihnen die Daten rechtzeitig zur Verfügung gestellt.

TimescaleDB. 120.000 nvps

Anschließend habe ich die Anzahl der Datenelemente auf 500.000 erhöht. Die Hauptaufgabe bestand darin, die Möglichkeiten von TimescaleDB zu überprüfen — ich erhielt eine berechnete Rate von 125.000 Werten pro Sekunde.

Das ist ein funktionierendes Setup, das lange betrieben werden kann. Da meine Festplatte jedoch nur 1,5 TB hatte, habe ich sie innerhalb von ein paar Tagen gefüllt.

Das Wichtigste ist, dass gleichzeitig neue Partitionen in TimescaleDB erstellt wurden.

Für die Leistung ist das völlig unauffällig. Wenn zum Beispiel in MySQL Partitionen erstellt werden, sieht das ganz anders aus. Das geschieht normalerweise nachts, da es die gesamte Einfügung blockiert, die Arbeit mit Tabellen beeinträchtigen kann und möglicherweise eine Dienstverschlechterung verursacht. Bei TimescaleDB tritt das nicht auf.

Zum Beispiel zeige ich ein Diagramm von vielen in der Community. Auf dem Bild ist TimescaleDB aktiviert, wodurch die I/O-Nutzung auf dem Prozessor gesenkt wurde. Auch die Nutzung interner Prozesselemente nahm ab. Dabei handelt es sich um eine gewöhnliche virtuelle Maschine auf normalen Festplatten, nicht SSDs.

Fazit

TimescaleDB ist eine gute Lösung für kleine Setups., die die Leistung der Festplatte betreffen. Es ermöglicht ein reibungsloses Arbeiten bis zur Migration der Datenbank auf schnellere Hardware.

TimescaleDB ist einfach einzurichten, bietet Leistungssteigerungen und arbeitet gut mit Zabbix sowie hat Vorteile gegenüber PostgreSQL..

Wenn Sie PostgreSQL verwenden und nicht planen, es zu wechseln, empfehle ich, PostgreSQL mit der TimescaleDB-Erweiterung zusammen mit Zabbix zu nutzen.Diese Lösung funktioniert effizient bis zu mittleren Setups.

Wenn wir von „hoher Leistung“ sprechen, meinen wir HighLoad++. Es ist nicht mehr lange hin, um Technologien und Praktiken kennenzulernen, die es Diensten ermöglichen, Millionen von Benutzern zu bedienen. Die Liste der Vorträge für den 7. und 8. November haben wir bereits erstellt, aber Meetups kann man immer noch vorschlagen.

Abonnieren Sie unsere Newsletter und telegram, in denen wir die Highlights der bevorstehenden Konferenz vorstellen und erläutern, wie man den größtmöglichen Nutzen daraus zieht.

Quelle: habr.com