{"id":38927,"date":"2019-10-31T22:26:48","date_gmt":"2019-10-31T19:26:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb\/"},"modified":"2019-10-31T22:26:48","modified_gmt":"2019-10-31T19:26:48","slug":"vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","title":{"rendered":"Hohe Leistung und natives Partitionieren: Zabbix mit Unterst\u00fctzung f\u00fcr TimescaleDB","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Zabbix ist ein Monitoring-System. Wie jedes andere System sieht es sich drei Hauptproblemen gegen\u00fcber, die alle Monitoring-Systeme betreffen: Datenerfassung und -verarbeitung, Historienverwaltung und deren Bereinigung.<\/p>\n<p>Die Phasen der Datenerfassung, -verarbeitung und -speicherung ben\u00f6tigen Zeit. Etwas, aber bei einem gro\u00dfen System kann dies zu erheblichen Verz\u00f6gerungen f\u00fchren. Das Speicherproblem betrifft den Datenzugriff. Diese Daten werden f\u00fcr Berichte, Pr\u00fcfungen und Trigger verwendet. Verz\u00f6gerungen beim Datenzugriff wirken sich ebenfalls auf die Leistung aus. Wenn Datenbanken wachsen, m\u00fcssen veraltete Daten gel\u00f6scht werden. Das L\u00f6schen ist ein ressourcenintensiver Vorgang.<\/p>\n<p><img decoding=\"async\" alt=\"Hohe Leistung und natives Partitionieren: Zabbix mit Unterst\u00fctzung f\u00fcr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/9b7aa23705cd32b4d8d858ad78b181fd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDie Probleme bei Verz\u00f6gerungen in der Datensammlung und -speicherung in Zabbix werden durch Caching gel\u00f6st: verschiedene Cache-Arten, Caching in der Datenbank. F\u00fcr das dritte Problem eignet sich Caching jedoch nicht, daher wird in Zabbix TimescaleDB eingesetzt. Dazu wird unser Experten- <strong>Andrei Gushchin<\/strong> \u2014 technischer Support-Ingenieur <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/zabbix\/\">Zabbix SIA<\/a><\/noindex>. Andrei arbeitet seit \u00fcber 6 Jahren im Zabbix-Support und ist direkt mit der Leistungsoptimierung konfrontiert.<\/p>\n<p>Wie funktioniert TimescaleDB und welche Leistung kann es im Vergleich zu herk\u00f6mmlichem PostgreSQL bieten? Welche Rolle spielt Zabbix f\u00fcr 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.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\n<center><div class=\"youtube-placeholder\" data-id=\"umRk94j5M8o\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/umRk94j5M8o\/hqdefault.jpg\" alt=\"Video abspielen\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><\/p>\n<h2>Leistungsherausforderungen<\/h2>\n<p>\nJedes \u00dcberwachungssystem steht vor bestimmten Leistungsherausforderungen. Ich werde \u00fcber drei davon sprechen: Datenerfassung und -verarbeitung, Speicherung und die Bereinigung von Verlauf.<\/p>\n<p><strong>Schnelle Datenerfassung und -verarbeitung. <\/strong>Ein gutes \u00dcberwachungssystem muss schnell alle Daten erfassen und sie gem\u00e4\u00df den Trigger-Ausdr\u00fccken \u2014 nach eigenen Kriterien \u2014 verarbeiten. Nach der Verarbeitung sollte das System die Daten auch z\u00fcgig in der Datenbank speichern, um sie sp\u00e4ter nutzen zu k\u00f6nnen.<\/p>\n<p><strong>Speicherung der Historie. <\/strong>Ein gutes \u00dcberwachungssystem 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\u00fcr Benachrichtigungen zu verwenden.<\/p>\n<p><strong>Bereinigung der Historie. <\/strong>Manchmal kommt der Tag, an dem Sie keine Metriken mehr speichern m\u00fcssen. Wozu ben\u00f6tigen 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\u00f6schen, um das Datenbankwachstum zu kontrollieren.<\/p>\n<blockquote><p>Die Bereinigung veralteter Daten ist ein dr\u00e4ngendes Thema, das die Datenbankleistung erheblich beeinflusst.<\/p><\/blockquote>\n<p><\/p>\n<h2>Caching in Zabbix<\/h2>\n<p>\nIn Zabbix werden die erste und zweite Abfrage durch Caching gel\u00f6st. Zur Sammlung und Verarbeitung von Daten wird der Arbeitsspeicher genutzt. F\u00fcr die Speicherung gibt es Historien in Triggern, Grafiken und berechneten Datenelementen. Auf der Datenbankseite gibt es ein bestimmtes Caching f\u00fcr grundlegende Abfragen, wie beispielsweise Grafiken.<\/p>\n<p>Caching auf der Seite des Zabbix-Servers umfasst:<\/p>\n<ul>\n<li>ConfigurationCache;<\/li>\n<li>ValueCache;<\/li>\n<li>HistoryCache;<\/li>\n<li>TrendsCache.<\/li>\n<\/ul>\n<p>\nBetrachten wir sie im Detail.<\/p>\n<h3>ConfigurationCache<\/h3>\n<p>\nDies ist der Hauptcache, in dem wir Metriken, Hosts, Datenelemente und Trigger speichern \u2013 alles, was f\u00fcr die Vorverarbeitung und das Sammeln von Daten ben\u00f6tigt wird.<\/p>\n<p><img decoding=\"async\" alt=\"Hohe Leistung und natives Partitionieren: Zabbix mit Unterst\u00fctzung f\u00fcr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/122708198f6cd136fbd0420876c06e9c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAll dies wird im ConfigurationCache gespeichert, um \u00fcberfl\u00fcssige Datenbankanfragen zu vermeiden. Nach dem Start des Servers aktualisieren wir diesen Cache, erstellen und aktualisieren die Konfigurationen regelm\u00e4\u00dfig.<\/p>\n<h3>Daten sammeln<\/h3>\n<p>\nDas Schema ist recht umfangreich, aber das Wichtigste daran ist <strong>Sammler<\/strong>. Dies sind verschiedene \"Poller\" \u2014 Sammelprozesse. Sie sind f\u00fcr verschiedene Arten der Datensammlung verantwortlich: sie sammeln Daten \u00fcber SNMP, IPMI und leiten alles an PreProcessing weiter.<\/p>\n<p><img decoding=\"async\" alt=\"Hohe Leistung und natives Partitionieren: Zabbix mit Unterst\u00fctzung f\u00fcr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/deff5d9ff358f1b04b505d18c7770f21.jpg\" style=\"display:block;margin: 0 auto;\" \/><em>Die Sammler sind durch eine orange Linie umrandet.<\/em><\/p>\n<p>In Zabbix gibt es berechnete aggregierte Datenelemente, die ben\u00f6tigt werden, um Pr\u00fcfungen zu aggregieren. Wenn wir diese haben, holen wir die Daten direkt aus ValueCache.<\/p>\n<h3>PreProcessing HistoryCache<\/h3>\n<p>\nAlle Sammler verwenden ConfigurationCache, um Aufgaben zu erhalten. Dann leiten sie diese an PreProcessing weiter.<\/p>\n<p><img decoding=\"async\" alt=\"Hohe Leistung und natives Partitionieren: Zabbix mit Unterst\u00fctzung f\u00fcr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/116e25100ebdf9ed209a9b04fa6fa156.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPreProcessing nutzt ConfigurationCache, um Schritte des PreProcessings zu erhalten. Es verarbeitet diese Daten auf verschiedene Weise.<\/p>\n<p>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 \u00fcber \u2014 <strong>history syncer<\/strong>, da es sich um eine monolithische Architektur handelt.<\/p>\n<p><em>Hinweis: PreProcessing ist eine rechenintensive Operation. Ab Version 4.2 wurde sie auf den Proxy ausgelagert. Wenn Sie ein sehr gro\u00dfes Zabbix mit vielen Datenelementen und hoher Erfassungsfrequenz haben, erleichtert dies die Arbeit erheblich.<\/em><\/p>\n<h3>ValueCache, Verlauf &amp; Trends Cache<\/h3>\n<p><\/p>\n<blockquote><p>Der History Syncer ist der Hauptprozess, der jedes Datenelement atomar verarbeitet, d.h. jeden Wert.<\/p><\/blockquote>\n<p>\nDer History Syncer entnimmt Werte aus dem HistoryCache und pr\u00fcft in der Konfiguration, ob Trigger f\u00fcr Berechnungen vorhanden sind. Wenn ja, f\u00fchrt er die Berechnungen durch.<\/p>\n<p>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\u00fcr weitere Verarbeitung vorhanden sind, speichert er diesen Wert im ValueCache, um nicht auf die Verlaufstabelle zugreifen zu m\u00fcssen. So wird der ValueCache mit den ben\u00f6tigten Daten f\u00fcr die Triggerberechnungen gef\u00fcllt.<\/p>\n<p>Der History Syncer zeichnet alle Daten in der Datenbank auf, die wiederum auf die Festplatte geschrieben wird. Der Verarbeitungsprozess endet hier.<\/p>\n<p><img decoding=\"async\" alt=\"Hohe Leistung und natives Partitionieren: Zabbix mit Unterst\u00fctzung f\u00fcr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/4d74195381fda7756b0250982f6896be.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Caching in der Datenbank<\/h3>\n<p>\nAuf der Seite der Datenbank gibt es verschiedene Caches, wenn Sie Grafiken oder Berichte zu Ereignissen betrachten m\u00f6chten:<\/p>\n<ul>\n<li><code>Innodb_buffer_pool<\/code> auf der MySQL-Seite;<\/li>\n<li><code>shared_buffers<\/code> auf der PostgreSQL-Seite;<\/li>\n<li><code>effective_cache_size<\/code> auf der Oracle-Seite;<\/li>\n<li><code>shared_pool<\/code> auf der DB2-Seite.<\/li>\n<\/ul>\n<p>\nEs gibt viele andere Caches, aber dies sind die wichtigsten f\u00fcr alle Datenbanken. Sie erm\u00f6glichen es, Daten, die h\u00e4ufig f\u00fcr Abfragen ben\u00f6tigt werden, im Arbeitsspeicher zu halten. Daf\u00fcr gibt es spezielle Technologien.<\/p>\n<h3>Die Leistung der Datenbank ist entscheidend.<\/h3>\n<p>\nDer Zabbix-Server sammelt st\u00e4ndig Daten und speichert sie. Beim Neustart liest er ebenfalls aus der Historie, um den ValueCache zu f\u00fcllen. Skripte und Berichte werden verwendet. <strong>Zabbix API<\/strong>, das auf dem Web-Interface basiert. Die Zabbix API greift auf die Datenbank zu und erh\u00e4lt die ben\u00f6tigten Daten f\u00fcr Diagramme, Berichte, Ereignisliste und aktuelle Probleme.<\/p>\n<p><img decoding=\"async\" alt=\"Hohe Leistung und natives Partitionieren: Zabbix mit Unterst\u00fctzung f\u00fcr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/dd0efdc4e57c1197d448ce453012091e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nF\u00fcr die Visualisierung \u2014 <strong>Grafana<\/strong>. Unter unseren Nutzern ist dies eine beliebte L\u00f6sung. Sie kann direkt \u00fcber 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\u00e4hrleisten.<\/p>\n<h2>Housekeeper<\/h2>\n<p>\nDer dritte Leistungsaspekt in Zabbix ist die Datenhistorienbereinigung durch Housekeeper. Er beachtet alle Einstellungen \u2013 in den Datenelementen ist angegeben, wie viele Tage die \u00c4nderungsdynamik (Trends) aufbewahrt werden soll.<\/p>\n<p>TrendsCache wird in Echtzeit berechnet. Wenn Daten eintreffen, aggregieren wir sie \u00fcber einen Zeitraum von einer Stunde und speichern sie in Tabellen, um die Dynamik der Trendver\u00e4nderungen zu verfolgen.<\/p>\n<p>Housekeeper wird gestartet und entfernt Informationen aus der Datenbank mit herk\u00f6mmlichen \u201eSelects\u201c. Dies ist nicht immer effizient, wie man an den Diagrammen zur Leistung der internen Prozesse erkennen kann.<\/p>\n<p><img decoding=\"async\" alt=\"Hohe Leistung und natives Partitionieren: Zabbix mit Unterst\u00fctzung f\u00fcr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/a3af1badd14b1092bc26e0b53845ae04.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDas rote Diagramm zeigt, dass der History Syncer st\u00e4ndig besch\u00e4ftigt ist. Das orange Diagramm oben zeigt den Housekeeper, der immer wieder gestartet wird. Er wartet darauf, dass die Datenbank alle Zeilen l\u00f6scht, die er festgelegt hat.<\/p>\n<p>Wann sollte man den Housekeeper deaktivieren? Zum Beispiel, wenn es eine \u201eItem ID\u201c gibt und die letzten 5.000 Zeilen \u00fcber einen bestimmten Zeitraum gel\u00f6scht werden m\u00fcssen. Nat\u00fcrlich erfolgt dies \u00fcber Indizes. Aber in der Regel ist das Dataset sehr gro\u00df, und die Datenbank liest dennoch von der Festplatte und l\u00e4dt in den Cache. Das ist immer eine sehr kostspielige Operation f\u00fcr die Datenbank und kann, je nach Gr\u00f6\u00dfe der DB, zu Leistungsproblemen f\u00fchren.<\/p>\n<p><img decoding=\"async\" alt=\"Hohe Leistung und natives Partitionieren: Zabbix mit Unterst\u00fctzung f\u00fcr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/0778318b539fbe33318e8a7310f8a89b.jpg\" style=\"display:block;margin: 0 auto;\" \/> <\/p>\n<p>Der Housekeeper kann einfach deaktiviert werden. Im Web-Interface gibt es eine Einstellung unter \u201eAllgemeine Verwaltung\u201c f\u00fcr den Housekeeper. Wir deaktivieren die interne Haushaltsf\u00fchrung f\u00fcr die interne History der Trends, wodurch er nicht mehr daf\u00fcr zust\u00e4ndig ist.<\/p>\n<p>Housekeeper wurde deaktiviert, die Zeitpl\u00e4ne haben sich angeglichen \u2013 welche Probleme k\u00f6nnen in diesem Fall auftreten und wie kann man bei der dritten Leistungsanfrage helfen?<\/p>\n<h2>Partitionierung \u2013 Sektionierung oder Partionierung<\/h2>\n<p>\nIn der Regel wird Partitionierung unterschiedlich in jeder relationalen Datenbank eingerichtet, die ich aufgelistet habe. Jede hat ihre eigene Technologie, aber grunds\u00e4tzlich sind sie \u00e4hnlich. Das Erstellen einer neuen Partition f\u00fchrt oft zu bestimmten Problemen.<\/p>\n<p>In der Regel wird die Partitionierung je nach 'Setup' \u2013 der Menge an Daten, die an einem Tag erstellt werden \u2013 konfiguriert. Normalerweise wird Partitionierung f\u00fcr einen Tag eingestellt, das ist das Minimum. F\u00fcr die Trends einer neuen Partition \u2013 f\u00fcr 1 Monat.<\/p>\n<p>Die Werte k\u00f6nnen sich bei einem sehr gro\u00dfen 'Setup' \u00e4ndern. Wenn ein kleines 'Setup' bis zu 5.000 nvps (neue Werte pro Sekunde) betr\u00e4gt, ist das mittlere von 5.000 bis 25.000, und das gro\u00dfe \u00fcber 25.000 nvps. Dies sind gro\u00dfe und sehr gro\u00dfe Installationen, die eine sorgf\u00e4ltige Datenbankkonfiguration erfordern.<\/p>\n<p>Bei sehr gro\u00dfen Installationen kann ein Tagesabschnitt suboptimal sein. Ich habe in MySQL Partitionen gesehen, die \u00fcber 40 GB und mehr pro Tag umfassen. Das ist ein enormer Datenumfang, der zu Problemen f\u00fchren kann und muss reduziert werden.<\/p>\n<h3>Was bringt Partitionierung?<\/h3>\n<p>\n<strong>Tabellenpartitionierung<\/strong>. Oft handelt es sich um separate Dateien auf der Festplatte. Der Abfrageplan w\u00e4hlt optimierter eine Partition aus. In der Regel wird Partitionierung basierend auf einem Bereich verwendet \u2014 das gilt auch f\u00fcr Zabbix. Wir verwenden dort den \u201etimestamp\u201c \u2014 die Zeit seit der Epoche. In unserem Fall sind das g\u00e4ngige Zahlen. Sie geben den Beginn und das Ende des Tages an \u2014 das ist die Partition.<\/p>\n<p><strong>Schnelles L\u00f6schen<\/strong> \u2014 <code>DELETE<\/code>. Es wird eine Datei\/Subtabelle ausgew\u00e4hlt, nicht eine Zeilenabfrage zum L\u00f6schen.<\/p>\n<p><strong>Beschleunigt die Datenauswahl deutlich<\/strong> <code>SELECT<\/code> \u2014 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\u00dfe Tabelle.<\/p>\n<p>Oft beschleunigt das auch viele DBs <code>INSERT<\/code> \u2014 Einf\u00fcgungen in die Child-Tabelle.<\/p>\n<h2>TimescaleDB<\/h2>\n<p>\nF\u00fcr v 4.2 haben wir uns mit TimescaleDB besch\u00e4ftigt. 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.<\/p>\n<p>In TimescaleDB gibt es das Konzept <strong>der Hypertabelle<\/strong> (hypertable), die Sie erstellen. In ihr befinden sich <strong>Chunks<\/strong> \u2014 Partitionen. Chunks sind automatisch verwaltete Fragmente der Hypertabelle, die nicht die anderen Fragmente beeinflussen. Jeder Chunk hat seinen eigenen Zeitbereich.<\/p>\n<p><img decoding=\"async\" alt=\"Hohe Leistung und natives Partitionieren: Zabbix mit Unterst\u00fctzung f\u00fcr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/91a24560ff12aa17f98689e3445f50e1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>TimescaleDB vs PostgreSQL<\/h3>\n<p>\nTimescaleDB funktioniert wirklich effizient. Die Entwickler der Erweiterung behaupten, dass sie einen besseren Algorithmus zur Abwicklung von Anfragen verwenden, insbesondere f\u00fcr &lt;code&gt;Inserts&lt;\/code&gt;. Wenn die Gr\u00f6\u00dfen der Dataset-Einf\u00fcgungen wachsen, unterst\u00fctzt der Algorithmus konstante Leistung.<\/p>\n<p><img decoding=\"async\" alt=\"Hohe Leistung und natives Partitionieren: Zabbix mit Unterst\u00fctzung f\u00fcr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/52f042018180ffd2cb6a2cf4a3af603e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNach 200 Millionen Zeilen beginnt PostgreSQL normalerweise erheblich nachzulassen und verliert die Leistung auf 0. TimescaleDB erm\u00f6glicht es, Inserts bei jedem Datenvolumen effektiv einzuf\u00fcgen.<\/p>\n<h3>Installation von<\/h3>\n<p>\nDie Installation von TimescaleDB ist f\u00fcr alle Pakete recht einfach. In <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.timescale.com\/v1.3\/getting-started\">Dokumentation.<\/a><\/noindex> wird alles ausf\u00fchrlich beschrieben \u2014 es h\u00e4ngt von den offiziellen PostgreSQL-Paketen ab. TimescaleDB kann auch manuell gebaut und kompiliert werden.<\/p>\n<p>F\u00fcr die Zabbix-Datenbank aktivieren wir einfach die Erweiterung:<\/p>\n<pre><code class=\"sql\">echo \"CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;\" | sudo -u postgres psql zabbix<\/code><\/pre>\n<p>\nSie aktivieren <code>die Erweiterung<\/code> und erstellen sie f\u00fcr die Zabbix-Datenbank. Der letzte Schritt ist die Erstellung einer Hypertabelle.<\/p>\n<h3>Migration der Verlaufstabellen auf TimescaleDB<\/h3>\n<p>\nEs gibt daf\u00fcr eine spezielle Funktion <code>create_hypertable<\/code>:<\/p>\n<pre><code class=\"sql\">SELECT create_hypertable(\u2018history\u2019, \u2018clock\u2019, chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable(\u2018history_unit\u2019, \u2018clock\u2019, chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable(\u2018history_log\u2019, \u2018clock\u2019, chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable(\u2018history_text\u2019, \u2018clock\u2019, chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable(\u2018history_str\u2019, \u2018clock\u2019, chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable(\u2018trends\u2019, \u2018clock\u2019, chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable(\u2018trends_unit\u2019, \u2018clock\u2019, chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nUPDATE config SET db_extension=\u2019timescaledb\u2019, hk_history_global=1, hk_trends_global=1<\/code><\/pre>\n<p>\nDie Funktion hat drei Parameter. Der erste ist<strong> die Tabelle in der Datenbank<\/strong>, f\u00fcr die eine Hypertabelle erstellt werden soll. Der zweite ist <strong>das Feld<\/strong>, nach dem die Hypertabelle erstellt werden muss. <code>chunk_time_interval<\/code> ist das Intervall der Partitionierungs-Chunks, das verwendet werden soll. In meinem Fall betr\u00e4gt das Intervall einen Tag \u2014 86.400.<\/p>\n<p>Der dritte Parameter ist <code><strong>daten_migrieren<\/strong><\/code>. Wenn Sie einstellen <code>true<\/code>, werden alle aktuellen Daten in vordefinierte Chunks \u00fcbertragen. Ich habe es selbst verwendet <code>daten_migrieren<\/code>. Ich hatte etwa 1 TB, das hat mehr als eine Stunde gedauert. In einigen F\u00e4llen habe ich beim Testen sogar optionale historische Daten vom Zeichentyp gel\u00f6scht, um sie nicht zu \u00fcbertragen.<\/p>\n<p>Der letzte Schritt \u2014\u00a0<code><strong>UPDATE<\/strong><\/code>: In <code>db_extension<\/code> stellen wir <code>timescaledb<\/code>, damit die DB dieses Erweiterung versteht. Zabbix aktiviert es und nutzt die Syntax und Abfragen korrekt \u2014 die Funktionen, die f\u00fcr TimescaleDB erforderlich sind.<\/p>\n<h2>Konfiguration der Hardware<\/h2>\n<p>\nIch habe zwei Server verwendet. Der erste \u2014 <strong>VMware-Maschine<\/strong>. Sie ist ziemlich klein: 20 Intel\u00ae Xeon\u00ae CPU E5-2630 v 4 @ 2,20 GHz, 16 GB RAM und eine 200 GB SSD.<\/p>\n<p>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.<\/p>\n<p>Auf dieser Maschine liefen der Zabbix-Server, PostgreSQL und <strong>Lastagenten<\/strong>. Ich hatte 50 aktive Agenten, die <code>LoadableModule<\/code>, um sehr schnell verschiedene Ergebnisse zu generieren: Zahlen, Zeichenfolgen. Ich habe die Datenbank mit einer gro\u00dfen Menge Daten gef\u00fcllt.<\/p>\n<p>Die urspr\u00fcngliche Konfiguration enthielt <strong>5.000 Elemente<\/strong> Daten f\u00fcr jeden Host. Fast jedes Element hatte einen Trigger, um es realen Installationen \u00e4hnlich zu machen. In einigen F\u00e4llen gab es mehr als einen Trigger. Auf einen Knoten im Netzwerk entfielen <strong>3.000-7.000 Trigger<\/strong>.<\/p>\n<p>Aktualisierungsintervall der Datenelemente \u2014 <strong>4-7 Sekunden<\/strong>. Ich regulierte die Last, indem ich nicht nur 50 Agenten verwendete, sondern noch weitere hinzuf\u00fcgte. Au\u00dferdem passte ich mit Hilfe der Datenelemente die Last dynamisch an und senkte das Aktualisierungsintervall auf 4 s.<\/p>\n<h3>PostgreSQL. 35.000 nvps<\/h3>\n<p>\nDer erste Start auf dieser Hardware war mit reinem PostgreSQL \u2014 35.000 Werte pro Sekunde. Wie man sieht, dauert das Einf\u00fcgen von Daten Bruchteile von Sekunden \u2014 alles funktioniert gut und schnell. Einziges Manko ist, dass die SSD mit 200 GB schnell voll wird.<\/p>\n<p><img decoding=\"async\" alt=\"Hohe Leistung und natives Partitionieren: Zabbix mit Unterst\u00fctzung f\u00fcr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/e84b2eb0f6fbbd902c5feab367c750ee.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDas ist das Standard-Performance-Dashboard von Zabbix \u2014 Server.<\/p>\n<p><img decoding=\"async\" alt=\"Hohe Leistung und natives Partitionieren: Zabbix mit Unterst\u00fctzung f\u00fcr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/c3afe021acf8e272813b8d8c2f82e762.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDer 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 \u00fcber l\u00e4ngere Zeitr\u00e4ume aktiv waren.<\/p>\n<p>Das vierte Diagramm zeigt die Nutzung des HistoryCache. Dies ist ein Puffer vor der Einspeisung in die Datenbank. Das gr\u00fcne f\u00fcnfte Diagramm zeigt die Nutzung des ValueCache, das hei\u00dft, wie viele Zugriffe der ValueCache f\u00fcr die Trigger hat \u2014 das sind mehrere Tausend Werte pro Sekunde.<\/p>\n<h3>PostgreSQL. 50.000 nvps<\/h3>\n<p>\nIch habe die Last auf 50.000 Werte pro Sekunde auf derselben Hardware erh\u00f6ht.<\/p>\n<p><img decoding=\"async\" alt=\"Hohe Leistung und natives Partitionieren: Zabbix mit Unterst\u00fctzung f\u00fcr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/8f10944486d5502b57d36059382d551b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBeim Laden mit dem Housekeeper wurden 10.000 Werte in 2-3 Sekunden geschrieben.<\/p>\n<p><img decoding=\"async\" alt=\"Hohe Leistung und natives Partitionieren: Zabbix mit Unterst\u00fctzung f\u00fcr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/5228c1735f0ee2da7f827093f3c7b1f9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Der Housekeeper beginnt bereits, die Arbeit zu st\u00f6ren.<\/em><\/p>\n<p>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\u00e4hrend der Arbeit des Housekeepers bereits aktiv gef\u00fcllt zu werden. Er wurde zu 20% gef\u00fcllt \u2014 das sind etwa 0,5 GB.<\/p>\n<h3>PostgreSQL. 80.000 nvps<\/h3>\n<p>\nIch habe die Last auf 80.000 Werte pro Sekunde erh\u00f6ht. Das sind etwa 400.000 Datenelemente und 280.000 Trigger.<\/p>\n<p><img decoding=\"async\" alt=\"Hohe Leistung und natives Partitionieren: Zabbix mit Unterst\u00fctzung f\u00fcr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/f6c6b0d6793f96523f7406e68f98c608.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Die Einspeisung mit der Last von drei\u00dfig History Syncers ist bereits recht hoch.<\/em><\/p>\n<p>Ich habe auch verschiedene Parameter angepasst: History Syncers, Caches.<\/p>\n<p><img decoding=\"async\" alt=\"Hohe Leistung und natives Partitionieren: Zabbix mit Unterst\u00fctzung f\u00fcr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/6ca7edd76aea6fdec00a61a0a6dc34e5.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAuf meiner Hardware stieg die Auslastung der History Syncers bis zum Maximum. Der HistoryCache f\u00fcllte sich schnell mit Daten \u2014 im Puffer sammelten sich die Daten zur Verarbeitung.<\/p>\n<p>W\u00e4hrend 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.<\/p>\n<p><img decoding=\"async\" alt=\"Hohe Leistung und natives Partitionieren: Zabbix mit Unterst\u00fctzung f\u00fcr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/e964a000156b561accd23b4e1644f4a8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIch habe erreicht, dass <strong>die maximalen M\u00f6glichkeiten der Festplatte genutzt werden<\/strong> auf dieser Hardware und dieser virtuellen Maschine. Bei einer solchen Intensit\u00e4t begann PostgreSQL recht aktiv Daten zu verwalten, und die Festplatte konnte nicht mehr ausreichend lesen und schreiben.<\/p>\n<h3>Zweiter Server<\/h3>\n<p>\nIch habe einen anderen Server genommen, der bereits 48 Prozessoren und 128 GB Arbeitsspeicher hatte. Ich habe ihn optimiert \u2014 60 history syncer installiert und akzeptable Leistung erzielt.<\/p>\n<p><img decoding=\"async\" alt=\"Hohe Leistung und natives Partitionieren: Zabbix mit Unterst\u00fctzung f\u00fcr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/591fc759b336d5fb2091460036b136bf.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTats\u00e4chlich ist dies bereits das Leistungsmaximum, wo etwas unternommen werden muss.<\/p>\n<h3>TimescaleDB. 80.000 nvps<\/h3>\n<p>\nMeine Hauptaufgabe ist es, die M\u00f6glichkeiten von TimescaleDB unter der Last von Zabbix zu testen. 80.000 Werte pro Sekunde sind viel, die Frequenz der Metrik-Sammlung (au\u00dfer bei Yandex, nat\u00fcrlich) und ein ziemlich gro\u00dfes \u201eSetup\u201c.<\/p>\n<p><img decoding=\"async\" alt=\"Hohe Leistung und natives Partitionieren: Zabbix mit Unterst\u00fctzung f\u00fcr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/aa569847e7bc31baab91661db1ee78a2.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn jedem Diagramm gibt es einen Einbruch \u2014 das ist die Datenmigration. Nach den Einbr\u00fcchen im Zabbix-Server hat sich das Profil der Belastung des history syncer erheblich ver\u00e4ndert \u2014 es ist um das Dreifache gefallen.<\/p>\n<blockquote><p>TimescaleDB erm\u00f6glicht es, Daten nahezu dreimal schneller einzuf\u00fcgen und weniger HistoryCache zu verwenden.<\/p><\/blockquote>\n<p>\nSomit werden Ihnen die Daten rechtzeitig zur Verf\u00fcgung gestellt.<\/p>\n<h3>TimescaleDB. 120.000 nvps<\/h3>\n<p>\nAnschlie\u00dfend habe ich die Anzahl der Datenelemente auf 500.000 erh\u00f6ht. Die Hauptaufgabe bestand darin, die M\u00f6glichkeiten von TimescaleDB zu \u00fcberpr\u00fcfen \u2014 ich erhielt eine berechnete Rate von 125.000 Werten pro Sekunde.<\/p>\n<p><img decoding=\"async\" alt=\"Hohe Leistung und natives Partitionieren: Zabbix mit Unterst\u00fctzung f\u00fcr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/4770ca4030e1c086f2fd9305a12496bb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDas 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\u00fcllt.<\/p>\n<p><img decoding=\"async\" alt=\"Hohe Leistung und natives Partitionieren: Zabbix mit Unterst\u00fctzung f\u00fcr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/1ad521b909a22a7db81a9ed802d348e7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDas Wichtigste ist, dass gleichzeitig neue Partitionen in TimescaleDB erstellt wurden.<\/p>\n<p>F\u00fcr die Leistung ist das v\u00f6llig unauff\u00e4llig. Wenn zum Beispiel in MySQL Partitionen erstellt werden, sieht das ganz anders aus. Das geschieht normalerweise nachts, da es die gesamte Einf\u00fcgung blockiert, die Arbeit mit Tabellen beeintr\u00e4chtigen kann und m\u00f6glicherweise eine Dienstverschlechterung verursacht. Bei TimescaleDB tritt das nicht auf.<\/p>\n<p>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\u00f6hnliche virtuelle Maschine auf normalen Festplatten, nicht SSDs.<\/p>\n<p><img decoding=\"async\" alt=\"Hohe Leistung und natives Partitionieren: Zabbix mit Unterst\u00fctzung f\u00fcr TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/bea0cd0f1448e1d1b3a5f979d51ce61c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Fazit<\/h2>\n<p>\n<strong>TimescaleDB ist eine gute L\u00f6sung f\u00fcr kleine Setups.<\/strong>, die die Leistung der Festplatte betreffen. Es erm\u00f6glicht ein reibungsloses Arbeiten bis zur Migration der Datenbank auf schnellere Hardware.<\/p>\n<p>TimescaleDB ist einfach einzurichten, bietet Leistungssteigerungen und arbeitet gut mit Zabbix sowie <strong>hat Vorteile gegen\u00fcber PostgreSQL.<\/strong>.<\/p>\n<p>Wenn Sie PostgreSQL verwenden und nicht planen, es zu wechseln, empfehle ich, <strong>PostgreSQL mit der TimescaleDB-Erweiterung zusammen mit Zabbix zu nutzen.<\/strong>Diese L\u00f6sung funktioniert effizient bis zu mittleren Setups.<\/p>\n<blockquote>\n<p>Wenn wir von \u201ehoher Leistung\u201c sprechen, meinen wir <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\">HighLoad++<\/a><\/noindex>. Es ist nicht mehr lange hin, um Technologien und Praktiken kennenzulernen, die es Diensten erm\u00f6glichen, Millionen von Benutzern zu bedienen. Die Liste <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\/abstracts\">der Vortr\u00e4ge<\/a><\/noindex> f\u00fcr den 7. und 8. November haben wir bereits erstellt, aber <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\/meetups\">Meetups<\/a><\/noindex> kann man immer noch vorschlagen.<\/p>\n<p>Abonnieren Sie unsere <noindex><a rel=\"nofollow\" href=\"http:\/\/eepurl.com\/VYVaf\">Newsletter<\/a><\/noindex> und <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/HighLoadChannel\">telegram<\/a><\/noindex>, in denen wir die Highlights der bevorstehenden Konferenz vorstellen und erl\u00e4utern, wie man den gr\u00f6\u00dftm\u00f6glichen Nutzen daraus zieht.<\/p>\n<\/blockquote>\n<p>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/oleg-bunin\/blog\/470902\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>Zabbix \u2014 \u044d\u0442\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430. \u041a\u0430\u043a \u0438 \u043b\u044e\u0431\u0430\u044f \u0434\u0440\u0443\u0433\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430, \u043e\u043d\u0430 \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0441 \u0442\u0440\u0435\u043c\u044f \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u043c\u0438 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u043c\u0438 \u0432\u0441\u0435\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430: \u0441\u0431\u043e\u0440 \u0438 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u0434\u0430\u043d\u043d\u044b\u0445, \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u0435 \u0438\u0441\u0442\u043e\u0440\u0438\u0438, \u0435\u0435 \u043e\u0447\u0438\u0441\u0442\u043a\u0430. \u042d\u0442\u0430\u043f\u044b \u043f\u043e\u043b\u0443\u0447\u0435\u043d\u0438\u044f, \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0438 \u0437\u0430\u043f\u0438\u0441\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0442 \u0432\u0440\u0435\u043c\u044f. \u041d\u0435\u043c\u043d\u043e\u0433\u043e, \u043d\u043e \u0434\u043b\u044f \u043a\u0440\u0443\u043f\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u044d\u0442\u043e \u043c\u043e\u0436\u0435\u0442 \u0432\u044b\u043b\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0432 \u0431\u043e\u043b\u044c\u0448\u0438\u0435 \u0437\u0430\u0434\u0435\u0440\u0436\u043a\u0438. \u041f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u2014 \u044d\u0442\u043e \u0432\u043e\u043f\u0440\u043e\u0441 \u0434\u043e\u0441\u0442\u0443\u043f\u0430 \u043a \u0434\u0430\u043d\u043d\u044b\u043c. \u041e\u043d\u0438 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29204,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38927","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"Zabbix \u2014 \u044d\u0442\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430. \u041a\u0430\u043a \u0438 \u043b\u044e\u0431\u0430\u044f \u0434\u0440\u0443\u0433\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430, \u043e\u043d\u0430 \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0441 \u0442\u0440\u0435\u043c\u044f \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u043c\u0438 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u043c\u0438 \u0432\u0441\u0435\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430: \u0441\u0431\u043e\u0440 \u0438 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u0434\u0430\u043d\u043d\u044b\u0445, \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u0435 \u0438\u0441\u0442\u043e\u0440\u0438\u0438, \u0435\u0435 \u043e\u0447\u0438\u0441\u0442\u043a\u0430. \u042d\u0442\u0430\u043f\u044b \u043f\u043e\u043b\u0443\u0447\u0435\u043d\u0438\u044f, \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0438 \u0437\u0430\u043f\u0438\u0441\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0442 \u0432\u0440\u0435\u043c\u044f. \u041d\u0435\u043c\u043d\u043e\u0433\u043e, \u043d\u043e \u0434\u043b\u044f \u043a\u0440\u0443\u043f\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u044d\u0442\u043e \u043c\u043e\u0436\u0435\u0442 \u0432\u044b\u043b\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0432 \u0431\u043e\u043b\u044c\u0448\u0438\u0435 \u0437\u0430\u0434\u0435\u0440\u0436\u043a\u0438. \u041f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u2014 \u044d\u0442\u043e \u0432\u043e\u043f\u0440\u043e\u0441 \u0434\u043e\u0441\u0442\u0443\u043f\u0430 \u043a \u0434\u0430\u043d\u043d\u044b\u043c. \u041e\u043d\u0438\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0412\u044b\u0441\u043e\u043a\u0430\u044f \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0438 \u043d\u0430\u0442\u0438\u0432\u043d\u043e\u0435 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435: Zabbix \u0441 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u043e\u0439 TimescaleDB | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"Zabbix \u2014 \u044d\u0442\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430. \u041a\u0430\u043a \u0438 \u043b\u044e\u0431\u0430\u044f \u0434\u0440\u0443\u0433\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430, \u043e\u043d\u0430 \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0441 \u0442\u0440\u0435\u043c\u044f \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u043c\u0438 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u043c\u0438 \u0432\u0441\u0435\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430: \u0441\u0431\u043e\u0440 \u0438 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u0434\u0430\u043d\u043d\u044b\u0445, \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u0435 \u0438\u0441\u0442\u043e\u0440\u0438\u0438, \u0435\u0435 \u043e\u0447\u0438\u0441\u0442\u043a\u0430. \u042d\u0442\u0430\u043f\u044b \u043f\u043e\u043b\u0443\u0447\u0435\u043d\u0438\u044f, \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0438 \u0437\u0430\u043f\u0438\u0441\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0442 \u0432\u0440\u0435\u043c\u044f. \u041d\u0435\u043c\u043d\u043e\u0433\u043e, \u043d\u043e \u0434\u043b\u044f \u043a\u0440\u0443\u043f\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u044d\u0442\u043e \u043c\u043e\u0436\u0435\u0442 \u0432\u044b\u043b\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0432 \u0431\u043e\u043b\u044c\u0448\u0438\u0435 \u0437\u0430\u0434\u0435\u0440\u0436\u043a\u0438. \u041f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u2014 \u044d\u0442\u043e \u0432\u043e\u043f\u0440\u043e\u0441 \u0434\u043e\u0441\u0442\u0443\u043f\u0430 \u043a \u0434\u0430\u043d\u043d\u044b\u043c. \u041e\u043d\u0438\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:26:48+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:26:48+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Hohe Leistung und natives Partitionieren: Zabbix mit Unterst\u00fctzung f\u00fcr TimescaleDB | ProHoster","description":"Zabbix \u2014 ein \u00dcberwachungssystem. Wie jedes andere System steht es vor drei grundlegenden Herausforderungen der \u00dcberwachungssysteme: Datensammlung und -verarbeitung, Speicherung von Historie und deren Bereinigung. Die Phasen der Datenerfassung, -verarbeitung und -speicherung ben\u00f6tigen Zeit. Zwar nicht viel, aber bei einem gro\u00dfen System kann dies zu erheblichen Verz\u00f6gerungen f\u00fchren. Die Frage der Speicherung betrifft den Zugriff auf die Daten.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0412\u044b\u0441\u043e\u043a\u0430\u044f \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0438 \u043d\u0430\u0442\u0438\u0432\u043d\u043e\u0435 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435: Zabbix \u0441 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u043e\u0439 TimescaleDB | ProHoster","og:description":"Zabbix \u2014 \u044d\u0442\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430. \u041a\u0430\u043a \u0438 \u043b\u044e\u0431\u0430\u044f \u0434\u0440\u0443\u0433\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430, \u043e\u043d\u0430 \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0441 \u0442\u0440\u0435\u043c\u044f \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u043c\u0438 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u043c\u0438 \u0432\u0441\u0435\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430: \u0441\u0431\u043e\u0440 \u0438 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u0434\u0430\u043d\u043d\u044b\u0445, \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u0435 \u0438\u0441\u0442\u043e\u0440\u0438\u0438, \u0435\u0435 \u043e\u0447\u0438\u0441\u0442\u043a\u0430. \u042d\u0442\u0430\u043f\u044b \u043f\u043e\u043b\u0443\u0447\u0435\u043d\u0438\u044f, \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0438 \u0437\u0430\u043f\u0438\u0441\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0442 \u0432\u0440\u0435\u043c\u044f. \u041d\u0435\u043c\u043d\u043e\u0433\u043e, \u043d\u043e \u0434\u043b\u044f \u043a\u0440\u0443\u043f\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u044d\u0442\u043e \u043c\u043e\u0436\u0435\u0442 \u0432\u044b\u043b\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0432 \u0431\u043e\u043b\u044c\u0448\u0438\u0435 \u0437\u0430\u0434\u0435\u0440\u0436\u043a\u0438. \u041f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u2014 \u044d\u0442\u043e \u0432\u043e\u043f\u0440\u043e\u0441 \u0434\u043e\u0441\u0442\u0443\u043f\u0430 \u043a \u0434\u0430\u043d\u043d\u044b\u043c. \u041e\u043d\u0438","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:26:48+00:00","article:modified_time":"2019-10-31T19:26:48+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38927","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 23:59:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 21:14:06","updated":"2026-01-23 23:59:19"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/38927","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=38927"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/38927\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/29204"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=38927"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=38927"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=38927"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}