{"id":55734,"date":"2020-01-27T00:00:00","date_gmt":"2020-01-26T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie"},"modified":"2020-02-18T14:03:52","modified_gmt":"2020-02-18T11:03:52","slug":"highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","title":{"rendered":"HighLoad++, Andrey Gushchin (Zabbix): hohe Leistung und natives Partitionieren.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Wir werden die Funktionsweise von Zabbix mit der TimescaleDB-Datenbank als Backend untersuchen. Wir zeigen, wie man von Grund auf startet und wie man von PostgreSQL migriert. Auch werden wir Vergleichstests der Leistung beider Konfigurationen durchf\u00fchren.<\/p>\n

\"HighLoad++,
\n
\nHighLoad++ Sibirien 2019. Saal \u201eTomsk\u201c. 24. Juni, 16:00. Thesen und Pr\u00e4sentation n\u00fctzlich sein.<\/a><\/noindex>. Die n\u00e4chste Konferenz von HighLoad++ findet am 6. und 7. April 2020 in Sankt Petersburg statt. Details und Tickets \u00fcber den Link<\/a><\/noindex>.<\/p>\n

Andrej Guschin (im Folgenden \u2013 AG):<\/b> \u2013 Ich bin Ingenieur im technischen Support von ZABBIX (im Folgenden \u2013 \u201eZabbix\u201c), Trainer. Ich arbeite seit \u00fcber 6 Jahren im technischen Support und habe direkt mit Leistungsfragen zu tun. Heute werde ich \u00fcber die Leistung sprechen, die TimescaleDB im Vergleich zu herk\u00f6mmlichem PostgreSQL 10 bieten kann. Auch ein gewisser Einf\u00fchrungsteil \u2013 wie alles funktioniert.<\/a><\/noindex><\/p>\n

Die Hauptleistungsherausforderungen: von der Datensammlung bis zur Datenbereinigung<\/h3>\n

\nLassen Sie uns damit beginnen, dass es bestimmte Leistungsherausforderungen gibt, mit denen jedes \u00dcberwachungssystem konfrontiert ist. Die erste Leistungsherausforderung besteht darin, Daten schnell zu sammeln und zu verarbeiten.<\/p>\n

\"HighLoad++,
\n
\nEin effektives \u00dcberwachungssystem muss schnell und zeitgerecht alle Daten empfangen, sie gem\u00e4\u00df Trigger-Ausdr\u00fccken verarbeiten, das hei\u00dft, sie nach bestimmten Kriterien (die in verschiedenen Systemen unterschiedlich sein k\u00f6nnen) bearbeiten und in einer Datenbank speichern, um die Daten sp\u00e4ter nutzen zu k\u00f6nnen.<\/p>\n

\"HighLoad++,
\n
\nDie zweite Herausforderung f\u00fcr die Leistung ist die Speicherung der Historie. In einer Datenbank Daten zu speichern und schnellen sowie bequemen Zugriff auf diese Metriken zu haben, die \u00fcber einen bestimmten Zeitraum gesammelt wurden, ist von gro\u00dfer Bedeutung. Wichtig ist, dass man diese Daten leicht abrufen kann, um sie in Berichten, Grafiken, Triggern oder bei bestimmten Schwellenwerten f\u00fcr Benachrichtigungen usw. zu verwenden.<\/p>\n

\"HighLoad++,
\n
\nDie dritte Herausforderung f\u00fcr die Leistung besteht darin, die Historie zu bereinigen, d.h. an einem bestimmten Tag m\u00fcssen Sie keine detaillierten Metriken mehr speichern, die \u00fcber 5 Jahre gesammelt wurden (sogar \u00fcber Monate oder zwei Monate). Einige Netzwerk-Knoten wurden entfernt, oder einige Hosts sind nicht mehr erforderlich, da die Metriken veraltet sind und nicht mehr gesammelt werden. All dies muss gel\u00f6scht werden, um zu verhindern, dass Ihre Datenbank unkontrolliert w\u00e4chst. Die Bereinigung der Historie ist zudem oft eine ernsthafte Herausforderung f\u00fcr den Speicher \u2013 sie hat h\u00e4ufig einen erheblichen Einfluss auf die Leistung.<\/p>\n

Wie k\u00f6nnen Cache-Probleme gel\u00f6st werden?<\/h3>\n

\nIch werde jetzt konkret \u00fcber Zabbix sprechen. In Zabbix werden die ersten beiden Herausforderungen durch Caching gel\u00f6st.<\/p>\n

\"HighLoad++,
\n
\nDatensammlung und -verarbeitung \u2013 wir verwenden den Arbeitsspeicher, um all diese Daten zu speichern. Im Folgenden wird n\u00e4her auf diese Daten eingegangen.<\/p>\n

Au\u00dferdem gibt es auf der Datenbankseite ein gewisses Caching f\u00fcr Hauptabfragen \u2013 f\u00fcr Grafiken und andere Dinge.<\/p>\n

Caching auf der Seite des Zabbix-Servers: Wir haben ConfigurationCache, ValueCache, HistoryCache und TrendsCache. Was ist das?<\/p>\n

\"HighLoad++,
\n
\nConfigurationCache ist der zentrale Cache, in dem wir Metriken, Hosts, Datenelemente und Trigger speichern; alles, was f\u00fcr die Verarbeitung von Preprocessing, Datensammlung, welche Hosts abgerufen werden sollen und mit welcher Frequenz erforderlich ist. All dies wird im ConfigurationCache gespeichert, um nicht die Datenbank zu belasten und unn\u00f6tige Anfragen zu erstellen. Nach dem Start des Servers aktualisieren wir diesen Cache (erstellen ihn) und aktualisieren ihn regelm\u00e4\u00dfig (je nach den Konfigurationseinstellungen).<\/p>\n

\"HighLoad++,
\n<\/p>\n

Caching in Zabbix. Datensammlung<\/h3>\n

\nHier ist das Schema ziemlich gro\u00df:<\/p>\n

\"HighLoad++,
\n
\nDie Hauptakteure im Schema sind diese Sammler:<\/p>\n

\"HighLoad++,
\n
\nDas sind die eigentlichen Sammelprozesse, verschiedene \u201ePoller\u201c, die f\u00fcr unterschiedliche Arten von Abfragen zust\u00e4ndig sind. Sie sammeln Daten \u00fcber ICMP, IPMI, verschiedene Protokolle und leiten all dies an das Preprocessing weiter.<\/p>\n

PreProcessing HistoryCache<\/h3>\n

\nAu\u00dferdem, wenn wir berechnete Datenelemente haben (wer mit \u201eZabbix\u201c vertraut ist, wei\u00df das), also berechnete, aggregierte Datenelemente, \u2013 holen wir diese direkt aus dem ValueCache. Wie dieser gef\u00fcllt wird, werde ich sp\u00e4ter besprechen. Alle diese Sammler nutzen den ConfigurationCache, um ihre Aufgaben abzurufen und leiten diese dann zum Preprocessing weiter.<\/p>\n

\"HighLoad++,
\n
\nDie Vorverarbeitung nutzt ebenfalls den ConfigurationCache, um Vorverarbeitungsschritte zu erhalten und verarbeitet diese Daten auf verschiedene Weise. Seit Version 4.2 haben wir das auf einen Proxy ausge lagert. Das ist sehr praktisch, denn die eigentliche Vorverarbeitung ist ein recht ressourcenintensiver Vorgang. Wenn Sie also ein sehr gro\u00dfes \"Zabbix\" mit einer gro\u00dfen Anzahl von Datenelementen und einer hohen Erfassungsfrequenz haben, erleichtert das die Arbeit erheblich.<\/p>\n

Nachdem wir diese Daten also irgendwie mit Hilfe der Vorverarbeitung verarbeitet haben, speichern wir sie im HistoryCache, um sie sp\u00e4ter weiter zu verarbeiten. Damit endet die Datenerfassung. Wir gehen zum Hauptprozess \u00fcber.<\/p>\n

Arbeit des History Syncers<\/h3>\n

\n\"HighLoad++,
\n
\nDer zentrale Prozess in \"Zabbix\" (da es eine monolithische Architektur ist) ist der History Syncer. Dies ist der Hauptprozess, der sich mit der atomaren Verarbeitung jedes Datenelements besch\u00e4ftigt, also mit jedem Wert:<\/p>\n