Zabbix est un système de surveillance. Comme tout autre système, il est confronté à trois problèmes principaux de tous les systèmes de surveillance : la collecte et le traitement des données, le stockage de l'historique et son effacement.
Les étapes de réception, de traitement et d'enregistrement des données prennent du temps. Pas beaucoup, mais pour un grand système, cela peut entraîner des retards importants. Le problème de stockage est une question d'accès aux données. Ils sont utilisés pour les rapports, les contrôles et les déclencheurs. Les retards d'accès aux données affectent également les performances. Lorsque la base de données grandit, les données non pertinentes doivent être supprimées. La suppression est une opération lourde qui consomme également certaines ressources.
Les problèmes de délai de collecte et de stockage dans Zabbix sont résolus par la mise en cache : plusieurs types de caches, mise en cache dans la base de données. Pour résoudre le troisième problème, la mise en cache n'est pas adaptée, donc TimescaleDB a été utilisé dans Zabbix. Je vais en parler Andrey Gushchin - Ingénieur du Support Technique . Andrey soutient Zabbix depuis plus de 6 ans et est directement impliqué dans la performance.
Comment TimescaleDB fonctionne-t-il, quelles performances peut-il offrir par rapport à PostgreSQL standard ? Quel rôle Zabbix joue-t-il dans TimescaleDB ? Comment démarrer à partir de zéro et comment migrer depuis PostgreSQL et quelle performance de configuration est la meilleure ? Tout cela sous la coupe.
Défis de performances
Chaque système de surveillance fait face à certains défis de performance. J'aborderai trois d'entre eux : la collecte et le traitement des données, le stockage, le nettoyage de l'historique.
Collecte et traitement rapides des données. Un bon système de surveillance doit recevoir rapidement toutes les données et les traiter selon des expressions de déclenchement - selon ses propres critères. Après traitement, le système doit également stocker rapidement ces données dans la base de données afin de les utiliser ultérieurement.
Stockage de l'historique. Un bon système de surveillance doit stocker l'historique dans une base de données et fournir un accès facile aux métriques. L'historique doit être utilisé dans les rapports, les graphiques, les déclencheurs, les seuils et les éléments d'alerte calculés.
Effacement de l'historique. Parfois, il arrive un jour où vous n'avez plus besoin de stocker des métriques. Pourquoi avez-vous besoin de données qui ont été collectées il y a 5 ans, un mois ou deux : certains nœuds ont été supprimés, certains hôtes ou métriques ne sont plus nécessaires, car ils sont obsolètes et ne sont plus collectés. Un bon système de surveillance doit stocker les données historiques et les supprimer de temps en temps afin que la base de données ne grossisse pas.
Le nettoyage des données obsolètes est un problème épineux qui a un impact important sur les performances de la base de données.
Mise en cache dans Zabbix
Dans Zabbix, les premier et deuxième appels sont résolus à l'aide de la mise en cache. La RAM est utilisée pour collecter et traiter les données. Pour le stockage - historique dans les déclencheurs, les graphiques et les éléments calculés. Du côté de la base de données, il existe une mise en cache pour les sélections de base, telles que les graphiques.
La mise en cache du côté du serveur Zabbix lui-même est :
- ConfigurationCache ;
- ValueCache ;
- HistoryCache ;
- TrendsCache.
Laissez-nous les examiner plus en détail.
Cache de configuration
C'est le cache principal dans lequel nous stockons les métriques, les hôtes, les éléments de données, les déclencheurs - tout ce qui est nécessaire pour le prétraitement et la collecte de données.
Tout cela est stocké dans le ConfigurationCache afin de ne pas créer de requêtes inutiles dans la base de données. Après le démarrage du serveur, nous mettons à jour ce cache, créons et mettons à jour périodiquement les configurations.
Collecte de données
Le schéma est assez vaste, mais l'essentiel est collectionneurs. Ce sont divers "pollers" - processus d'assemblage. Ils sont responsables de différents types d'assemblage : ils collectent les données via SNMP, IPMI, et transfèrent le tout au PreProcessing.
Les cueilleurs sont entourés d'orange.
Zabbix a calculé les éléments d'agrégation nécessaires pour agréger les vérifications. Si nous en avons, nous prenons les données pour eux directement à partir du ValueCache.
Prétraitement HistoryCache
Tous les collecteurs utilisent le ConfigurationCache pour recevoir des travaux. Ensuite, ils les transmettent au prétraitement.
Le prétraitement utilise ConfigurationCache pour obtenir les étapes de prétraitement. Il traite ces données de différentes manières.
Après avoir traité les données avec PreProcessing, nous les stockons dans HistoryCache pour les traiter. Ceci termine la collecte de données et nous passons au processus principal dans Zabbix - synchroniseur d'historique, car il s'agit d'une architecture monolithique.
Remarque : Le prétraitement est une opération assez lourde. Depuis la v 4.2, il a été déplacé vers un proxy. Si vous avez un très grand Zabbix avec un grand nombre d'éléments et une fréquence de collecte, cela rend les choses beaucoup plus faciles.
ValueCache, cache historique et tendances
Le synchroniseur d'historique est le processus principal qui traite de manière atomique chaque élément de données, c'est-à-dire chaque valeur.
Le synchroniseur d'historique prend les valeurs de HistoryCache et vérifie la configuration pour les déclencheurs de calculs. S'ils sont - calcule.
Le synchroniseur d'historique crée un événement, l'escalade pour créer des alertes si la configuration l'exige et enregistre. S'il existe des déclencheurs pour un traitement ultérieur, il mémorise cette valeur dans ValueCache afin de ne pas se référer à la table d'historique. C'est ainsi que le ValueCache est rempli avec les données nécessaires pour calculer les déclencheurs, les éléments calculés.
Le synchroniseur d'historique écrit toutes les données dans la base de données et écrit sur le disque. Le processus de traitement se termine ici.
Mise en cache de la base de données
Il existe différents caches du côté de la base de données lorsque vous souhaitez consulter des graphiques ou des rapports d'événements :
Innodb_buffer_poolcôté MySQL ;shared_buffersdu côté PostgreSQL ;effective_cache_sizedu côté de l'Oracle ;shared_poolcôté DB2.
Il existe de nombreux autres caches, mais ce sont les principaux pour toutes les bases de données. Ils vous permettent de conserver les données dans la RAM qui sont souvent nécessaires pour les requêtes. Ils ont leur propre technologie pour cela.
Les performances de la base de données sont essentielles
Le serveur Zabbix collecte constamment des données et les écrit. Une fois redémarré, il lit également l'historique pour remplir le ValueCache. Utilisations des scripts et des rapports API Zabbix, qui est construit sur la base de l'interface Web. L'API Zabbix accède à la base de données et récupère les données nécessaires pour les graphiques, les rapports, les listes d'événements et les problèmes récents.
Pour la visualisation - grafana. C'est une solution populaire parmi nos utilisateurs. Elle peut envoyer directement des requêtes via l'API Zabbix et à la base de données, et crée une certaine simultanéité pour l'obtention des données. Par conséquent, un réglage plus fin et meilleur de la base de données est nécessaire pour correspondre à la livraison rapide des résultats et des tests.
Gouvernante
Le troisième défi de performance dans Zabbix est le nettoyage de l'historique avec Housekeeper. Il respecte tous les paramètres - les éléments de données indiquent combien de temps stocker la dynamique des changements (tendances) en jours.
TrendsCache nous calculons à la volée. Lorsque les données arrivent, nous les agrégeons en une heure et les mettons dans des tableaux pour la dynamique des changements de tendance.
Housekeeper démarre et supprime des informations de la base de données avec les "sélections" habituelles. Ce n'est pas toujours efficace, ce que l'on peut comprendre à partir des graphiques de performance des processus internes.
Le graphique rouge indique que le synchroniseur d'historique est constamment occupé. Le graphique orange en haut est Housekeeper, qui est constamment en cours d'exécution. Il attend que la base de données supprime toutes les lignes qu'elle a spécifiées.
Quand désactiver Housekeeper ? Par exemple, il y a un "ID d'article" et vous devez supprimer les 5 XNUMX dernières lignes dans un certain temps. Bien sûr, cela se produit par index. Mais généralement, l'ensemble de données est très volumineux et la base de données lit toujours à partir du disque et le place dans le cache. Cette opération est toujours très coûteuse pour la base de données et, selon la taille de la base de données, peut entraîner des problèmes de performances.
La femme de ménage est simple à désactiver. Dans l'interface Web, il existe un paramètre dans « Général d'administration » pour la femme de ménage. Désactivez le nettoyage interne pour l'historique des tendances internes et il ne le contrôle plus.
La femme de ménage a été désactivée, les graphismes se sont stabilisés - quels pourraient être les problèmes dans ce cas et qu'est-ce qui peut aider à résoudre le troisième défi de performance ?
Partitionnement - partitionnement ou partitionnement
Le partitionnement est généralement configuré de manière différente sur chaque base de données relationnelle que j'ai répertoriée. Chacun a sa propre technologie, mais ils sont similaires, en général. La création d'une nouvelle partition entraîne souvent certains problèmes.
Les partitions sont généralement configurées en fonction de la "configuration" - la quantité de données créées en une journée. En règle générale, le partitionnement se met en place en une journée, c'est le minimum. Pour les nouvelles tendances de partition — 1 mois.
Les valeurs peuvent changer dans le cas d'un "setup" très important. Si une petite "configuration" est jusqu'à 5 000 nvps (nouvelles valeurs par seconde), une moyenne est de 5 000 à 25 000, puis une grande est supérieure à 25 000 nvps. Ce sont de grandes et très grandes installations qui nécessitent une configuration minutieuse de la base de données elle-même.
Sur de très grandes installations, une journée peut ne pas être optimale. J'ai vu des partitions MySQL de 40 Go ou plus par jour. Il s'agit d'une très grande quantité de données qui peut entraîner des problèmes et doit être réduite.
Qu'est-ce que le partitionnement ?
Tables de partitionnement. Il s'agit souvent de fichiers séparés sur le disque. Le plan de requête sélectionne une partition de manière plus optimale. Habituellement, le partitionnement est utilisé par plage - cela est également vrai pour Zabbix. Nous y utilisons "horodatage" - le temps écoulé depuis le début de l'époque. Nous avons des numéros réguliers. Vous définissez le début et la fin de la journée - c'est une partition.
Retrait rapide - DELETE. Un fichier/sous-table est sélectionné, et non une sélection de lignes à supprimer.
Accélère considérablement l'échantillonnage des données SELECT - utilise une ou plusieurs partitions, pas la table entière. Si vous accédez à des données datant de deux jours, il les extrait plus rapidement de la base de données car vous n'avez qu'à les charger dans le cache et à renvoyer un seul fichier, pas une grande table.
Souvent, de nombreuses bases de données accélèrent également INSERT - insère dans la table enfant.
Échelle de tempsDB
Pour la v 4.2, nous avons porté notre attention sur TimescaleDB. Il s'agit d'une extension PostgreSQL avec une interface native. L'extension fonctionne efficacement avec des données de séries chronologiques sans perdre les avantages des bases de données relationnelles. TimescaleDB partitionne également automatiquement.
TimescaleDB a un concept hypertable (hypertable) que vous créez. En elle sont morceaux - cloisons. Les blocs sont des fragments gérés automatiquement d'une hypertable qui n'affectent pas les autres fragments. Chaque morceau a sa propre plage de temps.
TimescaleDB contre PostgreSQL
TimescaleDB est vraiment efficace. Les producteurs de l'extension affirment utiliser un algorithme de traitement des requêtes plus correct, en particulier inserts . Au fur et à mesure que la taille de l'insert d'ensemble de données augmente, l'algorithme maintient des performances constantes.
Après 200 millions de lignes, PostgreSQL commence généralement à s'affaisser beaucoup et à perdre des performances à 0. TimescaleDB vous permet d'insérer efficacement des "inserts" avec n'importe quelle quantité de données.
Installation
L'installation de TimescaleDB est assez simple pour tous les packages. DANS tout est détaillé - cela dépend des packages PostgreSQL officiels. TimescaleDB peut également être construit et compilé à la main.
Pour la base de données Zabbix, nous activons simplement l'extension :
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
vous activez extension et créez-le pour la base de données Zabbix. La dernière étape consiste à créer une hypertable.
Migration des tables d'historique vers TimescaleDB
Il existe une fonction spéciale pour cela. create_hypertable:
SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1
La fonction a trois paramètres. D'abord - table dans la base de donnéesLe pour lequel vous souhaitez créer une hypertable. Deuxième - terrain, selon lequel il faut créer chunk_time_interval — intervalle de morceaux de partition à utiliser. Dans mon cas, l'intervalle est d'un jour - 86 400.
Le troisième paramètre est migrate_data. Si défini true, toutes les données actuelles sont transférées vers des morceaux pré-créés. J'ai moi-même utilisé migrate_data. J'avais environ 1 To qui a pris plus d'une heure. Même dans certains cas, lors des tests, j'ai supprimé les données historiques des types de caractères, qui sont facultatives pour le stockage, afin de ne pas les transférer.
Dernière étape - UPDATE: dans db_extension mettre timescaledbafin que la base de données comprenne qu'il existe cette extension. Zabbix l'active et utilise correctement la syntaxe et les requêtes déjà adressées à la base de données - les fonctionnalités nécessaires à TimescaleDB.
Configuration matérielle
J'ai utilisé deux serveurs. D'abord - Machine VMware. Il est assez petit : 20 processeurs Intel® Xeon® E5-2630 v 4 à 2.20 GHz, 16 Go de RAM et un disque SSD de 200 Go.
J'y ai installé PostgreSQL 10.8 avec Debian OS 10.8-1.pgdg90+1 et le système de fichiers xfs. J'ai tout configuré au minimum pour utiliser cette base de données particulière, moins ce que Zabbix lui-même utilisera.
Sur la même machine, il y avait un serveur Zabbix, PostgreSQL et charger des agents. J'avais 50 agents actifs qui utilisaient LoadableModulepour générer très rapidement divers résultats : nombres, chaînes. J'ai rempli la base de données avec beaucoup de données.
Initialement, la configuration contenait 5 000 articles données par hôte. Presque chaque élément contenait un déclencheur pour le faire ressembler à de véritables installations. Dans certains cas, il y avait plus d'un déclencheur. Un nœud de réseau avait 3 000 à 7 000 déclencheurs.
Intervalle de mise à jour de l'article − secondes 4-7. J'ai régulé la charge elle-même en utilisant non seulement 50 agents, mais en ajoutant plus. De plus, à l'aide d'éléments de données, j'ai régulé dynamiquement la charge et réduit l'intervalle de mise à jour à 4 s.
PostgreSQL. 35 000 nvps
Ma première exécution sur ce matériel était sur PostgreSQL pur - 35 200 valeurs par seconde. Comme vous pouvez le voir, l'insertion de données prend des fractions de seconde - tout va bien et rapidement. La seule chose est que le disque SSD de XNUMX Go se remplit rapidement.
Il s'agit d'un tableau de bord standard des performances du serveur Zabbix.
Le premier graphique bleu est le nombre de valeurs par seconde. Le deuxième graphique à droite est le chargement des processus de génération. Le troisième est le chargement des processus de construction internes : les synchroniseurs d'historique et Housekeeper, qui fonctionne depuis un certain temps ici.
Le quatrième graphique montre l'utilisation de HistoryCache. C'est une sorte de tampon avant insertion dans la base de données. Le cinquième graphique vert montre l'utilisation de ValueCache, c'est-à-dire que le nombre de hits ValueCache pour les déclencheurs est de plusieurs milliers de valeurs par seconde.
PostgreSQL. 50 000 nvps
Ensuite, j'ai augmenté la charge à 50 XNUMX valeurs par seconde sur le même matériel.
Lors du chargement à partir de Housekeeper, l'insertion de 10 2 valeurs a pris 3 à XNUMX secondes.
La gouvernante commence déjà à gêner.
Le troisième graphique montre qu'en général, la charge des trappeurs et des synchroniseurs d'historique est toujours au niveau de 60 %. Sur le quatrième graphique, l'HistoryCache pendant le fonctionnement de Housekeeper commence déjà à se remplir assez activement. Il est plein à 20 % - environ 0,5 Go.
PostgreSQL. 80 000 nvps
Ensuite, j'ai augmenté la charge à 80 400 valeurs par seconde. Cela représente environ 280 XNUMX éléments de données et XNUMX XNUMX déclencheurs.
L'insert de chargement d'une trentaine de synchroniseurs d'historique est déjà assez élevé.
J'ai également augmenté divers paramètres : synchroniseurs d'historique, caches.
Sur mon matériel, le chargement des synchroniseurs d'historique a augmenté au maximum. HistoryCache s'est rapidement rempli de données - le tampon a accumulé des données à traiter.
Pendant tout ce temps, j'ai observé comment le processeur, la RAM et d'autres paramètres système étaient utilisés, et j'ai constaté que l'utilisation du disque était maximale.
j'ai fait usage de capacité maximale du disque sur ce matériel et sur cette machine virtuelle. Avec une telle intensité, PostgreSQL a commencé à vider les données assez activement, et le disque n'avait plus le temps d'écrire et de lire.
Deuxième serveur
J'ai pris un autre serveur qui avait déjà 48 processeurs et 128 Go de RAM. Je l'ai réglé - j'ai défini 60 synchroniseurs d'historique et j'ai obtenu des performances acceptables.
En fait, c'est déjà une limite de performance où quelque chose doit être fait.
chronométréb. 80 000 nvps
Ma tâche principale est de tester les capacités de TimescaleDB par rapport à une charge Zabbix. 80 XNUMX valeurs par seconde, c'est beaucoup, la fréquence de collecte des métriques (sauf pour Yandex, bien sûr) et une "configuration" assez importante.
Il y a une baisse sur chaque graphique - il s'agit simplement d'une migration de données. Après les pannes du serveur Zabbix, le profil de chargement du synchroniseur d'historique a beaucoup changé - il est tombé trois fois.
TimescaleDB vous permet d'insérer des données presque 3 fois plus rapidement et d'utiliser moins HistoryCache.
En conséquence, vous recevrez des données en temps opportun.
chronométréb. 120 000 nvps
Ensuite, j'ai augmenté le nombre d'éléments de données à 500 125. La tâche principale consistait à vérifier les capacités de TimescaleDB - j'ai obtenu une valeur calculée de XNUMX XNUMX valeurs par seconde.
Il s'agit d'une "configuration" de travail qui peut prendre beaucoup de temps à fonctionner. Mais comme mon disque ne faisait que 1,5 To, je l'ai rempli en quelques jours.
Plus important encore, de nouvelles partitions TimescaleDB étaient créées en même temps.
Pour les performances, c'est complètement imperceptible. Lorsque des partitions sont créées dans MySQL, par exemple, les choses sont différentes. Cela se produit généralement la nuit, car cela bloque l'insertion générale, la manipulation des tables et peut créer une dégradation du service. Ce n'est pas le cas avec TimescaleDB.
Par exemple, je vais montrer un graphique de l'ensemble de la communauté. Dans l'image, TimescaleDB est activé, grâce à quoi la charge sur l'utilisation de io.weight sur le processeur a diminué. L'utilisation d'éléments de processus internes a également diminué. De plus, il s'agit d'une machine virtuelle ordinaire sur des disques de crêpes ordinaires, et non d'un SSD.
résultats
TimescaleDB est une bonne solution pour les petites "configurations", qui reposent sur les performances du disque. Cela vous permettra de continuer à bien travailler jusqu'à ce que la base de données soit migrée vers le matériel plus rapidement.
TimescaleDB est facile à configurer, améliore les performances, fonctionne bien avec Zabbix et a des avantages par rapport à PostgreSQL.
Si vous utilisez PostgreSQL et que vous ne prévoyez pas de le changer, je vous recommande utiliser PostgreSQL avec l'extension TimescaleDB en conjonction avec Zabbix. Cette solution fonctionne efficacement jusqu'à une "configuration" moyenne.
Nous disons "haute performance" - nous voulons dire . Vous ne tarderez pas à découvrir les technologies et les pratiques qui permettent aux services de servir des millions d'utilisateurs. Liste pour les 7 et 8 novembre, nous avons déjà établi, mais plus peut être suggéré.
Abonnez-vous à notre и , dans lequel nous révélons les caractéristiques de la prochaine conférence et découvrons comment en tirer le meilleur parti.
Source: habr.com