Nous verrons comment Zabbix fonctionne avec la base de données TimescaleDB comme backend. Nous allons vous montrer comment repartir de zéro et comment migrer depuis PostgreSQL. Nous fournirons également des tests de performances comparatifs des deux configurations.
HighLoad++ Sibérie 2019. Salle Tomsk. 24 juin, 16h00. Thèses et . La prochaine conférence HighLoad++ se tiendra les 6 et 7 avril 2020 à Saint-Pétersbourg. Détails et billets .
Andrey Gushchin (ci-après – AG) : – Je suis ingénieur du support technique ZABBIX (ci-après dénommé « Zabbix »), formateur. Je travaille dans le support technique depuis plus de 6 ans et j'ai une expérience directe de la performance. Aujourd'hui, je vais parler des performances que TimescaleDB peut fournir par rapport à PostgreSQL 10 standard. En outre, une partie introductive sur son fonctionnement en général.
Principaux défis de productivité : de la collecte de données au nettoyage des données
Pour commencer, chaque système de surveillance est confronté à certains défis de performances. Le premier défi de productivité est la collecte et le traitement rapides des données.
Un bon système de surveillance doit recevoir rapidement et en temps opportun toutes les données, les traiter selon des expressions de déclenchement, c'est-à-dire les traiter selon certains critères (cela est différent selon les systèmes) et les enregistrer dans une base de données afin d'utiliser ces données dans le avenir.
Le deuxième défi en termes de performances est le stockage de l’historique. Stockez souvent dans une base de données et accédez rapidement et facilement à ces mesures qui ont été collectées sur une période donnée. Le plus important est que ces données soient faciles à obtenir, à utiliser dans des rapports, des graphiques, des déclencheurs, dans certaines valeurs seuils, pour des alertes, etc.
Le troisième défi en termes de performances est l'effacement de l'historique, c'est-à-dire lorsque vous arrivez au point où vous n'avez plus besoin de stocker de mesures détaillées collectées sur 5 ans (même des mois ou deux mois). Certains nœuds du réseau ont été supprimés, ou certains hôtes, les métriques ne sont plus nécessaires car elles sont déjà obsolètes et ne sont plus collectées. Tout cela doit être nettoyé afin que votre base de données ne devienne pas trop volumineuse. En général, l'effacement de l'historique constitue le plus souvent un test sérieux pour le stockage - il a souvent un impact très important sur les performances.
Comment résoudre les problèmes de mise en cache ?
Je vais maintenant parler spécifiquement de Zabbix. Dans Zabbix, les premier et deuxième appels sont résolus à l'aide de la mise en cache.
Collecte et traitement des données - Nous utilisons la RAM pour stocker toutes ces données. Ces données seront maintenant discutées plus en détail.
Du côté de la base de données, il existe également une mise en cache pour les sélections principales - pour les graphiques et autres choses.
Mise en cache du côté du serveur Zabbix lui-même : nous avons ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Ce que c'est?
ConfigurationCache est le cache principal dans lequel nous stockons les métriques, les hôtes, les éléments de données et les déclencheurs ; tout ce dont vous avez besoin pour traiter le prétraitement, collecter des données, à partir de quels hôtes collecter, à quelle fréquence. Tout cela est stocké dans ConfigurationCache afin de ne pas accéder à la base de données et créer des requêtes inutiles. Après le démarrage du serveur, nous mettons à jour ce cache (le créons) et le mettons à jour périodiquement (en fonction des paramètres de configuration).
Mise en cache dans Zabbix. Collecte de données
Ici, le diagramme est assez grand :
Les principaux acteurs du projet sont les collecteurs suivants :
Ce sont les processus d'assemblage eux-mêmes, divers « pollers » qui sont responsables de différents types d'assemblages. Ils collectent des données via icmp, ipmi et divers protocoles et les transfèrent au prétraitement.
Prétraitement HistoryCache
De plus, si nous avons des éléments de données calculés (ceux qui connaissent Zabbix le savent), c'est-à-dire des éléments de données calculés et agrégés, nous les récupérons directement de ValueCache. Je vous dirai comment il est rempli plus tard. Tous ces collecteurs utilisent ConfigurationCache pour recevoir leurs tâches et les transmettent ensuite au prétraitement.
Le prétraitement utilise également ConfigurationCache pour obtenir les étapes de prétraitement et traite ces données de différentes manières. À partir de la version 4.2, nous l'avons déplacé vers un proxy. C'est très pratique, car le prétraitement lui-même est une opération assez difficile. Et si vous disposez d'un très grand Zabbix, avec un grand nombre d'éléments de données et une fréquence de collecte élevée, cela simplifie grandement le travail.
En conséquence, après avoir traité ces données d'une manière ou d'une autre à l'aide du prétraitement, nous les enregistrons dans HistoryCache afin de les traiter davantage. Ceci conclut la collecte de données. Nous passons au processus principal.
Travail du synchroniseur d'histoire
Le processus principal de Zabbix (puisqu'il s'agit d'une architecture monolithique) est le synchroniseur d'histoire. Il s’agit du processus principal qui s’occupe spécifiquement du traitement atomique de chaque élément de données, c’est-à-dire de chaque valeur :
- la valeur vient (elle la prend dans HistoryCache) ;
- vérifie dans le synchroniseur de configuration : s'il existe des déclencheurs pour le calcul - les calcule ;
s'il y en a - crée des événements, crée une escalade afin de créer une alerte, si nécessaire selon la configuration ; - enregistre les déclencheurs pour le traitement ultérieur, l'agrégation ; si vous agrégez sur la dernière heure et ainsi de suite, cette valeur est mémorisée par ValueCache afin de ne pas aller dans la table historique ; Ainsi, le ValueCache est rempli des données nécessaires au calcul des déclencheurs, des éléments calculés, etc. ;
- puis le synchroniseur d'historique écrit toutes les données dans la base de données ;
- la base de données les écrit sur le disque - c'est là que se termine le processus de traitement.
Base de données. Mise en cache
Côté base de données, lorsque l'on souhaite visualiser des graphiques ou certains rapports sur des événements, il existe différents caches. Mais dans ce rapport, je n'en parlerai pas.
Pour MySQL, il existe Innodb_buffer_pool et de nombreux caches différents qui peuvent également être configurés.
Mais voici les principaux :
- shared_buffers ;
- effective_cache_size ;
- piscine commune.
Pour toutes les bases de données, j'ai dit qu'il existe certains caches qui permettent de stocker dans la RAM les données souvent nécessaires aux requêtes. Ils disposent de leurs propres technologies pour cela.
À propos des performances de la base de données
En conséquence, il existe un environnement concurrentiel, c'est-à-dire que le serveur Zabbix collecte des données et les enregistre. Au redémarrage, il lit également l'historique pour remplir le ValueCache, etc. Ici, vous pouvez avoir des scripts et des rapports qui utilisent l'API Zabbix, qui est construite sur une interface Web. L'API Zabbix entre dans la base de données et reçoit les données nécessaires pour obtenir des graphiques, des rapports ou une sorte de liste d'événements, de problèmes récents.
Grafana est également une solution de visualisation très populaire, que nos utilisateurs utilisent. Capable de se connecter directement à la fois via l'API Zabbix et via la base de données. Cela crée également une certaine concurrence pour l'obtention des données : un réglage plus fin et meilleur de la base de données est nécessaire pour garantir une livraison rapide des résultats et des tests.
Effacement de l'historique. Zabbix a une femme de ménage
Le troisième appel utilisé dans Zabbix consiste à effacer l'historique à l'aide de Housekeeper. Housekeeper suit tous les paramètres, c'est-à-dire que nos éléments de données indiquent la durée de stockage (en jours), la durée de stockage des tendances et la dynamique des changements.
Je n'ai pas parlé du TrendCache, qu'on calcule à la volée : les données arrivent, on les agrège sur une heure (ce sont surtout des chiffres pour la dernière heure), le montant est moyen/minimum et on l'enregistre une fois par heure dans le tableau de la dynamique des changements (« Tendances ») . « Housekeeper » démarre et supprime les données de la base de données à l'aide de sélections régulières, ce qui n'est pas toujours efficace.
Comment comprendre que c’est inefficace ? Vous pouvez voir l'image suivante sur les graphiques de performances des processus internes :
Votre synchroniseur d'historique est constamment occupé (graphique rouge). Et le graphique « rouge » qui va en haut. Il s'agit d'une « Housekeeper » qui démarre et attend que la base de données supprime toutes les lignes qu'elle a spécifiées.
Prenons un identifiant d'article : vous devez supprimer les 5 XNUMX derniers ; bien sûr, par index. Mais généralement, l'ensemble de données est assez volumineux - la base de données le lit toujours à partir du disque et le place dans le cache, ce qui constitue une opération très coûteuse pour la base de données. En fonction de sa taille, cela peut entraîner certains problèmes de performances.
Vous pouvez désactiver Housekeeper de manière simple : nous avons une interface Web familière. Dans les paramètres d'administration générale (paramètres pour « Gouvernante »), nous désactivons la gestion interne de l'historique et des tendances internes. Par conséquent, Housekeeper ne contrôle plus ceci :
Que pouvez-vous faire ensuite ? Vous l'avez éteint, vos graphiques se sont stabilisés... Quels autres problèmes pourraient survenir dans ce cas ? Qu'est-ce qui peut aider ?
Partitionnement (sectionnement)
Généralement, cela est configuré de manière différente sur chaque base de données relationnelle que j'ai répertoriée. MySQL possède sa propre technologie. Mais dans l’ensemble, ils sont très similaires entre PostgreSQL 10 et MySQL. Bien sûr, il existe de nombreuses différences internes dans la manière dont tout cela est mis en œuvre et dans la manière dont tout cela affecte les performances. Mais en général, la création d’une nouvelle partition entraîne souvent aussi certains problèmes.
En fonction de votre configuration (quantité de données que vous créez en une journée), ils fixent généralement le minimum - c'est 1 jour / lot, et pour les « tendances », la dynamique des changements - 1 mois / nouveau lot. Cela peut changer si vous disposez d’une très grande configuration.
Parlons tout de suite de la taille de la configuration : jusqu'à 5 5 nouvelles valeurs par seconde (appelées nvps) - cela sera considéré comme une petite « configuration ». Moyenne – de 25 à XNUMX mille valeurs par seconde. Tout ce qui précède, ce sont déjà des installations de grande et très grande taille qui nécessitent une configuration très minutieuse de la base de données.
Sur les très grandes installations, 1 jour peut ne pas être optimal. J'ai personnellement vu des partitions sur MySQL de 40 gigaoctets par jour (et il y en a peut-être plus). Il s’agit d’une très grande quantité de données, ce qui peut entraîner certains problèmes. Il faut le réduire.
Pourquoi avez-vous besoin d'un partitionnement ?
Ce que propose le partitionnement, je pense que tout le monde le sait, c'est le partitionnement des tables. Il s'agit souvent de fichiers distincts sur le disque et de requêtes span. Il sélectionne une partition de manière plus optimale si elle fait partie du partitionnement normal.
Pour Zabbix, en particulier, il est utilisé par plage, par plage, c'est-à-dire que nous utilisons un horodatage (un nombre régulier, l'heure depuis le début de l'époque). Vous spécifiez le début/la fin de la journée, et c'est la partition. Par conséquent, si vous demandez des données datant de deux jours, tout est récupéré plus rapidement de la base de données, car il vous suffit de charger un fichier dans le cache et de le renvoyer (plutôt qu'une grande table).
De nombreuses bases de données accélèrent également l'insertion (insertion dans une table enfant). Je parle de manière abstraite pour l'instant, mais c'est aussi possible. Le partitionnement est souvent utile.
ElasticSearch pour NoSQL
Récemment, en 3.4, nous avons implémenté une solution NoSQL. Ajout de la possibilité d'écrire dans Elasticsearch. Vous pouvez écrire certains types : vous choisissez - soit d'écrire des chiffres, soit des signes ; nous avons du texte de chaîne, vous pouvez écrire des journaux dans Elasticsearch... En conséquence, l'interface Web accédera également à Elasticsearch. Cela fonctionne très bien dans certains cas, mais pour le moment, cela peut être utilisé.
Échelle de tempsDB. Hypertables
Pour la version 4.4.2, nous avons prêté attention à une chose comme TimescaleDB. Ce que c'est? Il s'agit d'une extension pour PostgreSQL, c'est-à-dire qu'elle possède une interface PostgreSQL native. De plus, cette extension vous permet de travailler beaucoup plus efficacement avec les données de séries temporelles et de bénéficier d'un partitionnement automatique. À quoi il ressemble:
C'est hypertable - il existe un tel concept dans Timescale. Il s'agit d'une hypertable que vous créez et qui contient des morceaux. Les morceaux sont des partitions, ce sont des tables enfants, si je ne me trompe pas. C'est vraiment efficace.
TimescaleDB et PostgreSQL
Comme l'assurent les fabricants de TimescaleDB, ils utilisent un algorithme plus correct pour traiter les requêtes, notamment les insertions, ce qui leur permet d'avoir des performances approximativement constantes avec une taille croissante de l'insertion de l'ensemble de données. Autrement dit, après 200 millions de lignes Postgres, la ligne habituelle commence à s'affaisser considérablement et perd littéralement ses performances jusqu'à zéro, tandis que Timescale vous permet d'insérer des insertions aussi efficacement que possible avec n'importe quelle quantité de données.
Comment installer TimescaleDB ? C'est simple!
C'est dans la documentation, c'est décrit - vous pouvez l'installer à partir de packages pour n'importe quel... Cela dépend des packages officiels de Postgres. Peut être compilé manuellement. Il se trouve que j'ai dû compiler pour la base de données.
Sur Zabbix, nous activons simplement l'extension. Je pense que ceux qui ont utilisé Extention dans Postgres... Vous activez simplement Extention, créez-la pour la base de données Zabbix que vous utilisez.
Et la dernière étape...
Échelle de tempsDB. Migration des tables d'historique
Vous devez créer une hypertable. Il existe une fonction spéciale pour cela – Créer une hypertable. Dans celui-ci, le premier paramètre est la table nécessaire dans cette base de données (pour laquelle vous devez créer une hypertable).
Le champ par lequel créer, et chunk_time_interval (il s'agit de l'intervalle de morceaux (partitions qui doivent être utilisées). 86 400 correspond à un jour.
Paramètre Migrate_data : si vous insérez sur true, cela migrera toutes les données actuelles vers des morceaux pré-créés.
J'ai moi-même utilisé migrate_data - cela prend beaucoup de temps, selon la taille de votre base de données. J'avais plus d'un téraoctet - la création a pris plus d'une heure. Dans certains cas, lors des tests, j'ai supprimé les données historiques du texte (history_text) et de la chaîne (history_str) afin de ne pas les transférer - elles ne m'intéressaient pas vraiment.
Et on fait la dernière mise à jour dans notre db_extention : on installe timescaledb pour que la base de données et, en particulier, notre Zabbix comprenne qu'il y a db_extention. Il l'active et utilise la syntaxe et les requêtes correctes sur la base de données, en utilisant les « fonctionnalités » nécessaires à TimescaleDB.
Configuration du serveur
J'ai utilisé deux serveurs. Le premier serveur est une machine virtuelle assez petite, 20 processeurs, 16 Go de RAM. J'ai configuré Postgres 10.8 dessus :
Le système d'exploitation était Debian, le système de fichiers était xfs. J'ai effectué des réglages minimaux pour utiliser cette base de données particulière, moins ce que Zabbix lui-même utilisera. Sur la même machine se trouvaient un serveur Zabbix, PostgreSQL et des agents de chargement.
J'ai utilisé 50 agents actifs qui utilisent LoadableModule pour générer rapidement différents résultats. Ce sont eux qui ont généré les chaînes, les nombres, etc. J'ai rempli la base de données avec beaucoup de données. Initialement, la configuration contenait 5 XNUMX éléments de données par hôte, et environ chaque élément de données contenait un déclencheur - pour qu'il s'agisse d'une véritable configuration. Parfois, vous avez même besoin de plusieurs déclencheurs à utiliser.
J'ai régulé l'intervalle de mise à jour et la charge elle-même en utilisant non seulement 50 agents (en ajoutant davantage), mais également en utilisant des éléments de données dynamiques et en réduisant l'intervalle de mise à jour à 4 secondes.
Test de performance. PostgreSQL : 36 XNUMX NVP
Le premier lancement, la première configuration que j'ai eue était sur PostreSQL 10 pur sur ce matériel (35 200 valeurs par seconde). En général, comme vous pouvez le voir sur l'écran, l'insertion de données prend quelques fractions de seconde - tout va bien et rapidement, disques SSD (20 gigaoctets). Le seul problème est que XNUMX Go se remplissent assez rapidement.
Il y aura beaucoup de tels graphiques dans le futur. Il s'agit d'un tableau de bord standard des performances du serveur Zabbix.
Le premier graphique est le nombre de valeurs par seconde (bleu, en haut à gauche), 35 mille valeurs dans ce cas. Ceci (en haut au centre) est le chargement des processus de construction, et ceci (en haut à droite) est le chargement des processus internes : les synchroniseurs d'historique et la femme de ménage, qui ici (en bas au centre) fonctionnent depuis un certain temps.
Ce graphique (en bas au centre) montre l'utilisation de ValueCache - combien d'accès ValueCache pour les déclencheurs (plusieurs milliers de valeurs par seconde). Un autre graphique important est le quatrième (en bas à gauche), qui montre l'utilisation de HistoryCache, dont j'ai parlé, qui est un tampon avant insertion dans la base de données.
Test de performance. PostgreSQL : 50 XNUMX NVP
Ensuite, j'ai augmenté la charge à 50 10 valeurs par seconde sur le même matériel. Lors du chargement par Housekeeper, 2 3 valeurs ont été enregistrées en XNUMX-XNUMX secondes avec calcul. Ce qui est en fait montré dans la capture d'écran suivante :
La « femme de ménage » commence déjà à interférer avec le travail, mais en général, la charge sur les trappeurs historiques est toujours au niveau de 60 % (troisième graphique, en haut à droite). HistoryCache commence déjà à se remplir activement pendant l'exécution de Housekeeper (en bas à gauche). C'était environ un demi-gigaoctet, rempli à 20 %.
Test de performance. PostgreSQL : 80 XNUMX NVP
Ensuite, je l'ai augmenté à 80 XNUMX valeurs par seconde :
Il s'agissait d'environ 400 280 éléments de données, 30 XNUMX déclencheurs. L'insert, comme vous pouvez le constater, en termes de charge de plombs historiques (il y en avait XNUMX) était déjà assez élevé. Ensuite, j'ai augmenté divers paramètres : les plombs d'historique, le cache... Sur ce matériel, la charge sur les plombs d'historique a commencé à augmenter jusqu'à un maximum, presque « sur l'étagère » - en conséquence, HistoryCache est passé à une charge très élevée :
Pendant tout ce temps, j'ai surveillé tous les paramètres du système (comment le processeur est utilisé, la RAM) et j'ai découvert que l'utilisation du disque était maximale - j'ai atteint la capacité maximale de ce disque sur ce matériel, sur cette machine virtuelle. "Postgres" a commencé à vider les données assez activement avec une telle intensité, et le disque n'avait plus le temps d'écrire, de lire...
J'ai pris un autre serveur qui avait déjà 48 processeurs et 128 Go de RAM :
Je l'ai également « réglé » - j'ai installé le synchroniseur d'historique (60 pièces) et j'ai obtenu des performances acceptables. En fait, nous ne sommes pas « sur le plateau », mais c’est probablement la limite de la productivité, là où il faut déjà faire quelque chose.
Test de performance. TimescaleDB : 80 XNUMX NVP
Ma tâche principale était d'utiliser TimescaleDB. Chaque graphique montre une baisse :
Ces échecs sont précisément la migration des données. Après cela, sur le serveur Zabbix, le profil de chargement des plombs d'historique, comme vous pouvez le constater, a beaucoup changé. Il vous permet d'insérer des données presque 3 fois plus rapidement et d'utiliser moins de HistoryCache - en conséquence, vous recevrez les données à temps. Encore une fois, 80 XNUMX valeurs par seconde est un taux assez élevé (bien sûr, pas pour Yandex). Dans l'ensemble, il s'agit d'une configuration assez importante, avec un seul serveur.
Test de performances PostgreSQL : 120 XNUMX NVP
Ensuite, j'ai augmenté la valeur du nombre d'éléments de données à un demi-million et j'ai reçu une valeur calculée de 125 XNUMX par seconde :
Et j'ai ces graphiques :
En principe, il s'agit d'une configuration fonctionnelle, elle peut fonctionner assez longtemps. Mais comme je n'avais qu'un disque de 1,5 téraoctet, je l'ai utilisé en quelques jours. Le plus important est qu'en même temps de nouvelles partitions ont été créées sur TimescaleDB, et cela est passé complètement inaperçu en termes de performances, ce qui ne peut pas être dit de MySQL.
Généralement, les partitions sont créées la nuit, car cela bloque généralement l'insertion et le travail avec les tables et peut conduire à une dégradation du service. Dans ce cas, ce n'est pas le cas ! La tâche principale était de tester les capacités de TimescaleDB. Le résultat fut le chiffre suivant : 120 XNUMX valeurs par seconde.
Il existe également des exemples dans la communauté :
La personne a également activé TimescaleDB et la charge d'utilisation de io.weight a été réduite sur le processeur ; et l'utilisation d'éléments de processus internes a également diminué en raison de l'inclusion de TimescaleDB. De plus, ce sont des disques pancake ordinaires, c'est-à-dire une machine virtuelle ordinaire sur des disques ordinaires (pas des SSD) !
Pour certaines petites configurations limitées par les performances du disque, TimescaleDB est, à mon avis, une très bonne solution. Cela vous permettra de continuer à travailler avant de migrer vers un matériel plus rapide pour la base de données.
Je vous invite tous à nos événements : Conférence à Moscou, Sommet à Riga. Utilisez nos chaînes - Telegram, forum, IRC. Si vous avez des questions, venez à notre bureau, nous pouvons parler de tout.
Questions du public
Question du public (ci-après - A) : - Si TimescaleDB est si facile à configurer et qu'il donne une telle amélioration des performances, alors peut-être que cela devrait être utilisé comme meilleure pratique pour configurer Zabbix avec Postgres ? Et y a-t-il des pièges et des inconvénients à cette solution, ou après tout, si je décide de créer Zabbix pour moi-même, je peux facilement prendre Postgres, y installer Timescale tout de suite, l'utiliser et ne penser à aucun problème ?
AG : – Oui, je dirais que c'est une bonne recommandation : utilisez Postgres immédiatement avec l'extension TimescaleDB. Comme je l'ai déjà dit, il y a beaucoup de bonnes critiques, malgré le fait que cette « fonctionnalité » soit expérimentale. Mais effectivement les tests montrent que c'est une excellente solution (avec TimescaleDB) et je pense qu'elle va évoluer ! Nous surveillons le développement de cette extension et apporterons les modifications nécessaires.
Même pendant le développement, nous nous sommes appuyés sur l'une de leurs « fonctionnalités » bien connues : il était possible de travailler avec des morceaux un peu différemment. Mais ils l'ont ensuite supprimé dans la version suivante et nous avons dû arrêter de nous fier à ce code. Je recommanderais d'utiliser cette solution sur de nombreuses configurations. Si vous utilisez MySQL... Pour les configurations moyennes, n'importe quelle solution fonctionne bien.
Un: – Sur les derniers graphiques de la communauté, il y avait un graphique avec « Housekeeper » :
Il a continué à travailler. Que fait Housekeeper avec TimescaleDB ?
AG : – Maintenant, je ne peux pas le dire avec certitude – je vais regarder le code et vous le dirai plus en détail. Il utilise les requêtes TimescaleDB non pas pour supprimer des morceaux, mais pour les agréger d'une manière ou d'une autre. Je ne suis pas encore prêt à répondre à cette question technique. Nous en saurons plus sur le stand aujourd'hui ou demain.
Un: – J'ai une question similaire – sur les performances de l'opération de suppression dans Timescale.
A (réponse du public) : – Lorsque vous supprimez des données d'une table, si vous le faites via delete, vous devez alors parcourir la table - supprimer, nettoyer, tout marquer pour un futur vide. Dans Timescale, puisque vous avez des morceaux, vous pouvez les supprimer. En gros, vous dites simplement au fichier qui se trouve dans le big data : « Supprimer ! »
Timescale comprend simplement qu'un tel morceau n'existe plus. Et comme il est intégré au planificateur de requêtes, il utilise des hooks pour capturer vos conditions dans des opérations de sélection ou autres et comprend immédiatement que ce morceau n'existe plus - "Je n'y irai plus !" (Données non disponibles). C'est tout! Autrement dit, une analyse de table est remplacée par une suppression de fichier binaire, donc c'est rapide.
Un: – Nous avons déjà abordé le sujet du non-SQL. D'après ce que je comprends, Zabbix n'a pas vraiment besoin de modifier les données, et tout cela ressemble à un journal. Est-il possible d'utiliser des bases de données spécialisées qui ne peuvent pas modifier leurs données, mais qui en même temps enregistrent, accumulent et distribuent beaucoup plus rapidement - Clickhouse, par exemple, quelque chose de similaire à Kafka ?.. Kafka est aussi un journal ! Est-il possible de les intégrer d’une manière ou d’une autre ?
AG : - Le déchargement peut être effectué. Nous avons une certaine « fonctionnalité » depuis la version 3.4 : vous pouvez écrire tous les fichiers historiques, les événements, tout le reste dans des fichiers ; puis envoyez-le à n'importe quelle autre base de données à l'aide d'un gestionnaire. En fait, de nombreuses personnes retravaillent et écrivent directement dans la base de données. À la volée, les plombiers de l'histoire écrivent tout cela dans des fichiers, font pivoter ces fichiers, etc., et vous pouvez transférer cela vers Clickhouse. Je ne peux pas parler de projets, mais peut-être que la prise en charge des solutions NoSQL (telles que Clickhouse) se poursuivra.
Un: – En général, il s'avère que vous pouvez complètement vous débarrasser de postgres ?
AG : – Bien sûr, la partie la plus difficile de Zabbix, ce sont les tableaux historiques, qui créent le plus de problèmes et d’événements. Dans ce cas, si vous ne stockez pas les événements pendant une longue période et stockez l'historique avec les tendances dans un autre stockage rapide, alors en général, je pense, il n'y aura aucun problème.
Un: – Pouvez-vous estimer à quelle vitesse tout fonctionnera si vous passez à Clickhouse, par exemple ?
AG : – Je ne l'ai pas testé. Je pense qu’au moins les mêmes chiffres peuvent être obtenus tout simplement, étant donné que Clickhouse a sa propre interface, mais je ne peux pas le dire avec certitude. Il vaut mieux tester. Tout dépend de la configuration : du nombre d’hôtes dont vous disposez, etc. L'insertion est une chose, mais vous devez également récupérer ces données - Grafana ou autre chose.
Un: – Nous parlons donc d’un combat égal, et non du grand avantage de ces bases de données rapides ?
AG : – Je pense que lorsque nous intégrerons, il y aura des tests plus précis.
Un: – Où est passé ce bon vieux RRD ? Qu’est-ce qui vous a poussé à migrer vers les bases de données SQL ? Initialement, toutes les mesures étaient collectées sur RRD.
AG : – Zabbix avait RRD, peut-être dans une version très ancienne. Il y a toujours eu des bases de données SQL – une approche classique. L'approche classique est MySQL, PostgreSQL (ils existent depuis très longtemps). Nous n'avons presque jamais utilisé d'interface commune pour les bases de données SQL et RRD.
Quelques publicités 🙂
Merci de rester avec nous. Vous aimez nos articles ? Vous voulez voir du contenu plus intéressant ? Soutenez-nous en passant une commande ou en recommandant à vos amis, , un analogue unique des serveurs d'entrée de gamme, que nous avons inventé pour vous : (disponible avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).
Dell R730xd 2 fois moins cher dans le centre de données Equinix Tier IV à Amsterdam ? Ici seulement aux Pays-Bas! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99$ ! En savoir plus
Source: habr.com