{"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\/fr\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","title":{"rendered":"Haute performance et partitionnement natif : Zabbix avec support de TimescaleDB","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Zabbix est un syst\u00e8me de surveillance. Comme tout autre syst\u00e8me, il est confront\u00e9 \u00e0 trois probl\u00e8mes principaux de tous les syst\u00e8mes de surveillance : la collecte et le traitement des donn\u00e9es, le stockage de l'historique, et son nettoyage.<\/p>\n<p>Les \u00e9tapes de collecte, de traitement et d'enregistrement des donn\u00e9es prennent du temps. Un peu, mais pour un grand syst\u00e8me, cela peut se traduire par de grands d\u00e9lais. Le probl\u00e8me du stockage est une question d'acc\u00e8s aux donn\u00e9es. Elles sont utilis\u00e9es pour les rapports, les v\u00e9rifications et les d\u00e9clencheurs. Les retards d'acc\u00e8s aux donn\u00e9es affectent \u00e9galement les performances. Lorsque la base de donn\u00e9es se d\u00e9veloppe, il faut supprimer les donn\u00e9es obsol\u00e8tes. La suppression est une op\u00e9ration lourde qui consomme \u00e9galement une partie des ressources.<\/p>\n<p><img decoding=\"async\" alt=\"Haute performance et partitionnement natif : Zabbix avec support de TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/9b7aa23705cd32b4d8d858ad78b181fd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLes probl\u00e8mes de d\u00e9lais lors de la collecte et du stockage dans Zabbix sont r\u00e9solus par le cache : plusieurs types de caches, le cache dans la base de donn\u00e9es. Pour r\u00e9soudre le troisi\u00e8me probl\u00e8me, le cache ne convient pas, c'est pourquoi Zabbix utilise TimescaleDB. Cela sera expliqu\u00e9 par <strong>Andrey Guschin<\/strong> \u2014 ing\u00e9nieur de support technique <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/zabbix\/\">Zabbix SIA<\/a><\/noindex>. Andrey travaille chez Zabbix depuis plus de 6 ans et fait face directement \u00e0 la performance.<\/p>\n<p>Comment fonctionne TimescaleDB, quelles performances peut-elle offrir par rapport \u00e0 un PostgreSQL classique ? Quel est le r\u00f4le de Zabbix pour une base de donn\u00e9es TimescaleDB ? Comment d\u00e9marrer \u00e0 partir de z\u00e9ro et comment migrer depuis PostgreSQL, et quelle configuration offre les meilleures performances ? Tout cela est abord\u00e9 ci-dessous.<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=\"Lire la vid\u00e9o\" 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>D\u00e9fis de performance<\/h2>\n<p>\nChaque syst\u00e8me de surveillance est confront\u00e9 \u00e0 des d\u00e9fis de performance sp\u00e9cifiques. Je vais parler de trois d'entre eux : la collecte et le traitement des donn\u00e9es, le stockage, et le nettoyage de l'historique.<\/p>\n<p><strong>Collecte et traitement des donn\u00e9es rapides. <\/strong>Un bon syst\u00e8me de surveillance doit pouvoir obtenir rapidement toutes les donn\u00e9es et les traiter en fonction des expressions d\u00e9clencheurs \u2014 selon ses propres crit\u00e8res. Apr\u00e8s traitement, le syst\u00e8me doit \u00e9galement sauvegarder ces donn\u00e9es rapidement dans la base de donn\u00e9es pour un usage futur.<\/p>\n<p><strong>Stockage de l'historique. <\/strong>Un bon syst\u00e8me de surveillance doit stocker l'historique dans la base de donn\u00e9es et fournir un acc\u00e8s facile aux m\u00e9triques. L'historique est n\u00e9cessaire pour l'utiliser dans les rapports, les graphiques, les d\u00e9clencheurs, les seuils et les \u00e9l\u00e9ments de donn\u00e9es calcul\u00e9s pour les alertes.<\/p>\n<p><strong>Nettoyage de l'historique. <\/strong>Parfois, il arrive un jour o\u00f9 vous n'avez plus besoin de conserver les m\u00e9triques. Pourquoi conserver des donn\u00e9es collect\u00e9es il y a 5 ans, un mois ou deux : certains n\u0153uds ont \u00e9t\u00e9 supprim\u00e9s, certains h\u00f4tes ou m\u00e9triques ne sont plus n\u00e9cessaires car obsol\u00e8tes et ne sont plus collect\u00e9s. Un bon syst\u00e8me de surveillance doit conserver des donn\u00e9es historiques et les supprimer de temps en temps pour \u00e9viter que la base de donn\u00e9es ne devienne trop volumineuse.<\/p>\n<blockquote><p>La suppression des donn\u00e9es obsol\u00e8tes est un sujet sensible qui a un impact fort sur les performances de la base de donn\u00e9es.<\/p><\/blockquote>\n<p><\/p>\n<h2>Mise en cache dans Zabbix<\/h2>\n<p>\nDans Zabbix, le premier et le deuxi\u00e8me appels sont r\u00e9solus gr\u00e2ce \u00e0 la mise en cache. Pour la collecte et le traitement des donn\u00e9es, la m\u00e9moire vive est utilis\u00e9e. Pour le stockage \u2014 l'historique dans les d\u00e9clencheurs, les graphiques et les \u00e9l\u00e9ments de donn\u00e9es calcul\u00e9s. Du c\u00f4t\u00e9 de la base de donn\u00e9es, il existe un certain cache pour les requ\u00eates principales, par exemple, pour les graphiques.<\/p>\n<p>La mise en cache du c\u00f4t\u00e9 du serveur Zabbix lui-m\u00eame est :<\/p>\n<ul>\n<li>ConfigurationCache;<\/li>\n<li>ValueCache;<\/li>\n<li>HistoryCache;<\/li>\n<li>TrendsCache.<\/li>\n<\/ul>\n<p>\nExaminons-les plus en d\u00e9tail.<\/p>\n<h3>ConfigurationCache<\/h3>\n<p>\nC'est le cache principal o\u00f9 nous stockons les m\u00e9triques, les h\u00f4tes, les \u00e9l\u00e9ments de donn\u00e9es, les d\u00e9clencheurs \u2014 tout ce qui est n\u00e9cessaire pour le pr\u00e9traitement et la collecte de donn\u00e9es.<\/p>\n<p><img decoding=\"async\" alt=\"Haute performance et partitionnement natif : Zabbix avec support de TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/122708198f6cd136fbd0420876c06e9c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTout cela est stock\u00e9 dans le ConfigurationCache pour \u00e9viter de cr\u00e9er des requ\u00eates excessives dans la base de donn\u00e9es. Apr\u00e8s le d\u00e9marrage du serveur, nous mettons \u00e0 jour ce cache, cr\u00e9ons et mettons p\u00e9riodiquement \u00e0 jour les configurations.<\/p>\n<h3>Collecte des donn\u00e9es<\/h3>\n<p>\nLe sch\u00e9ma est assez vaste, mais l'essentiel est <strong>les collecteurs<\/strong>. Ce sont diff\u00e9rents \u00ab pollers \u00bb \u2014 processus de collecte. Ils sont responsables de diff\u00e9rents types de collecte : ils collectent des donn\u00e9es via SNMP, IPMI, et transmettent tout cela au pr\u00e9traitement.<\/p>\n<p><img decoding=\"async\" alt=\"Haute performance et partitionnement natif : Zabbix avec support de TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/deff5d9ff358f1b04b505d18c7770f21.jpg\" style=\"display:block;margin: 0 auto;\" \/><em>Les collecteurs sont encercl\u00e9s par une ligne orange.<\/em><\/p>\n<p>Dans Zabbix, il existe des \u00e9l\u00e9ments de donn\u00e9es agr\u00e9g\u00e9s calcul\u00e9s qui sont n\u00e9cessaires pour agr\u00e9ger les v\u00e9rifications. Si nous les avons, nous r\u00e9cup\u00e9rons les donn\u00e9es pour eux directement depuis le ValueCache.<\/p>\n<h3>Pr\u00e9traitement HistoryCache<\/h3>\n<p>\nTous les collecteurs utilisent le ConfigurationCache pour obtenir des t\u00e2ches. Ensuite, ils les transmettent au pr\u00e9traitement.<\/p>\n<p><img decoding=\"async\" alt=\"Haute performance et partitionnement natif : Zabbix avec support de TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/116e25100ebdf9ed209a9b04fa6fa156.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLe pr\u00e9traitement utilise le ConfigurationCache pour obtenir les \u00e9tapes de pr\u00e9traitement. Il traite ces donn\u00e9es de diff\u00e9rentes mani\u00e8res.<\/p>\n<p>Apr\u00e8s le traitement des donn\u00e9es avec le pr\u00e9traitement, nous les sauvegardons dans le HistoryCache pour traitement. C'est la fin de la collecte de donn\u00e9es et nous passons au principal processus dans Zabbix \u2014 <strong>history syncer<\/strong>, car c'est une architecture monolithique.<\/p>\n<p><em>Remarque : le pr\u00e9traitement est une op\u00e9ration assez lourde. \u00c0 partir de la version 4.2, il a \u00e9t\u00e9 d\u00e9plac\u00e9 sur le proxy. Si vous avez un Zabbix tr\u00e8s volumineux avec un grand nombre d'\u00e9l\u00e9ments de donn\u00e9es et une fr\u00e9quence de collecte \u00e9lev\u00e9e, cela facilite consid\u00e9rablement le travail.<\/em><\/p>\n<h3>ValueCache, historique et cache des tendances<\/h3>\n<p><\/p>\n<blockquote><p>Le synchroniseur d'historique est le processus principal qui traite de mani\u00e8re atomique chaque \u00e9l\u00e9ment de donn\u00e9es, c'est-\u00e0-dire chaque valeur.<\/p><\/blockquote>\n<p>\nLe synchroniseur d'historique prend les valeurs du Cache d'historique et v\u00e9rifie s'il existe des d\u00e9clencheurs pour les calculs dans la Configuration. S'il y en a, il calcule.<\/p>\n<p>Le synchroniseur d'historique cr\u00e9e un \u00e9v\u00e9nement, une escalade, pour g\u00e9n\u00e9rer des alertes si n\u00e9cessaire selon la configuration, et les enregistre. S'il y a des d\u00e9clencheurs pour un traitement ult\u00e9rieur, alors il m\u00e9morise cette valeur dans le ValueCache, afin de ne pas se r\u00e9f\u00e9rer \u00e0 la table d\u2019historique. Ainsi, le ValueCache se remplit des donn\u00e9es n\u00e9cessaires pour le calcul des d\u00e9clencheurs et des \u00e9l\u00e9ments calcul\u00e9s.<\/p>\n<p>Le synchroniseur d'historique enregistre toutes les donn\u00e9es dans la base de donn\u00e9es, et celle-ci les envoie sur le disque. Le processus de traitement se termine ici.<\/p>\n<p><img decoding=\"async\" alt=\"Haute performance et partitionnement natif : Zabbix avec support de TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/4d74195381fda7756b0250982f6896be.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Mise en cache dans la base de donn\u00e9es<\/h3>\n<p>\nDu c\u00f4t\u00e9 de la base de donn\u00e9es, il existe diff\u00e9rents caches lorsque vous souhaitez voir des graphiques ou des rapports sur les \u00e9v\u00e9nements :<\/p>\n<ul>\n<li><code>Innodb_buffer_pool<\/code> du c\u00f4t\u00e9 de MySQL ;<\/li>\n<li><code>shared_buffers<\/code> du c\u00f4t\u00e9 de PostgreSQL ;<\/li>\n<li><code>effective_cache_size<\/code> du c\u00f4t\u00e9 d'Oracle ;<\/li>\n<li><code>shared_pool<\/code> du c\u00f4t\u00e9 de DB2.<\/li>\n<\/ul>\n<p>\nIl existe encore beaucoup d'autres caches, mais ce sont les principaux pour toutes les bases de donn\u00e9es. Ils permettent de garder en m\u00e9moire vive les donn\u00e9es souvent n\u00e9cessaires pour les requ\u00eates. Ils ont leurs propres technologies pour cela.<\/p>\n<h3>La performance de la base de donn\u00e9es est critique<\/h3>\n<p>\nLe serveur Zabbix collecte constamment des donn\u00e9es et les enregistre. Lors du red\u00e9marrage, il lit \u00e9galement l'historique pour remplir le ValueCache. Il utilise des scripts et des rapports <strong>Zabbix API<\/strong>, qui est construit sur la base de l'interface Web. L'API Zabbix interroge la base de donn\u00e9es et obtient les donn\u00e9es n\u00e9cessaires pour les graphiques, les rapports, les listes d'\u00e9v\u00e9nements et les probl\u00e8mes r\u00e9cents.<\/p>\n<p><img decoding=\"async\" alt=\"Haute performance et partitionnement natif : Zabbix avec support de TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/dd0efdc4e57c1197d448ce453012091e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPour la visualisation \u2014 <strong>Grafana<\/strong>. C'est une solution populaire parmi nos utilisateurs. Elle peut envoyer directement des requ\u00eates via l'API Zabbix \u00e0 la base de donn\u00e9es et cr\u00e9e une certaine concurrence pour l'obtention des donn\u00e9es. Par cons\u00e9quent, une configuration plus fine et de meilleure qualit\u00e9 de la base de donn\u00e9es est n\u00e9cessaire pour r\u00e9pondre \u00e0 la rapide d\u00e9livrance de r\u00e9sultats et au test.<\/p>\n<h2>Housekeeper<\/h2>\n<p>\nLe troisi\u00e8me appel de performance dans Zabbix est le nettoyage de l'historique par Housekeeper. Il respecte tous les param\u00e8tres \u2014 dans les \u00e9l\u00e9ments de donn\u00e9es, il est indiqu\u00e9 combien de temps conserver la dynamique des changements (tendances) en jours.<\/p>\n<p>Nous calculons TrendsCache \u00e0 la vol\u00e9e. Lorsque les donn\u00e9es arrivent, nous les agr\u00e9geons sur une heure et les enregistrons dans les tables pour la dynamique des changements de tendances.<\/p>\n<p>Le Housekeeper s'ex\u00e9cute et supprime des informations de la base de donn\u00e9es via des \u00ab selects \u00bb ordinaires. Ce n'est pas toujours efficace, comme le montrent les graphiques de performance des processus internes.<\/p>\n<p><img decoding=\"async\" alt=\"Haute performance et partitionnement natif : Zabbix avec support de TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/a3af1badd14b1092bc26e0b53845ae04.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLe graphique rouge montre que le synchroniseur d'historique est constamment occup\u00e9. Le graphique orange en haut repr\u00e9sente le Housekeeper, qui s'ex\u00e9cute en continu. Il attend que la base de donn\u00e9es supprime toutes les lignes qu'il a sp\u00e9cifi\u00e9es.<\/p>\n<p>Quand faut-il d\u00e9sactiver le Housekeeper ? Par exemple, s'il y a un \u00ab Item ID \u00bb et qu'il faut supprimer les 5 000 derni\u00e8res lignes sur une certaine p\u00e9riode. Bien s\u00fbr, cela se fait par index. Mais en g\u00e9n\u00e9ral, le dataset est tr\u00e8s volumineux, et la base de donn\u00e9es lit toujours depuis le disque et le charge en cache. Cela repr\u00e9sente toujours une op\u00e9ration tr\u00e8s co\u00fbteuse pour la base de donn\u00e9es et, selon la taille de la base, cela peut entra\u00eener des probl\u00e8mes de performance.<\/p>\n<p><img decoding=\"async\" alt=\"Haute performance et partitionnement natif : Zabbix avec support de TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/0778318b539fbe33318e8a7310f8a89b.jpg\" style=\"display:block;margin: 0 auto;\" \/> <\/p>\n<p>Le Housekeeper peut \u00eatre simplement d\u00e9sactiv\u00e9. Dans l'interface Web, il existe un param\u00e8tre dans \u00ab Administration g\u00e9n\u00e9rale \u00bb pour le Housekeeper. Nous d\u00e9sactivons le Housekeeping interne pour l'historique interne des tendances et il ne g\u00e8re plus cela.<\/p>\n<p>Le Housekeeper a \u00e9t\u00e9 d\u00e9sactiv\u00e9, les graphiques se sont stabilis\u00e9s - quels probl\u00e8mes pourraient survenir dans ce cas et que pourrait-il faire pour r\u00e9soudre le troisi\u00e8me appel de performance ?<\/p>\n<h2>Partitionnement - ou sectionnement<\/h2>\n<p>\nEn g\u00e9n\u00e9ral, le partitionnement est configur\u00e9 de diff\u00e9rentes mani\u00e8res sur chaque base de donn\u00e9es relationnelle que j'ai mentionn\u00e9e. Chacune a sa propre technologie, mais elles se ressemblent dans l'ensemble. La cr\u00e9ation d'une nouvelle partition entra\u00eene souvent certains probl\u00e8mes.<\/p>\n<p>En g\u00e9n\u00e9ral, les partitions sont configur\u00e9es en fonction de la \u00ab setup \u00bb - la quantit\u00e9 de donn\u00e9es g\u00e9n\u00e9r\u00e9es par jour. En r\u00e8gle g\u00e9n\u00e9rale, le partitionnement est \u00e9tabli sur une journ\u00e9e, c'est le minimum. Pour les tendances, une nouvelle partition est \u00e9tablie sur un mois.<\/p>\n<p>Les valeurs peuvent changer en cas de tr\u00e8s grande \u00ab setup \u00bb. Si la petite \u00ab setup \u00bb est de moins de 5 000 nvps (nouvelles valeurs par seconde), la moyenne est entre 5 000 et 25 000, tandis que la grande est au-dessus de 25 000 nvps. Ce sont de grandes et tr\u00e8s grandes installations qui n\u00e9cessitent un r\u00e9glage minutieux de la base de donn\u00e9es.<\/p>\n<p>Sur de tr\u00e8s grandes installations, un segment d'une journ\u00e9e peut ne pas \u00eatre optimal. J'ai vu des partitions sur MySQL d\u00e9passant 40 Go ou plus par jour. C'est un volume de donn\u00e9es tr\u00e8s \u00e9lev\u00e9 qui peut poser des probl\u00e8mes, et il doit \u00eatre r\u00e9duit.<\/p>\n<h3>Quels sont les avantages du partitionnement ?<\/h3>\n<p>\n<strong>Partitionnement des tables<\/strong>. Cela consiste souvent en des fichiers s\u00e9par\u00e9s sur le disque. Le plan de requ\u00eates choisit de mani\u00e8re plus optimale une partition. En g\u00e9n\u00e9ral, la partition est utilis\u00e9e par plage \u2014 c'est \u00e9galement vrai pour Zabbix. Nous utilisons ici un \u00abtimestamp\u00bb \u2014 le temps depuis le d\u00e9but de l'\u00e9poque. Ce sont des nombres ordinaires. Vous d\u00e9finissez le d\u00e9but et la fin de la journ\u00e9e \u2014 c'est la partition.<\/p>\n<p><strong>Suppression rapide<\/strong> \u2014 <code>SUPPRIMER<\/code>. Un fichier\/sous-table est s\u00e9lectionn\u00e9, plut\u00f4t qu'un \u00e9chantillon de lignes \u00e0 supprimer.<\/p>\n<p><strong>Acc\u00e9l\u00e8re consid\u00e9rablement la r\u00e9cup\u00e9ration des donn\u00e9es<\/strong> <code>SELECT<\/code> \u2014 utilise une ou plusieurs partitions, plut\u00f4t que toute la table. Si vous demandez des donn\u00e9es datant de deux jours, elles sont r\u00e9cup\u00e9r\u00e9es depuis la base de donn\u00e9es plus rapidement, car il suffit de charger en cache et de fournir un seul fichier, au lieu d'une grande table.<\/p>\n<p>Souvent, cela acc\u00e9l\u00e8re \u00e9galement de nombreuses bases de donn\u00e9es <code>INSERT<\/code> \u2014 les insertions dans la sous-table.<\/p>\n<h2>TimescaleDB<\/h2>\n<p>\nPour la version 4.2, nous avons examin\u00e9 TimescaleDB. C'est une extension pour PostgreSQL avec une interface native. L'extension fonctionne efficacement avec des donn\u00e9es de s\u00e9ries temporelles, tout en conservant les avantages des bases de donn\u00e9es relationnelles. TimescaleDB partitionne \u00e9galement automatiquement.<\/p>\n<p>Dans TimescaleDB, il existe le concept de <strong>hypertable<\/strong> (hypertable), que vous cr\u00e9ez. Elle contient des <strong>chunks<\/strong> \u2014 partitions. Les chunks sont des fragments de l'hypertable g\u00e9r\u00e9s automatiquement, qui n'affectent pas les autres fragments. Chaque chunk a sa propre plage temporelle.<\/p>\n<p><img decoding=\"async\" alt=\"Haute performance et partitionnement natif : Zabbix avec support de 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 fonctionne vraiment efficacement. Les d\u00e9veloppeurs de l'extension affirment qu'ils utilisent un algorithme de traitement des requ\u00eates plus appropri\u00e9, notamment pour les <code>inserts<\/code>. Lorsque les tailles des inserts de dataset augmentent, l'algorithme maintient des performances constantes.<\/p>\n<p><img decoding=\"async\" alt=\"Haute performance et partitionnement natif : Zabbix avec support de TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/52f042018180ffd2cb6a2cf4a3af603e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nApr\u00e8s 200 millions de lignes, PostgreSQL commence g\u00e9n\u00e9ralement \u00e0 fortement ralentir et perd en performance jusqu'\u00e0 0. TimescaleDB permet d'ins\u00e9rer des \u00abinserts\u00bb efficacement, quel que soit le volume de donn\u00e9es.<\/p>\n<h3>Installation<\/h3>\n<p>\nInstaller TimescaleDB est assez simple pour tous les paquets. Dans <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.timescale.com\/v1.3\/getting-started\">documentation<\/a><\/noindex> tout est d\u00e9crit en d\u00e9tail \u2014 cela d\u00e9pend des paquets officiels de PostgreSQL. TimescaleDB peut \u00e9galement \u00eatre construit et compil\u00e9 manuellement.<\/p>\n<p>Pour la base de donn\u00e9es Zabbix, il suffit d'activer l'extension :<\/p>\n<pre><code class=\"sql\">echo \"CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;\" | sudo -u postgres psql zabbix<\/code><\/pre>\n<p>\nVous activez l' <code>extension<\/code> et la cr\u00e9ez pour la base de donn\u00e9es Zabbix. La derni\u00e8re \u00e9tape consiste \u00e0 cr\u00e9er l'hypertable.<\/p>\n<h3>Migrez les tables d'historique vers TimescaleDB<\/h3>\n<p>\nIl existe une fonction sp\u00e9ciale pour cela <code>create_hypertable<\/code>:<\/p>\n<pre><code class=\"sql\">SELECT create_hypertable('history', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable('history_unit', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable('history_log', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable('history_text', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable('history_str', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable('trends', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable('trends_unit', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nUPDATE config SET db_extension='timescaledb', hk_history_global=1, hk_trends_global=1<\/code><\/pre>\n<p>\nLa fonction a trois param\u00e8tres. Le premier \u2014<strong> la table dans la base de donn\u00e9es<\/strong>, pour laquelle il faut cr\u00e9er une hypertable. Le deuxi\u00e8me \u2014 <strong>le champ<\/strong>, selon lequel il faut cr\u00e9er <code>chunk_time_interval<\/code> \u2014 l'intervalle des partitions de chunks \u00e0 utiliser. Dans mon cas, l'intervalle est d'un jour \u2014 86\u00a0400.<\/p>\n<p>Le troisi\u00e8me param\u00e8tre \u2014 <code><strong>migrer_donn\u00e9es<\/strong><\/code>. Si vous mettez <code>true<\/code>, toutes les donn\u00e9es actuelles sont transf\u00e9r\u00e9es dans les chunks d\u00e9j\u00e0 cr\u00e9\u00e9s. J'ai utilis\u00e9 <code>migrer_donn\u00e9es<\/code>. J'avais environ 1 To, ce qui a pris plus d'une heure. M\u00eame dans certains cas lors des tests, j'ai supprim\u00e9 les anciennes donn\u00e9es d'historique inutiles pour ne pas les transf\u00e9rer.<\/p>\n<p>La derni\u00e8re \u00e9tape \u2014\u00a0<code><strong>UPDATE<\/strong><\/code>: dans <code>db_extension<\/code> nous fixons <code>timescaledb<\/code>, afin que la base de donn\u00e9es comprenne qu'il existe cette extension. Zabbix l'active et utilise correctement la syntaxe et les requ\u00eates \u00e0 la base de donn\u00e9es \u2014 ces fonctionnalit\u00e9s n\u00e9cessaires pour TimescaleDB.<\/p>\n<h2>Configuration mat\u00e9rielle<\/h2>\n<p>\nJ'ai utilis\u00e9 deux serveurs. Le premier \u2014 <strong>machine VMware<\/strong>. Elle est assez petite : 20 processeurs Intel\u00ae Xeon\u00ae CPU E5-2630 v 4 @ 2.20GHz, 16 Go de RAM et un disque SSD de 200 Go.<\/p>\n<p>J'ai install\u00e9 PostgreSQL 10.8 dessus avec l'OS Debian 10.8-1.pgdg90+1 et un syst\u00e8me de fichiers xfs. J'ai fait les r\u00e9glages minimaux pour utiliser cette base de donn\u00e9es, except\u00e9 ce que Zabbix va utiliser lui-m\u00eame.<\/p>\n<p>Sur cette m\u00eame machine se trouvaient le serveur Zabbix, PostgreSQL et <strong>les agents de charge<\/strong>. J'avais 50 agents actifs qui utilisaient <code>LoadableModule<\/code>, afin de g\u00e9n\u00e9rer tr\u00e8s rapidement diff\u00e9rents r\u00e9sultats : chiffres, cha\u00eenes. Je remplissais la base avec une grande quantit\u00e9 de donn\u00e9es.<\/p>\n<p>Initialement, la configuration contenait <strong>5\u00a0000 \u00e9l\u00e9ments<\/strong> de donn\u00e9es par h\u00f4te. Presque chaque \u00e9l\u00e9ment contenait un d\u00e9clencheur, afin que cela ressemble \u00e0 de vraies installations. Dans certains cas, il y avait plus d'un d\u00e9clencheur. Pour un n\u0153ud du r\u00e9seau, il y avait <strong>3\u00a0000 \u00e0 7\u00a0000 d\u00e9clencheurs<\/strong>.<\/p>\n<p>L'intervalle de mise \u00e0 jour des \u00e9l\u00e9ments de donn\u00e9es \u2014 <strong>4 \u00e0 7 secondes<\/strong>J'ai r\u00e9gul\u00e9 la charge en utilisant non seulement 50 agents, mais j'en ai ajout\u00e9 d'autres. De plus, gr\u00e2ce aux \u00e9l\u00e9ments de donn\u00e9es dynamiques, j'ai ajust\u00e9 la charge et r\u00e9duit l'intervalle de mise \u00e0 jour \u00e0 4 secondes.<\/p>\n<h3>PostgreSQL. 35\u00a0000 nvps<\/h3>\n<p>\nMon premier lancement sur ce mat\u00e9riel s'est fait avec PostgreSQL pur \u2014 35 000 valeurs par seconde. Comme on peut le voir, l'insertion des donn\u00e9es prend des fractions de seconde \u2014 tout fonctionne bien et rapidement. La seule chose est que le disque SSD de 200 Go se remplit rapidement.<\/p>\n<p><img decoding=\"async\" alt=\"Haute performance et partitionnement natif : Zabbix avec support de TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/e84b2eb0f6fbbd902c5feab367c750ee.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVoici le tableau de bord standard de performance de Zabbix \u2014 serveurs.<\/p>\n<p><img decoding=\"async\" alt=\"Haute performance et partitionnement natif : Zabbix avec support de TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/c3afe021acf8e272813b8d8c2f82e762.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLe premier graphique bleu montre le nombre de valeurs par seconde. Le second graphique \u00e0 droite montre la charge des processus de collecte. Le troisi\u00e8me indique la charge des processus internes de collecte : history syncers et Housekeeper, qui a fonctionn\u00e9 ici pendant une dur\u00e9e suffisante.<\/p>\n<p>Le quatri\u00e8me graphique montre l'utilisation de HistoryCache. C'est une sorte de tampon avant l'insertion dans la base de donn\u00e9es. Le cinqui\u00e8me graphique vert indique l'utilisation de ValueCache, c'est-\u00e0-dire combien de hits de ValueCache pour les d\u00e9clencheurs \u2014 ce sont plusieurs milliers de valeurs par seconde.<\/p>\n<h3>PostgreSQL. 50\u00a0000 nvps<\/h3>\n<p>\nEnsuite, j'ai augment\u00e9 la charge \u00e0 50 000 valeurs par seconde sur ce m\u00eame mat\u00e9riel.<\/p>\n<p><img decoding=\"async\" alt=\"Haute performance et partitionnement natif : Zabbix avec support de TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/8f10944486d5502b57d36059382d551b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLors du chargement avec Housekeeper, l'insertion de 10 000 valeurs s'\u00e9crivait en 2 \u00e0 3 secondes.<\/p>\n<p><img decoding=\"async\" alt=\"Haute performance et partitionnement natif : Zabbix avec support de TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/5228c1735f0ee2da7f827093f3c7b1f9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Housekeeper commence d\u00e9j\u00e0 \u00e0 interf\u00e9rer avec le fonctionnement.<\/em><\/p>\n<p>D'apr\u00e8s le troisi\u00e8me graphique, on peut voir que, dans l'ensemble, la charge des trappeurs et des history syncers est encore \u00e0 60 %. Sur le quatri\u00e8me graphique, HistoryCache commence \u00e0 se remplir assez activement pendant le fonctionnement de Housekeeper. Il est rempli \u00e0 20 % \u2014 soit environ 0,5 Go.<\/p>\n<h3>PostgreSQL. 80\u00a0000 nvps<\/h3>\n<p>\nEnsuite, j'ai augment\u00e9 la charge \u00e0 80 000 valeurs par seconde. Cela repr\u00e9sente environ 400 000 \u00e9l\u00e9ments de donn\u00e9es et 280 000 d\u00e9clencheurs.<\/p>\n<p><img decoding=\"async\" alt=\"Haute performance et partitionnement natif : Zabbix avec support de TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/f6c6b0d6793f96523f7406e68f98c608.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>L'insertion avec la charge de trente history syncers est d\u00e9j\u00e0 suffisamment \u00e9lev\u00e9e.<\/em><\/p>\n<p>J'ai \u00e9galement augment\u00e9 divers param\u00e8tres : history syncers, caches.<\/p>\n<p><img decoding=\"async\" alt=\"Haute performance et partitionnement natif : Zabbix avec support de TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/6ca7edd76aea6fdec00a61a0a6dc34e5.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSur mon mat\u00e9riel, la charge des history syncers atteignait son maximum. HistoryCache s'est rapidement rempli de donn\u00e9es \u2014 des donn\u00e9es ont \u00e9t\u00e9 accumul\u00e9es dans le tampon pour traitement.<\/p>\n<p>Tout ce temps, j'ai surveill\u00e9 l'utilisation du processeur, de la m\u00e9moire vive et d'autres param\u00e8tres syst\u00e8me, et j'ai d\u00e9couvert que l'utilisation des disques \u00e9tait maximale.<\/p>\n<p><img decoding=\"async\" alt=\"Haute performance et partitionnement natif : Zabbix avec support de TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/e964a000156b561accd23b4e1644f4a8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJ'ai atteint l'utilisation <strong>des capacit\u00e9s maximales du disque<\/strong> sur ce mat\u00e9riel et cette machine virtuelle. Avec une telle intensit\u00e9, PostgreSQL a commenc\u00e9 \u00e0 vider les donn\u00e9es assez activement, et le disque n'\u00e9tait plus capable de fonctionner correctement pour les \u00e9critures et les lectures.<\/p>\n<h3>Deuxi\u00e8me serveur<\/h3>\n<p>\nJ'ai pris un autre serveur qui avait d\u00e9j\u00e0 48 processeurs et 128 Go de RAM. Je l'ai optimis\u00e9 en installant 60 history syncer, et j'ai obtenu des performances acceptables.<\/p>\n<p><img decoding=\"async\" alt=\"Haute performance et partitionnement natif : Zabbix avec support de TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/591fc759b336d5fb2091460036b136bf.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn fait, c'est d\u00e9j\u00e0 la limite de performance o\u00f9 il faut prendre des mesures.<\/p>\n<h3>TimescaleDB. 80 000 nvps<\/h3>\n<p>\nMon principal objectif est d'\u00e9valuer les capacit\u00e9s de TimescaleDB sous la charge de Zabbix. 80 000 valeurs par seconde, c'est beaucoup, surtout avec une fr\u00e9quence de collecte des m\u00e9triques (\u00e0 part Yandex, bien s\u00fbr) et un \u00ab setup \u00bb assez important.<\/p>\n<p><img decoding=\"async\" alt=\"Haute performance et partitionnement natif : Zabbix avec support de TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/aa569847e7bc31baab91661db1ee78a2.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSur chaque graphique, il y a un creux \u2014 c'est lors de la migration des donn\u00e9es. Apr\u00e8s ces creux, le profil de charge de history syncer sur le serveur Zabbix a \u00e9norm\u00e9ment chang\u00e9 \u2014 il a chut\u00e9 de trois fois.<\/p>\n<blockquote><p>TimescaleDB permet d'ins\u00e9rer des donn\u00e9es presque trois fois plus vite et d'utiliser moins d'HistoryCache.<\/p><\/blockquote>\n<p>\nEn cons\u00e9quence, les donn\u00e9es vous parviendront en temps opportun.<\/p>\n<h3>TimescaleDB. 120 000 nvps<\/h3>\n<p>\nEnsuite, j'ai augment\u00e9 le nombre d'\u00e9l\u00e9ments de donn\u00e9es \u00e0 500 000. Mon principal objectif \u00e9tait d'\u00e9valuer les capacit\u00e9s de TimescaleDB \u2014 j'ai obtenu une valeur estim\u00e9e de 125 000 valeurs par seconde.<\/p>\n<p><img decoding=\"async\" alt=\"Haute performance et partitionnement natif : Zabbix avec support de TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/4770ca4030e1c086f2fd9305a12496bb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nC'est un \u00ab setup \u00bb fonctionnel qui peut fonctionner longtemps. Mais comme mon disque n'\u00e9tait que de 1,5 To, je l'ai rempli en quelques jours.<\/p>\n<p><img decoding=\"async\" alt=\"Haute performance et partitionnement natif : Zabbix avec support de TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/1ad521b909a22a7db81a9ed802d348e7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLe plus important, c'est qu'en m\u00eame temps, de nouvelles partitions de TimescaleDB \u00e9taient cr\u00e9\u00e9es.<\/p>\n<p>Pour les performances, cela est compl\u00e8tement imperceptible. Lorsque des partitions sont cr\u00e9\u00e9es dans MySQL, par exemple, c'est tout autre chose. Cela se produit g\u00e9n\u00e9ralement la nuit, car cela bloque les insertions globales, les op\u00e9rations sur les tables et peut causer une d\u00e9gradation du service. Ce n'est pas le cas avec TimescaleDB.<\/p>\n<p>\u00c0 titre d'exemple, je vais montrer un graphique parmi de nombreux autres dans la communaut\u00e9. Sur l'image, TimescaleDB est activ\u00e9, ce qui a permis de r\u00e9duire la charge d'utilisation de io.weight sur le processeur. L'utilisation des \u00e9l\u00e9ments des processus internes a \u00e9galement diminu\u00e9. D'ailleurs, c'est une machine virtuelle classique sur des disques classiques, et non sur SSD.<\/p>\n<p><img decoding=\"async\" alt=\"Haute performance et partitionnement natif : Zabbix avec support de TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/bea0cd0f1448e1d1b3a5f979d51ce61c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Conclusions<\/h2>\n<p>\n<strong>TimescaleDB est une bonne solution pour de petits \u00ab setup \u00bb<\/strong>, qui sont limit\u00e9s par les performances du disque. Cela permettra de continuer \u00e0 bien fonctionner jusqu'\u00e0 ce que la base de donn\u00e9es soit migr\u00e9e sur un mat\u00e9riel plus rapide.<\/p>\n<p>TimescaleDB est facile \u00e0 configurer, offre un gain de performance, fonctionne bien avec Zabbix et <strong>pr\u00e9sente des avantages par rapport \u00e0 PostgreSQL.<\/strong>.<\/p>\n<p>Si vous utilisez PostgreSQL et que vous ne pr\u00e9voyez pas de le changer, je recommande <strong>d'utiliser PostgreSQL avec l'extension TimescaleDB en tandem avec Zabbix.<\/strong>Cette solution fonctionne efficacement jusqu'\u00e0 des \u00ab setup \u00bb moyens.<\/p>\n<blockquote>\n<p>Quand nous parlons de \u00ab haute performance \u00bb, nous faisons r\u00e9f\u00e9rence \u00e0 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\">HighLoad++<\/a><\/noindex>. Il ne reste plus longtemps \u00e0 attendre pour d\u00e9couvrir les technologies et pratiques permettant aux services de g\u00e9rer des millions d'utilisateurs. La liste <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\/abstracts\">des rapports<\/a><\/noindex> pour les 7 et 8 novembre est d\u00e9j\u00e0 \u00e9tablie, mais <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\/meetups\">les meetups<\/a><\/noindex> peuvent encore \u00eatre propos\u00e9s.<\/p>\n<p>Abonnez-vous \u00e0 notre <noindex><a rel=\"nofollow\" href=\"http:\/\/eepurl.com\/VYVaf\">newsletter<\/a><\/noindex> et <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/HighLoadChannel\">telegram<\/a><\/noindex>, o\u00f9 nous d\u00e9voilons des astuces pour la prochaine conf\u00e9rence, et d\u00e9couvrez comment en tirer le meilleur parti.<\/p>\n<\/blockquote>\n<p>Source : <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.2.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\/fr\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"fr_FR\" \/>\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\/fr\/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\udd47 Haute performance et partitionnement natif : Zabbix avec support de TimescaleDB | ProHoster","description":"Zabbix est un syst\u00e8me de surveillance.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","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\/fr\/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\/fr\/wp-json\/wp\/v2\/posts\/38927","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=38927"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/38927\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/29204"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=38927"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=38927"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=38927"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}