{"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 \u00dcberwachungssystem. Wie jedes andere System sieht es sich mit drei Hauptproblemen aller \u00dcberwachungssysteme konfrontiert: Datensammlung und -verarbeitung, Speicherung der Historie und deren Bereinigung.<\/p>\n<p>Die Phasen der Datenakquise, -verarbeitung und -speicherung ben\u00f6tigen Zeit. Wenig, aber f\u00fcr ein gro\u00dfes System kann das zu erheblichen Verz\u00f6gerungen f\u00fchren. Das Problem der Speicherung ist eine Frage des Zugriffs auf die Daten. Diese werden f\u00fcr Berichte, Pr\u00fcfungen und Trigger verwendet. Verz\u00f6gerungen beim Zugriff auf die Daten beeinflussen ebenfalls die Leistung. Wenn Datenbanken wachsen, m\u00fcssen veraltete Daten gel\u00f6scht werden. Das L\u00f6schen ist ein ressourcenintensiver Prozess, der auch einen Teil der Ressourcen beansprucht.<\/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 mit Verz\u00f6gerungen bei der Sammlung und Speicherung in Zabbix werden durch Caching gel\u00f6st: verschiedene Arten von Caches, Caching in der Datenbank. F\u00fcr das dritte Problem ist Caching jedoch nicht geeignet, weshalb in Zabbix TimescaleDB eingesetzt wird. Dar\u00fcber wird sprechen <strong>Andrei Guschin<\/strong> \u2014 Ingenieur im technischen Support <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/zabbix\/\">Zabbix SIA<\/a><\/noindex>. Andrei ist seit \u00fcber 6 Jahren im Zabbix-Support t\u00e4tig und hat direkte Erfahrung mit der Leistung.<\/p>\n<p>Wie funktioniert TimescaleDB, welche Leistung kann sie im Vergleich zu gew\u00f6hnlichem PostgreSQL bieten? Welche Rolle spielt Zabbix f\u00fcr die Datenbank TimescaleDB? Wie startet man von Grund auf und wie migriert man von PostgreSQL und welche Konfiguration bietet die beste Leistung? All dies kommt im weiteren Verlauf.<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 sieht sich bestimmten Leistungsherausforderungen gegen\u00fcber. Ich werde \u00fcber drei von ihnen sprechen: Datensammlung und -verarbeitung, Speicherung, Bereinigung der Historie.<\/p>\n<p><strong>Schnelle Datensammlung und -verarbeitung. <\/strong>Ein gutes \u00dcberwachungssystem sollte alle Daten schnell erfassen und sie gem\u00e4\u00df den Triggerbedingungen \u2014 nach eigenen Kriterien \u2014 verarbeiten. Nach der Verarbeitung sollte das System diese 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 einen benutzerfreundlichen Zugriff auf die Metriken erm\u00f6glichen. Die Historie ist notwendig, um sie in Berichten, Grafiken, Triggern, Schwellenwerten und berechneten Datenelementen 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. Warum ben\u00f6tigen Sie Daten, die vor 5 Jahren, einem oder zwei Monaten gesammelt wurden? Einige Knoten wurden entfernt, einige Hosts oder Metriken sind nicht mehr erforderlich, weil sie veraltet sind und nicht mehr gesammelt werden. Ein gutes \u00dcberwachungssystem sollte historische Daten speichern und diese gelegentlich l\u00f6schen, um das Datenbankwachstum zu begrenzen.<\/p>\n<blockquote><p>Die Reinigung von veralteten Daten ist eine kritische Frage, die sich stark auf die Leistung der Datenbank auswirkt.<\/p><\/blockquote>\n<p><\/p>\n<h2>Caching in Zabbix<\/h2>\n<p>\nIn Zabbix werden der erste und der zweite Aufruf durch Caching gel\u00f6st. F\u00fcr das Sammeln und Verarbeiten von Daten wird der Arbeitsspeicher verwendet. Zum Speichern gibt es Historien in Triggern, Grafiken und berechneten Datenelementen. Auf der Datenbankseite ist ein gewisses Caching f\u00fcr grundlegende Abfragen vorhanden, beispielsweise f\u00fcr Grafiken.<\/p>\n<p>Caching auf der Seite des Zabbix-Servers ist:<\/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 diese n\u00e4her.<\/p>\n<h3>ConfigurationCache<\/h3>\n<p>\nDies ist der Hauptcache, in dem wir Metriken, Hosts, Datenelemente, Trigger speichern \u2014 alles, was f\u00fcr die Vorverarbeitung und das Sammeln von Daten erforderlich ist.<\/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 unn\u00f6tige Datenbankanfragen zu vermeiden. Nach dem Start des Servers aktualisieren wir diesen Cache, erstellen und aktualisieren regelm\u00e4\u00dfig die Konfigurationen.<\/p>\n<h3>Datensammlung<\/h3>\n<p>\nDas Schema ist ziemlich gro\u00df, aber das Wesentliche ist <strong>Sammler<\/strong>. Dies sind verschiedene \u201ePoller\u201c \u2014 Sammelprozesse. Sie sind f\u00fcr verschiedene Arten der Datensammlung verantwortlich: Sie sammeln Daten \u00fcber SNMP, IPMI, und leiten dies alles zur Vorverarbeitung 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 mit einer orangefarbenen Linie umrandet.<\/em><\/p>\n<p>In Zabbix gibt es berechnete aggregierte Datenelemente, die ben\u00f6tigt werden, um Pr\u00fcfungen zu aggregieren. Wenn wir sie haben, holen wir die Daten f\u00fcr sie direkt aus dem ValueCache.<\/p>\n<h3>PreProcessing HistoryCache<\/h3>\n<p>\nAlle Sammler nutzen den ConfigurationCache, um Aufgaben zu erhalten. Danach leiten sie diese zur Vorverarbeitung 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 \/>\nDie Vorverarbeitung nutzt den ConfigurationCache, um Schritte der Vorverarbeitung zu erhalten. Sie verarbeitet diese Daten auf verschiedene Weise.<\/p>\n<p>Nach der Datenverarbeitung durch die Vorverarbeitung speichern wir sie im HistoryCache, um sie zu verarbeiten. Damit endet das Sammeln von Daten und wir gehen zum Hauptprozess in Zabbix \u00fcber \u2014 <strong>history syncer<\/strong>, da dies eine monolithische Architektur ist.<\/p>\n<p><em>Hinweis: Die Vorverarbeitung ist eine recht aufwendige Operation. Ab Version 4.2 wurde sie auf den Proxy ausgelagert. Wenn Sie ein sehr gro\u00dfes Zabbix mit vielen Datenelementen und einer hohen Abfragfrequenz haben, erleichtert dies die Arbeit erheblich.<\/em><\/p>\n<h3>ValueCache, Verlauf und Trends Cache<\/h3>\n<p><\/p>\n<blockquote><p>Der History Syncer ist der Hauptprozess, der jedes Datenelement atomar verarbeitet, das hei\u00dft, jeden Wert.<\/p><\/blockquote>\n<p>\nDer History Syncer nimmt Werte aus dem HistoryCache und \u00fcberpr\u00fcft in der Konfiguration das Vorhandensein von Triggern f\u00fcr Berechnungen. Wenn sie vorhanden sind, berechnet er.<\/p>\n<p>Der History Syncer erstellt ein Ereignis, eine Eskalation, um Benachrichtigungen zu erstellen, falls es in der Konfiguration erforderlich ist, und protokolliert sie. Wenn Triggers f\u00fcr die anschlie\u00dfende Verarbeitung vorhanden sind, merkt sich dieser Wert im ValueCache, um nicht auf die Verlaufstabelle zuzugreifen. So wird der ValueCache mit den Daten gef\u00fcllt, die zur Berechnung der Trigger und berechneten Elemente erforderlich sind.<\/p>\n<p>Der History Syncer schreibt alle Daten in die Datenbank, und diese in die Festplatte. Der Verarbeitungsprozess endet damit.<\/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 \u00fcber Ereignisse anzeigen 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 noch viele andere Caches, aber dies sind die wichtigsten f\u00fcr alle Datenbanken. Sie erm\u00f6glichen es, die Daten, die h\u00e4ufig f\u00fcr Abfragen erforderlich sind, im Arbeitsspeicher zu halten. Sie haben ihre eigenen Technologien daf\u00fcr.<\/p>\n<h3>Die Leistung der Datenbank ist kritisch wichtig.<\/h3>\n<p>\nDer Zabbix-Server sammelt st\u00e4ndig Daten und protokolliert sie. Bei einem Neustart liest er ebenfalls aus dem Verlauf, um den ValueCache zu f\u00fcllen. Skripte und Berichte verwenden <strong>Zabbix API<\/strong>, die auf der Grundlage der Weboberfl\u00e4che basiert. Die Zabbix API greift auf die Datenbank zu und erh\u00e4lt die erforderlichen Daten f\u00fcr Grafiken, Berichte, Ereignislisten 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 \/>\nZur Visualisierung \u2014 <strong>Grafana<\/strong>. Bei unseren Nutzern ist dies eine beliebte L\u00f6sung. Sie kann direkt Anfragen \u00fcber die Zabbix API an die Datenbank senden und schafft damit eine gewisse Konkurrenz beim Abrufen von Daten. Daher ist eine feinere und bessere Konfiguration der Datenbank erforderlich, um der schnellen Ausgabe von Ergebnissen und Tests gerecht zu werden.<\/p>\n<h2>Housekeeper<\/h2>\n<p>\nDer dritte Leistungsaufruf in Zabbix ist die Bereinigung des Verlaufs mithilfe von Housekeeper. Er beachtet alle Einstellungen \u2014 in den Datenelementen ist angegeben, wie lange die Dynamik der Ver\u00e4nderungen (Trends) in Tagen aufbewahrt werden soll.<\/p>\n<p>TrendsCache berechnen wir in Echtzeit. Wenn Daten eingehen, aggregieren wir sie \u00fcber eine Stunde und speichern sie in Tabellen f\u00fcr die Dynamik der Ver\u00e4nderungen von Trends.<\/p>\n<p>Der Housekeeper wird gestartet und entfernt Informationen aus der Datenbank mit gew\u00f6hnlichen \u00abselects\u00bb. Das ist nicht immer effizient, was man an den Leistungsdiagrammen interner 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 st\u00e4ndig gestartet wird. Er wartet darauf, dass die Datenbank alle Zeilen entfernt, die er festgelegt hat.<\/p>\n<p>Wann sollte man den Housekeeper deaktivieren? Zum Beispiel, wenn es eine \u00abItem ID\u00bb gibt und die letzten 5.000 Zeilen \u00fcber einen bestimmten Zeitraum gel\u00f6scht werden sollen. Nat\u00fcrlich geschieht dies \u00fcber Indizes. In der Regel ist der Datensatz jedoch sehr gro\u00df, und die Datenbank liest dennoch von der Festplatte und hebt in den Cache. Dies ist immer eine sehr teure Operation f\u00fcr die Datenbank und kann je nach Gr\u00f6\u00dfe der Datenbank 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>Man kann den Housekeeper einfach deaktivieren. Im Web-Interface gibt es eine Einstellung in \u00abAdministration general\u00bb f\u00fcr den Housekeeper. Wir deaktivieren das interne Housekeeping f\u00fcr die interne Trendhistorie, und er verwaltet dies nicht mehr.<\/p>\n<p>Der Housekeeper wurde deaktiviert, die Diagramme haben sich stabilisiert \u2013 welche Probleme k\u00f6nnten in diesem Fall auftreten und was k\u00f6nnte bei der L\u00f6sung des dritten Leistungsaufrufs helfen?<\/p>\n<h2>Partitionierung<\/h2>\n<p>\nIn der Regel wird die Partitionierung auf verschiedene Weise in jeder relationalen Datenbank konfiguriert, die ich aufgelistet habe. Jede hat ihre eigene Technologie, aber sie sind im Allgemeinen \u00e4hnlich. Die Erstellung einer neuen Partition f\u00fchrt oft zu bestimmten Problemen.<\/p>\n<p>In der Regel werden Partitionen je nach \u00absetup\u00bb \u2013 der Menge an Daten, die an einem Tag erzeugt werden \u2013 konfiguriert. Normalerweise wird die Partitionierung f\u00fcr einen Tag festgelegt, das ist das Minimum. F\u00fcr die Trends einer neuen Partition \u2013 f\u00fcr 1 Monat.<\/p>\n<p>Die Werte k\u00f6nnen sich im Falle eines sehr gro\u00dfen \u00absetup\u00bb \u00e4ndern. Wenn das kleine \u00absetup\u00bb bis zu 5.000 nvps (neue Werte pro Sekunde) betr\u00e4gt, betr\u00e4gt der Durchschnitt zwischen 5.000 und 25.000, und gro\u00df ist \u00fcber 25.000 nvps. Dies sind gro\u00dfe und sehr gro\u00dfe Installationen, die eine sorgf\u00e4ltige Konfiguration der Datenbank erfordern.<\/p>\n<p>Bei sehr gro\u00dfen Installationen kann ein Zeitraum von einem Tag nicht optimal sein. Ich habe bei MySQL Partitionen von 40 GB und mehr pro Tag gesehen. Dies ist eine sehr gro\u00dfe Datenmenge, die zu Problemen f\u00fchren kann, und sie muss verkleinert werden.<\/p>\n<h3>Was bringt die Partitionierung?<\/h3>\n<p>\n<strong>Partitionierung von Tabellen<\/strong>. Oft sind dies separate Dateien auf der Festplatte. Der Anfrageplan w\u00e4hlt optimaler eine Partition aus. Normalerweise wird Partitionierung nach Bereich verwendet \u2013 das gilt auch f\u00fcr Zabbix. Wir verwenden dort \u201etimestamp\u201c \u2013 die Zeit seit der Epoche. Bei uns sind das gew\u00f6hnliche Zahlen. Sie geben den Beginn und das Ende des Tages an \u2013 das ist die Partition.<\/p>\n<p><strong>Schnelles L\u00f6schen<\/strong> \u2014 <code>DELETE<\/code>. Es wird eine Datei\/Subtabelle ausgew\u00e4hlt und nicht eine Zeilenabfrage zum L\u00f6schen.<\/p>\n<p><strong>Er beschleunigt die Datenauswahl merklich<\/strong> <code>SELECT<\/code> \u2014 verwendet eine oder mehrere Partitionen und nicht die gesamte Tabelle. Wenn Sie nach Daten von vor zwei Tagen fragen, werden sie schneller aus der DB abgerufen, da nur eine Datei in den Cache geladen und nicht eine gro\u00dfe Tabelle ausgegeben werden muss.<\/p>\n<p>Oft beschleunigt es 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 auf TimescaleDB geachtet. Dies ist eine Erweiterung f\u00fcr PostgreSQL mit nativem Interface. Die Erweiterung funktioniert effizient mit Zeitreihendaten, ohne die Vorteile relationaler DBs zu verlieren. TimescaleDB partitioniert auch automatisch.<\/p>\n<p>In TimescaleDB gibt es das Konzept <strong>Hypertabelle<\/strong> (hypertable), die Sie erstellen. Darin befinden sich <strong>Chunks<\/strong> \u2014 Partitionen. Chunks sind automatisch verwaltete Fragmente der Hypertabelle, die andere Fragmente nicht 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 arbeitet wirklich effizient. Die Hersteller der Erweiterung behaupten, dass sie einen genaueren Algorithmus zur Anfragebearbeitung verwenden, insbesondere f\u00fcr &lt;code&gt;inserts&lt;\\\/code&gt;. Wenn die Gr\u00f6\u00dfe der Dataset-Einf\u00fcgungen w\u00e4chst, bleibt die Leistung konstant.<\/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 zu sinken und verliert die Leistung bis auf 0. TimescaleDB erm\u00f6glicht die effiziente Einf\u00fcgung von \u201einserts\u201c bei jeder Datenmenge.<\/p>\n<h3>Installation<\/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> alles ausf\u00fchrlich beschrieben \u2013 es basiert auf den offiziellen PostgreSQL-Paketen. TimescaleDB kann auch manuell zusammengestellt und kompiliert werden.<\/p>\n<p>F\u00fcr die Zabbix-DB 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 die <code>Erweiterung<\/code> und erstellen sie f\u00fcr die Zabbix-DB. Der letzte Schritt ist die Erstellung der Hypertabelle.<\/p>\n<h3>Migration von Geschichte-Tabellen zu TimescaleDB<\/h3>\n<p>\nDaf\u00fcr gibt es eine spezielle Funktion <code>create_hypertable<\/code>:<\/p>\n<pre><code class=\"sql\">W\u00c4HLEN Sie create_hypertable('history', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nW\u00c4HLEN Sie create_hypertable('history_unit', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nW\u00c4HLEN Sie create_hypertable('history_log', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nW\u00c4HLEN Sie create_hypertable('history_text', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nW\u00c4HLEN Sie create_hypertable('history_str', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nW\u00c4HLEN Sie create_hypertable('trends', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nW\u00c4HLEN Sie create_hypertable('trends_unit', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nAKTUALISIEREN Sie config SET db_extension='timescaledb', hk_history_global=1, hk_trends_global=1<\/code><\/pre>\n<p>\nDie Funktion hat drei Parameter. Der erste \u2014<strong> Tabelle in der DB<\/strong>, f\u00fcr die eine Hypertabelle erstellt werden muss. Der zweite \u2014 <strong>Feld<\/strong>, nach dem eine Erstellung erfolgen soll <code>chunk_time_interval<\/code> \u2013 der Chunk-Zeitintervall f\u00fcr die Partitionen, die verwendet werden sollen. In meinem Fall betr\u00e4gt das Intervall einen Tag \u2013 86\u00a0400.<\/p>\n<p>Der dritte Parameter \u2014 <code><strong>Daten migrieren<\/strong><\/code>. Wenn Sie setzen <code>true<\/code>, werden alle aktuellen Daten in die im Voraus erstellten Chunks verschoben. Ich habe selbst verwendet <code>Daten migrieren<\/code>. Ich hatte etwa 1 TB, was mehr als eine Stunde dauerte. Selbst in einigen F\u00e4llen habe ich w\u00e4hrend der Tests nicht ben\u00f6tigte historische Daten von Zeichentypen gel\u00f6scht, um sie nicht zu migrieren.<\/p>\n<p>Der letzte Schritt \u2014\u00a0<code><strong>UPDATE<\/strong><\/code>: in <code>db_extension<\/code> setzen wir <code>timescaledb<\/code>, damit die DB versteht, dass diese Erweiterung existiert. Zabbix aktiviert sie und verwendet korrekt die Syntax und Abfragen zur DB \u2013 die Funktionen, die f\u00fcr TimescaleDB erforderlich sind.<\/p>\n<h2>Hardware-Konfiguration<\/h2>\n<p>\nIch habe zwei Server verwendet. Der erste \u2014 <strong>VMware-Maschine<\/strong>. Sie ist recht klein: 20 Intel\u00ae Xeon\u00ae CPU E5-2630 v 4 @ 2.20GHz, 16 GB RAM und eine SSD mit 200 GB.<\/p>\n<p>Ich habe darauf PostgreSQL 10.8 mit Debian 10.8-1.pgdg90+1 und dem Dateisystem xfs installiert. Ich habe alles minimal konfiguriert, um genau diese Datenbank zu verwenden, abgesehen davon, dass sie selbst von Zabbix verwendet wird.<\/p>\n<p>Auf derselben Maschine lief 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 DB mit einer gro\u00dfen Menge an Daten gef\u00fcllt.<\/p>\n<p>Urspr\u00fcnglich enthielt die Konfiguration <strong>5\u00a0000 Elemente<\/strong> Daten f\u00fcr jeden Host. Fast jedes Element hatte einen Trigger, um es wie echte Installationen erscheinen zu lassen. In einigen F\u00e4llen gab es mehr als einen Trigger. Pro Knoten im Netzwerk kamen <strong>3\u00a0000-7\u00a0000 Trigger<\/strong>.<\/p>\n<p>Das Aktualisierungsintervall der Datenelemente \u2014 <strong>4-7 Sekunden<\/strong>. Ich habe die Last dadurch reguliert, dass ich nicht nur 50 Agenten verwendet habe, sondern noch weitere hinzugef\u00fcgt habe. Au\u00dferdem habe ich mit den Datenelementen die Last dynamisch reguliert und das Aktualisierungsintervall auf 4 Sekunden gesenkt.<\/p>\n<h3>PostgreSQL. 35\u00a0000 nvps<\/h3>\n<p>\nDer erste Start auf dieser Hardware erfolgte 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. Das einzige, was passiert, ist, dass die 200 GB SSD-Festplatte 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-Dashboard f\u00fcr die Leistung 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 \u2014 die Last der Sammlerprozesse. Der dritte \u2014 die Last der internen Sammlerprozesse: History Syncers und Housekeeper, was hier ausreichend Zeit in Anspruch nahm.<\/p>\n<p>Der vierte Graph zeigt die Nutzung des HistoryCache. Das ist ein Puffer vor dem Einf\u00fcgen in die Datenbank. Der gr\u00fcne f\u00fcnfte Graph zeigt die Nutzung des ValueCache, also wie viele Hits der ValueCache f\u00fcr Trigger hat \u2014 das sind mehrere Tausend Werte pro Sekunde.<\/p>\n<h3>PostgreSQL. 50\u00a0000 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 Housekeeper wurde das Einf\u00fcgen von 10.000 Werten in 2-3 Sekunden aufgezeichnet.<\/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>Housekeeper beginnt bereits, die Arbeit zu st\u00f6ren.<\/em><\/p>\n<p>Im dritten Graphen sieht man, dass die Last der Trapper und History Syncers insgesamt noch bei 60 % liegt. Im vierten Graphen wird der HistoryCache w\u00e4hrend der Arbeit des Housekeepers bereits aktiv gef\u00fcllt. Er hat sich zu 20 % gef\u00fcllt \u2014 das sind etwa 0,5 GB.<\/p>\n<h3>PostgreSQL. 80\u00a0000 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>Der Insert mit der Last von drei\u00dfig History Syncers ist bereits ziemlich hoch.<\/em><\/p>\n<p>Zudem habe ich verschiedene Parameter erh\u00f6ht: 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 erh\u00f6hte sich die Last der History Syncers bis zum Maximum. Der HistoryCache f\u00fcllte sich schnell mit Daten \u2014 im Puffer sammelten sich die zu verarbeitenden Daten.<\/p>\n<p>W\u00e4hrend der ganzen Zeit habe ich beobachtet, wie der Prozessor, der Arbeitsspeicher und andere Systemparameter genutzt wurden, und habe festgestellt, dass die Disknutzung 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 die Nutzung erreicht <strong>der maximalen Diskkapazit\u00e4ten<\/strong> auf dieser Hardware und dieser virtuellen Maschine. Bei solcher Intensit\u00e4t begann PostgreSQL, die Daten ziemlich aktiv abzulehnen, und die Festplatte konnte nicht mehr mit dem Schreiben und Lesen nachkommen.<\/p>\n<h3>Zweiter Server<\/h3>\n<p>\nIch habe einen anderen Server genommen, der bereits 48 Prozessoren und 128 GB RAM hatte. Ich habe ihn optimiert \u2013 60 History Syncer installiert, und eine akzeptable Leistung erreicht.<\/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 \/>\nFaktisch ist dies bereits die Leistungsgrenze, wo etwas unternommen werden muss.<\/p>\n<h3>TimescaleDB. 80.000 nvps<\/h3>\n<p>\nMein Hauptziel ist es, die M\u00f6glichkeiten von TimescaleDB unter der Last von Zabbix zu \u00fcberpr\u00fcfen. 80.000 Werte pro Sekunde sind viel, die Frequenz der Metrikabfrage (au\u00dfer bei Yandex, nat\u00fcrlich) und ein ziemlich gro\u00dfer \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 \/>\nJeder Graph weist Einbr\u00fcche auf \u2013 das ist genau die Migration der Daten. Nach den Einbr\u00fcchen auf dem Zabbix-Server hat sich das Lastprofil des History Syncer drastisch ver\u00e4ndert \u2013 es ist um das Dreifache gefallen.<\/p>\n<blockquote><p>TimescaleDB erm\u00f6glicht es, Daten praktisch dreimal schneller einzuf\u00fcgen und weniger HistoryCache zu verwenden.<\/p><\/blockquote>\n<p>\nDementsprechend werden Ihnen die Daten rechtzeitig zur Verf\u00fcgung gestellt.<\/p>\n<h3>TimescaleDB. 120.000 nvps<\/h3>\n<p>\nDann habe ich die Anzahl der Datenelemente auf 500.000 erh\u00f6ht. Die Hauptaufgabe war es, die M\u00f6glichkeiten von TimescaleDB zu testen \u2013 ich habe einen gesch\u00e4tzten Wert von 125.000 Werten pro Sekunde erhalten.<\/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 funktionierender \u201eSetup\u201c, der lange betrieben werden kann. Aber da meine Festplatte nur 1,5 TB gro\u00df war, habe ich sie in ein paar Tagen voll erhalten.<\/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 von TimescaleDB erstellt wurden.<\/p>\n<p>F\u00fcr die Leistung ist das v\u00f6llig unauff\u00e4llig. Wenn Partitionen in MySQL erstellt werden, ist das zum Beispiel ganz anders. Normalerweise geschieht das nachts, da es die allgemeine Einf\u00fcgung blockiert, die Arbeit mit Tabellen behindert und die Servicequalit\u00e4t degradieren kann. Im Falle von TimescaleDB ist das nicht der Fall.<\/p>\n<p>Zur Veranschaulichung zeige ich einen Graphen aus vielen in der Community. Das Bild zeigt, dass TimescaleDB aktiviert wurde, wodurch die Last bez\u00fcglich der Nutzung von io.weight auf der CPU gesenkt wurde. Die Nutzung interner Prozess-Elemente ist ebenfalls zur\u00fcckgegangen. Dabei handelt es sich um eine normale virtuelle Maschine auf herk\u00f6mmlichen 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>Das DBMS Tarantool ist ein attraktives, zukunftstr\u00e4chtiges Produkt zur Erstellung von hochbelasteten Anwendungen.<\/h2>\n<p>\n<strong>TimescaleDB ist eine gute L\u00f6sung f\u00fcr kleine \u201eSetups\u201c<\/strong>, die an der Leistung der Festplatte scheitern. Es wird erm\u00f6glichen, bis zur Migration der Datenbank auf leistungsf\u00e4higere Hardware gut weiterzuarbeiten.<\/p>\n<p>TimescaleDB ist einfach einzurichten, bietet Leistungssteigerungen und funktioniert gut mit Zabbix und <strong>hat Vorteile gegen\u00fcber PostgreSQL.<\/strong>.<\/p>\n<p>Wenn Sie PostgreSQL verwenden und nicht vorhaben, es zu \u00e4ndern, empfehle ich <strong>die Verwendung von PostgreSQL mit der Erweiterung TimescaleDB in Verbindung mit Zabbix.<\/strong>Diese L\u00f6sung funktioniert effizient bis zu mittleren \u201eSetups\u201c.<\/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 dauert nicht lange, um Technologien und Praktiken kennenzulernen, die es den Diensten erm\u00f6glichen, Millionen von Nutzern zu bedienen. Die Liste <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\/abstracts\">der Berichte<\/a><\/noindex> f\u00fcr den 7. und 8. November haben wir bereits vorbereitet, aber <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\/meetups\">Meetups<\/a><\/noindex> k\u00f6nnen noch vorgeschlagen werden.<\/p>\n<p>Abonnieren Sie unseren <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 dem wir die Highlights der bevorstehenden Konferenz enth\u00fcllen und erfahren, wie Sie den gr\u00f6\u00dftm\u00f6glichen Nutzen daraus ziehen k\u00f6nnen.<\/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 5.0.1.1 - 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.\" \/>\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) 5.0.1.1\" \/>\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.\" \/>\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 native Partitionierung: Zabbix mit Unterst\u00fctzung f\u00fcr TimescaleDB | ProHoster","description":"Zabbix ist ein \u00dcberwachungssystem.","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.","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}