La prochaine conférence HighLoad++ aura lieu les 6 et 7 avril 2020 à Saint-Pétersbourg. Détails et billets . HighLoad++ Moscou 2018. Salle « Moscou ». 9 novembre, 15h00. Thèses et .
* Surveillance - en ligne et analytique.
* Limitations de base de la plateforme ZABBIX.
* Solution pour faire évoluer le stockage analytique.
* Optimisation du serveur ZABBIX.
* Optimisation de l'interface utilisateur.
* Expérience d'exploitation du système sous des charges de plus de 40 XNUMX NVPS.
* Brèves conclusions.
Mikhaïl Makurov (ci-après – MM) : - Salut tout le monde!
Maxim Chernetsov (ci-après – MCH) : - Bon après-midi!
MM : – Laissez-moi vous présenter Maxime. Max est un ingénieur talentueux, le meilleur réseauteur que je connaisse. Maxim intervient dans les réseaux et services, leur développement et leur exploitation.
L'HME : – Et je voudrais te parler de Mikhail. Mikhail est un développeur C. Il a écrit plusieurs solutions de traitement du trafic à forte charge pour notre entreprise. Nous vivons et travaillons dans l'Oural, dans la ville des hommes durs de Chelyabinsk, dans la société Intersvyaz. Notre société est un fournisseur de services Internet et de télévision par câble pour un million de personnes dans 16 villes.
MM : – Et il faut dire qu’Intersvyaz est bien plus qu’un simple fournisseur, c’est une société informatique. La plupart de nos solutions sont réalisées par notre service informatique.
Un: des serveurs traitant le trafic au centre d'appels et à l'application mobile. Le service informatique compte aujourd’hui environ 80 personnes aux compétences très très diverses.
À propos de Zabbix et de son architecture
L'HME : – Et maintenant, je vais essayer d'établir un record personnel et de dire en une minute ce qu'est Zabbix (ci-après dénommé « Zabbix »).
Zabbix se positionne comme un système de surveillance prêt à l'emploi au niveau de l'entreprise. Il possède de nombreuses fonctionnalités qui facilitent la vie : règles d'escalade avancées, API d'intégration, regroupement et détection automatique des hôtes et des métriques. Zabbix dispose de ce qu'on appelle des outils de mise à l'échelle - des proxys. Zabbix est un système open source.
En bref sur l'architecture. On peut dire qu'il se compose de trois éléments :
- Serveur. Écrit en C. Avec un traitement et un transfert d'informations assez complexes entre les threads. Tous les traitements y ont lieu : de la réception à l'enregistrement dans la base de données.
- Toutes les données sont stockées dans la base de données. Zabbix prend en charge MySQL, PostreSQL et Oracle.
- L'interface Web est écrite en PHP. Sur la plupart des systèmes, il est livré avec un serveur Apache, mais fonctionne plus efficacement en combinaison avec nginx + php.
Aujourd'hui, nous aimerions raconter une histoire de la vie de notre entreprise liée à Zabbix...
Une histoire de la vie de la société Intersvyaz. Qu’avons-nous et de quoi avons-nous besoin ?
Il y a 5 ou 6 mois. Un jour après le travail...
L'HME : - Micha, bonjour ! Je suis content d'avoir réussi à vous attraper - il y a une conversation. Nous avons encore eu des problèmes de surveillance. Lors d'un accident majeur, tout allait au ralenti et il n'y avait aucune information sur l'état du réseau. Malheureusement, ce n’est pas la première fois que cela se produit. J'ai besoin de votre aide. Faisons en sorte que notre veille fonctionne en toutes circonstances !
MM : - Mais synchronisons d'abord. Je n'y ai pas regardé depuis quelques années. Pour autant que je me souvienne, nous avons abandonné Nagios et sommes passés à Zabbix il y a environ 8 ans. Et maintenant, nous semblons avoir 6 serveurs puissants et environ une douzaine de proxys. Est-ce que je confond quelque chose ?
L'HME : - Presque. 15 serveurs, dont certains sont des machines virtuelles. Le plus important est que cela ne nous sauve pas au moment où nous en avons le plus besoin. Comme un accident : les serveurs ralentissent et vous ne voyez rien. Nous avons essayé d'optimiser la configuration, mais cela n'a pas permis une augmentation optimale des performances.
MM : - Il est clair. Avez-vous regardé quelque chose, avez-vous déjà déterré quelque chose dans les diagnostics ?
L'HME : – La première chose à laquelle vous devez vous occuper est la base de données. MySQL est constamment chargé, stockant de nouvelles métriques, et lorsque Zabbix commence à générer un tas d'événements, la base de données passe à la vitesse supérieure pendant littéralement quelques heures. Je vous ai déjà parlé de l'optimisation de la configuration, mais littéralement cette année, ils ont mis à jour le matériel : les serveurs disposent de plus d'une centaine de gigaoctets de mémoire et de baies de disques sur des RAID SSD - cela n'a aucun sens de le développer de manière linéaire sur le long terme. Qu'est-ce qu'on fait?
MM : - Il est clair. En général, MySQL est une base de données LTP. Apparemment, il n'est plus adapté au stockage d'archives de métriques de notre taille. Voyons cela.
L'HME : - Allons !
Intégration de Zabbix et Clickhouse à la suite du hackathon
Après un certain temps, nous avons reçu des données intéressantes :
La majeure partie de l'espace de notre base de données était occupée par les archives de métriques et moins de 1 % était utilisé pour la configuration, les modèles et les paramètres. À cette époque, nous exploitions la solution Big data basée sur Clickhouse depuis plus d’un an. La direction du mouvement nous était évidente. Lors de notre Hackathon du printemps, j'ai écrit l'intégration de Zabbix avec Clickhouse pour le serveur et le frontend. À cette époque, Zabbix prenait déjà en charge ElasticSearch et nous avons décidé de les comparer.
Comparaison de Clickhouse et Elasticsearch
MM : – À titre de comparaison, nous avons généré la même charge que celle fournie par le serveur Zabbix et examiné comment les systèmes se comporteraient. Nous avons écrit les données par lots de 1000 XNUMX lignes, en utilisant CURL. Nous avons supposé à l'avance que Clickhouse serait plus efficace pour le profil de charge que Zabbix propose. Les résultats ont même dépassé nos attentes :
Dans les mêmes conditions de test, Clickhouse a écrit trois fois plus de données. Dans le même temps, les deux systèmes consommaient très efficacement (une petite quantité de ressources) lors de la lecture des données. Mais Elastics nécessitait une grande quantité de processeur lors de l'enregistrement :
Au total, Clickhouse était nettement supérieur à Elastix en termes de consommation et de vitesse du processeur. Dans le même temps, grâce à la compression des données, Clickhouse utilise 11 fois moins de disque dur et effectue environ 30 fois moins d'opérations sur le disque :
L'HME : – Oui, le travail de Clickhouse avec le sous-système de disque est mis en œuvre de manière très efficace. Vous pouvez utiliser d'énormes disques SATA pour les bases de données et obtenir des vitesses d'écriture de plusieurs centaines de milliers de lignes par seconde. Le système prêt à l'emploi prend en charge le partitionnement, la réplication et est très facile à configurer. Nous sommes plus que satisfaits de son utilisation tout au long de l'année.
Pour optimiser les ressources, vous pouvez installer Clickhouse à côté de votre base de données principale existante et ainsi économiser beaucoup de temps CPU et d'opérations disque. Nous avons déplacé l'archive des métriques vers les clusters Clickhouse existants :
Nous avons tellement soulagé la base de données MySQL principale que nous avons pu la combiner sur une seule machine avec le serveur Zabbix et abandonner le serveur dédié à MySQL.
Comment fonctionnent les sondages dans Zabbix ?
il y a 4 mois
MM : – Eh bien, pouvons-nous oublier les problèmes avec la base ?
L'HME : - Ça c'est sûr! Un autre problème que nous devons résoudre est la lenteur de la collecte de données. Désormais, nos 15 serveurs proxy sont surchargés de processus SNMP et d'interrogation. Et il n'y a d'autre moyen que d'installer de nouveaux et nouveaux serveurs.
MM : - Super. Mais d’abord, dites-nous comment fonctionnent les sondages dans Zabbix ?
L'HME : – Bref, il existe 20 types de métriques et une douzaine de façons de les obtenir. Zabbix peut collecter des données soit en mode « requête-réponse », soit attendre de nouvelles données via « l'interface Trapper ».
Il convient de noter que dans le Zabbix original, cette méthode (Trapper) est la plus rapide.
Il existe des serveurs proxy pour la répartition de la charge :
Les proxys peuvent exécuter les mêmes fonctions de collecte que le serveur Zabbix, en recevant des tâches et en envoyant les métriques collectées via l'interface Trapper. C'est la manière officiellement recommandée de répartir la charge. Les proxys sont également utiles pour surveiller une infrastructure distante fonctionnant via NAT ou un canal lent :
MM : – Tout est clair avec l’architecture. Il faut regarder les sources...
Quelques jours plus tard
L'histoire de la victoire de nmap fping
MM : "Je pense que j'ai déterré quelque chose."
L'HME : - Dites-moi!
MM : – J'ai découvert que lors de la vérification de la disponibilité, Zabbix vérifie un maximum de 128 hôtes à la fois. J'ai essayé d'augmenter ce nombre à 500 et de supprimer l'intervalle inter-paquets dans leur ping (ping) - cela a doublé les performances. Mais j'aimerais des chiffres plus grands.
L'HME : – Dans ma pratique, je dois parfois vérifier la disponibilité de milliers d'hôtes, et je n'ai jamais rien vu de plus rapide que nmap pour cela. Je suis sûr que c'est le moyen le plus rapide. Essayons! Nous devons augmenter considérablement le nombre d'hôtes par itération.
MM : – Vérifiez plus de cinq cents ? 600 ?
L'HME : - Au moins quelques milliers.
MM : - D'ACCORD. La chose la plus importante que je voulais dire est que j'ai constaté que la plupart des sondages dans Zabbix se font de manière synchrone. Nous devons absolument le changer en mode asynchrone. Nous pouvons alors augmenter considérablement le nombre de métriques collectées par les sondeurs, surtout si nous augmentons le nombre de métriques par itération.
L'HME : - Super! Et quand?
MM : – Comme d'habitude, hier.
L'HME : – Nous avons comparé les deux versions de fping et nmap :
Sur un grand nombre d'hôtes, nmap devait être jusqu'à cinq fois plus efficace. Étant donné que nmap vérifie uniquement la disponibilité et le temps de réponse, nous avons déplacé le calcul des pertes vers les déclencheurs et réduit considérablement les intervalles de vérification de disponibilité. Nous avons trouvé que le nombre optimal d'hôtes pour nmap était d'environ 4 120 par itération. Nmap nous a permis de réduire de trois fois le coût CPU des contrôles de disponibilité et de réduire l'intervalle de 10 secondes à XNUMX.
Optimisation des sondages
MM : « Ensuite, nous avons commencé à faire des sondages. Nous nous sommes principalement intéressés à la détection et aux agents SNMP. Dans Zabbix, les sondages sont effectués de manière synchrone et des mesures spéciales ont été prises pour augmenter l'efficacité du système. En mode synchrone, l'indisponibilité de l'hôte entraîne une dégradation significative des interrogations. Il existe tout un système d'états, il existe des processus spéciaux - les soi-disant pollers inaccessibles, qui ne fonctionnent qu'avec des hôtes inaccessibles :
C'est un commentaire qui démontre la matrice étatique, toute la complexité du système de transitions nécessaires pour que le système reste efficace. De plus, l'interrogation synchrone elle-même est assez lente :
C'est pourquoi des milliers de flux d'interrogation sur des dizaines de proxys n'ont pas pu collecter la quantité de données requise pour nous. L'implémentation asynchrone a non seulement résolu les problèmes liés au nombre de threads, mais a également simplifié considérablement le système d'état des hôtes indisponibles, car pour tout nombre vérifié au cours d'une itération d'interrogation, le temps d'attente maximum était de 1 délai d'attente :
De plus, nous avons modifié et amélioré le système d'interrogation pour les requêtes SNMP. Le fait est que la plupart des gens ne peuvent pas répondre à plusieurs requêtes SNMP en même temps. Par conséquent, nous avons créé un mode hybride, lorsque l'interrogation SNMP du même hôte est effectuée de manière asynchrone :
Ceci est fait pour l’ensemble du pack d’hôtes. Ce mode n'est finalement pas plus lent qu'un mode complètement asynchrone, puisque l'interrogation d'une centaine et demie de valeurs SNMP est toujours beaucoup plus rapide qu'un timeout.
Nos expériences ont montré que le nombre optimal de requêtes en une itération est d'environ 8 200 avec l'interrogation SNMP. Au total, le passage au mode asynchrone nous a permis d'accélérer les performances d'interrogation de XNUMX fois, plusieurs centaines de fois.
L'HME : – Les optimisations d'interrogation qui en ont résulté ont montré que nous pouvons non seulement nous débarrasser de tous les proxys, mais également réduire les intervalles de nombreuses vérifications, et que les proxys ne seront plus nécessaires pour partager la charge.
Il y a environ trois mois
Changez l'architecture - augmentez la charge !
MM : - Eh bien, Max, est-il temps d'être productif ? J'ai besoin d'un serveur puissant et d'un bon ingénieur.
L'HME : - D'accord, planifions ça. Il est grand temps de sortir du point mort des 5 XNUMX métriques par seconde.
Le matin après la mise à jour
L'HME : - Misha, nous nous sommes mis à jour, mais le matin, nous avons reculé... Devinez quelle vitesse nous avons réussi à atteindre ?
MM : – 20 mille maximum.
L'HME : - Ouais, 25 ! Malheureusement, nous sommes exactement là où nous avons commencé.
MM : - Pourquoi? Avez-vous effectué des diagnostics ?
L'HME : - Oui bien sûr! Voici par exemple un top intéressant :
MM : - Regardons. Je vois que nous avons essayé un grand nombre de fils de sondage :
Mais en même temps, ils n’ont pas pu recycler le système, même de moitié :
Et les performances globales sont assez faibles, environ 4 XNUMX métriques par seconde :
Y a-t-il autre chose?
L'HME : – Oui, strace d’un des sondeurs :
MM : – Ici, vous pouvez clairement voir que le processus de sondage attend des « sémaphores ». Voici les serrures :
L'HME : - Pas clair.
MM : – Écoutez, cela ressemble à une situation dans laquelle un groupe de threads essaie de travailler avec des ressources avec lesquelles un seul peut travailler à la fois. Ensuite, tout ce qu’ils peuvent faire, c’est partager cette ressource au fil du temps :
Et les performances totales de travail avec une telle ressource sont limitées par la vitesse d'un cœur :
Il existe deux manières de résoudre ce problème.
Mettez à niveau le matériel de la machine, passez à des cœurs plus rapides :
Ou changez l'architecture et en même temps changez la charge :
L'HME : – D'ailleurs, sur la machine de test nous utiliserons moins de cœurs que sur celle de combat, mais ils sont 1,5 fois plus rapides en fréquence par cœur !
MM : - Clair? Vous devez regarder le code du serveur.
Chemin des données dans le serveur Zabbix
L'HME : – Pour le comprendre, nous avons commencé à analyser comment les données sont transférées à l'intérieur du serveur Zabbix :
Cool photo, non ? Passons en revue étape par étape pour que ce soit plus ou moins clair. Il existe des threads et des services chargés de collecter les données :
Ils transmettent les métriques collectées via un socket au gestionnaire de préprocesseur, où elles sont enregistrées dans une file d'attente :
Le « gestionnaire de préprocesseur » transmet les données à ses travailleurs, qui exécutent les instructions de prétraitement et les renvoient via le même socket :
Après cela, le gestionnaire de préprocesseur les stocke dans le cache historique :
À partir de là, ils sont récupérés par les plombs d'historique, qui remplissent de nombreuses fonctions : par exemple, calculer les déclencheurs, remplir le cache de valeurs et, surtout, enregistrer les métriques dans le stockage de l'historique. En général, le processus est complexe et très déroutant.
MM : – La première chose que nous avons constatée est que la plupart des threads se disputent ce que l'on appelle le « cache de configuration » (la zone mémoire où sont stockées toutes les configurations du serveur). Les threads chargés de collecter les données font surtout beaucoup de blocage :
... puisque la configuration stocke non seulement les métriques avec leurs paramètres, mais également les files d'attente à partir desquelles les interrogeurs obtiennent des informations sur la marche à suivre ensuite. Lorsqu'il y a plusieurs pollers et que l'un bloque la configuration, les autres attendent les requêtes :
Les sondeurs ne devraient pas entrer en conflit
Par conséquent, la première chose que nous avons faite a été de diviser la file d'attente en 4 parties et de permettre aux pollers de bloquer ces files d'attente, ces parties en même temps, dans des conditions sûres :
Cela a supprimé la concurrence pour le cache de configuration et la vitesse des interrogeurs a considérablement augmenté. Mais ensuite, nous avons été confrontés au fait que le gestionnaire du préprocesseur a commencé à accumuler une file d'attente de tâches :
Le gestionnaire de préprocesseur doit être capable de prioriser
Cela s'est produit dans les cas où il manquait de performance. Ensuite, tout ce qu'il pouvait faire était d'accumuler les requêtes des processus de collecte de données et d'ajouter leur tampon jusqu'à ce qu'il consomme toute la mémoire et plante :
Pour résoudre ce problème, nous avons ajouté un deuxième socket dédié spécifiquement aux travailleurs :
Ainsi, le gestionnaire du préprocesseur a eu la possibilité de prioriser son travail et, si le tampon augmente, la tâche est de ralentir la suppression, donnant ainsi aux travailleurs la possibilité d'utiliser ce tampon :
Ensuite, nous avons découvert que l'une des raisons du ralentissement était les travailleurs eux-mêmes, puisqu'ils étaient en compétition pour une ressource qui n'avait absolument aucune importance pour leur travail. Nous avons documenté ce problème comme un correctif de bug, et il a déjà été résolu dans les nouvelles versions de Zabbix :
Nous augmentons le nombre de sockets - nous obtenons le résultat
De plus, le gestionnaire de préprocesseur lui-même est devenu un goulot d'étranglement, puisqu'il ne s'agit que d'un seul thread. Il reposait sur la vitesse de base, donnant une vitesse maximale d'environ 70 XNUMX métriques par seconde :
Par conséquent, nous en avons fabriqué quatre, avec quatre jeux de douilles, ouvriers :
Et cela nous a permis d'augmenter la vitesse à environ 130 XNUMX métriques :
La non-linéarité de la croissance s’explique par l’apparition d’une concurrence pour le cache historique. 4 gestionnaires de préprocesseurs et plombs d'histoire se sont affrontés. À ce stade, nous recevions environ 130 95 métriques par seconde sur la machine de test, les utilisant à environ XNUMX % du processeur :
Il y a environ 2,5 mois
Le refus de la communauté SNMP a augmenté les NVP d'une fois et demie
MM : – Max, j'ai besoin d'une nouvelle voiture d'essai ! Nous ne rentrons plus dans celui actuel.
L'HME : - Qu'est-ce que tu as maintenant ?
MM : – Maintenant – 130 XNUMX NVP et un processeur prêt à l’emploi.
L'HME : - Ouah! Cool! Attendez, j'ai deux questions. D'après mes calculs, notre besoin est d'environ 15 à 20 XNUMX métriques par seconde. Pourquoi avons-nous besoin de plus ?
MM : "Je veux finir le travail." J'aimerais voir jusqu'où nous pouvons tirer parti de ce système.
L'HME : - Mais ...
MM : "Mais c'est inutile pour les affaires."
L'HME : - Il est clair. Et la deuxième question : pouvons-nous prendre en charge ce que nous avons actuellement par nous-mêmes, sans l'aide d'un développeur ?
MM : - Je ne pense pas. Changer le fonctionnement du cache de configuration est un problème. Cela affecte les changements dans la plupart des threads et est assez difficile à maintenir. Très probablement, il sera très difficile de le maintenir.
L'HME : "Alors nous avons besoin d'une sorte d'alternative."
MM : - Il existe une telle option. On peut passer aux noyaux rapides, tout en abandonnant le nouveau système de verrouillage. Nous obtiendrons toujours une performance de 60 à 80 XNUMX métriques. En même temps, on peut laisser tout le reste du code. Clickhouse et les sondages asynchrones fonctionneront. Et ce sera facile à entretenir.
L'HME : - Incroyable! Je suggère que nous nous arrêtions ici.
Après avoir optimisé le côté serveur, nous avons enfin pu lancer le nouveau code en production. Nous avons abandonné certains changements au profit du passage à une machine dotée de cœurs rapides et de la minimisation du nombre de modifications de code. Nous avons également simplifié la configuration et éliminé les macros dans les éléments de données lorsque cela était possible, car elles introduisent un verrouillage supplémentaire.
Par exemple, l'abandon de la macro snmp-community, que l'on retrouve souvent dans la documentation et les exemples, a permis dans notre cas d'accélérer encore les NVP d'environ 1,5 fois.
Après deux jours de production
Suppression des fenêtres contextuelles de l'historique des incidents
L'HME : – Misha, nous utilisons le système depuis deux jours et tout fonctionne. Mais seulement quand tout fonctionne ! Nous avions prévu des travaux avec le transfert d'un segment assez important du réseau, et nous avons encore une fois vérifié de nos propres mains ce qui marchait et ce qui ne marchait pas.
MM : - C'est impossible ! Nous avons tout vérifié 10 fois. Le serveur gère instantanément même l’indisponibilité complète du réseau.
L'HME : - Oui, je comprends tout : serveur, base de données, top, austat, logs - tout est rapide... Mais on regarde l'interface web, et il y a un processeur « dans l'étagère » sur le serveur et ça :
MM : - Il est clair. Regardons le Web. Nous avons constaté que dans une situation où il y avait un grand nombre d'incidents actifs, la plupart des widgets en direct commençaient à fonctionner très lentement :
La raison en était la génération de fenêtres contextuelles d'historique des incidents générées pour chaque élément de la liste. Nous avons donc abandonné la génération de ces fenêtres (commenté 5 lignes dans le code), et cela a résolu nos problèmes.
Le temps de chargement des widgets, même lorsqu'ils sont totalement indisponibles, a été réduit de quelques minutes aux 10-15 secondes acceptables pour nous, et l'historique peut toujours être consulté en cliquant sur l'heure :
Après le travail. il y a 2 mois
L'HME : - Misha, tu pars ? Il faut qu'on parle.
MM : - Je n'en avais pas l'intention. Encore quelque chose avec Zabbix ?
L'HME : - Non, détends-toi ! Je voulais juste dire : tout fonctionne, merci ! J'ai une bière.
Zabbix est efficace
Zabbix est un système et des fonctions assez universels et riches. Il peut être utilisé pour de petites installations prêtes à l’emploi, mais à mesure que les besoins augmentent, il doit être optimisé. Pour stocker une grande archive de métriques, utilisez un stockage approprié :
- vous pouvez utiliser des outils intégrés sous forme d'intégration avec Elasticsearch ou de téléchargement de l'historique vers des fichiers texte (disponibles à partir de la version XNUMX) ;
- Vous pouvez profiter de notre expérience et de notre intégration avec Clickhouse.
Pour augmenter considérablement la vitesse de collecte des métriques, collectez-les à l'aide de méthodes asynchrones et transmettez-les via l'interface trapper au serveur Zabbix ; ou vous pouvez utiliser un correctif pour rendre les interrogeurs Zabbix asynchrones.
Zabbix est écrit en C et est assez efficace. Résoudre plusieurs goulots d'étranglement architecturaux vous permet d'augmenter encore ses performances et, d'après notre expérience, d'obtenir plus de 100 XNUMX métriques sur une machine monoprocesseur.
Le même patch Zabbix
MM : – Je voudrais ajouter quelques points. L'intégralité du rapport actuel, tous les tests, les numéros sont donnés pour la configuration que nous utilisons. Nous en extrayons maintenant environ 20 XNUMX métriques par seconde. Si vous essayez de comprendre si cela fonctionnera pour vous, vous pouvez comparer. Ce qui a été discuté aujourd'hui est publié sur GitHub sous la forme d'un patch :
Le correctif comprend :
- intégration complète avec Clickhouse (à la fois le serveur Zabbix et le frontend) ;
- résoudre des problèmes avec le gestionnaire de préprocesseur ;
- sondage asynchrone.
Le patch est compatible avec toutes les versions 4, y compris lts. Très probablement, avec des modifications minimes, cela fonctionnera sur la version 3.4.
Je vous remercie de votre attention.
des questions
Question du public (ci-après – A) : – Bonjour ! S'il vous plaît dites-moi, avez-vous des projets d'interaction intensive avec l'équipe Zabbix ou avec eux avec vous, afin qu'il ne s'agisse pas d'un patch, mais d'un comportement normal de Zabbix ?
MM : – Oui, nous allons certainement apporter certains changements. Quelque chose va se passer, quelque chose va rester dans le patch.
Un: – Merci beaucoup pour l’excellent rapport ! S'il vous plaît dites-moi, après avoir appliqué le correctif, le support de Zabbix restera et comment continuer la mise à jour vers des versions supérieures ? Sera-t-il possible de mettre à jour Zabbix après votre patch vers 4.2, 5.0 ?
MM : – Je ne peux rien dire sur le support. Si j'étais le support technique de Zabbix, je dirais probablement non, car il s'agit du code de quelqu'un d'autre. Quant à la base de code 4.2, notre position est la suivante : « Nous évoluerons avec le temps et nous nous mettrons à jour sur la prochaine version. » Par conséquent, nous publierons pendant un certain temps un correctif pour les versions mises à jour. Je l'ai déjà dit dans le rapport : le nombre de modifications avec les versions est encore assez faible. Je pense que le passage de 3.4 à 4 nous a pris environ 15 minutes. Quelque chose a changé là-bas, mais pas très important.
Un: – Vous prévoyez donc de prendre en charge votre correctif et vous pouvez l’installer en toute sécurité en production et recevoir des mises à jour d’une manière ou d’une autre à l’avenir ?
MM : – Nous le recommandons fortement. Cela résout beaucoup de problèmes pour nous.
L'HME : – Encore une fois, je voudrais attirer l'attention sur le fait que les changements qui ne concernent pas l'architecture et ne concernent pas le blocage ou les files d'attente sont modulaires, ils sont dans des modules séparés. Même avec des modifications mineures, vous pouvez les maintenir assez facilement.
MM : – Si vous êtes intéressé par les détails, alors « Clickhouse » utilise ce qu'on appelle la bibliothèque historique. Il est délié - c'est une copie du support Elastics, c'est-à-dire qu'il est configurable. Le sondage ne change que les sondeurs. Nous pensons que cela fonctionnera pendant longtemps.
Un: - Merci beaucoup. Dites-moi, existe-t-il une documentation sur les modifications apportées ?
MM : – La documentation est un correctif. Évidemment, avec l'introduction de Clickhouse et l'introduction de nouveaux types de sondeurs, de nouvelles options de configuration apparaissent. Le lien de la dernière diapositive contient une brève description de la façon de l'utiliser.
À propos du remplacement de fping par nmap
Un: – Comment avez-vous finalement mis cela en œuvre ? Pouvez-vous donner des exemples précis : avez-vous des strappers et un script externe ? Qu'est-ce qui finit par vérifier un si grand nombre d'hôtes si rapidement ? Comment exploitez-vous ces hôtes ? Devons-nous les alimenter dans nmap d'une manière ou d'une autre, les récupérer de quelque part, les insérer, exécuter quelque chose ?
MM : - Cool. Une question très correcte ! Le point est le suivant. Nous avons modifié la bibliothèque (ICMP ping, qui fait partie de Zabbix) pour les vérifications ICMP, qui indiquent le nombre de paquets - un (1), et le code essaie d'utiliser nmap. Autrement dit, c'est le travail interne de Zabbix, qui est devenu le travail interne du pinger. En conséquence, aucune synchronisation ou utilisation d’un trappeur n’est requise. Cela a été fait délibérément afin de laisser le système intact et de ne pas avoir à gérer la synchronisation de deux systèmes de bases de données : que vérifier, télécharger via le poller, et notre téléchargement est-il interrompu ?.. C'est beaucoup plus simple.
Un: – Est-ce que ça marche aussi pour les proxys ?
MM : – Oui, mais nous n’avons pas vérifié. Le code d'interrogation est le même dans Zabbix et sur le serveur. Devrait marcher. Je le souligne encore une fois : les performances du système sont telles que nous n’avons pas besoin de proxy.
L'HME : – La bonne réponse à la question est : « Pourquoi avez-vous besoin d’un proxy avec un tel système ? » Uniquement à cause du NAT ou de la surveillance via une sorte de canal lent...
Un: – Et vous utilisez Zabbix comme allerteur, si je comprends bien. Ou vos graphiques (là où se trouve la couche d'archives) ont-ils été déplacés vers un autre système, tel que Grafana ? Ou n'utilisez-vous pas cette fonctionnalité ?
MM : – Je le souligne encore une fois : nous avons réalisé une intégration complète. Nous versons de l'historique dans Clickhouse, mais en même temps, nous avons modifié l'interface PHP. L'interface Php va à Clickhouse et réalise tous les graphiques à partir de là. En même temps, pour être honnête, nous avons une partie qui construit des données dans d'autres systèmes d'affichage graphique du même Clickhouse, à partir des mêmes données Zabbix.
L'HME : – Dans « Grafan » également.
Comment les décisions concernant l’allocation des ressources ont-elles été prises ?
Un: – Partagez un peu de votre cuisine intérieure. Comment a-t-on pris la décision qu'il était nécessaire d'allouer des ressources pour une transformation sérieuse du produit ? Ce sont, en général, certains risques. Et s'il vous plaît dites-moi, dans le contexte du fait que vous allez prendre en charge les nouvelles versions : comment cette décision se justifie-t-elle d'un point de vue gestion ?
MM : – Apparemment, nous n’avons pas très bien raconté le drame de l’histoire. Nous nous sommes retrouvés dans une situation où il fallait faire quelque chose, et nous avons essentiellement opté pour deux équipes parallèles :
- L'une consistait à lancer un système de surveillance utilisant de nouvelles méthodes : la surveillance en tant que service, un ensemble standard de solutions open source que nous combinons et essayons ensuite de modifier le processus métier afin de travailler avec le nouveau système de surveillance.
- En même temps, nous avions un programmeur enthousiaste qui faisait cela (à propos de lui-même). Il se trouve qu'il a gagné.
Un: – Et quelle est la taille de l’équipe ?
L'HME : - Elle est devant toi.
Un: – Alors comme toujours, il vous faut un passionné ?
MM : – Je ne sais pas ce qu’est un passionné.
Un: - Dans ce cas, apparemment, c'est toi. Merci beaucoup, vous êtes génial.
MM : - merci
À propos des correctifs pour Zabbix
Un: – Pour un système qui utilise des proxys (par exemple, dans certains systèmes distribués), est-il possible d'adapter et de patcher, par exemple, les pollers, les proxys et partiellement le préprocesseur de Zabbix lui-même ; et leur interaction ? Est-il possible d’optimiser les développements existants pour un système avec plusieurs proxys ?
MM : – Je sais que le serveur Zabbix est assemblé à l'aide d'un proxy (le code est compilé et obtenu). Nous n'avons pas testé cela en production. Je n'en suis pas sûr, mais je pense que le gestionnaire de préprocesseur n'est pas utilisé dans le proxy. La tâche du proxy est de récupérer un ensemble de métriques de Zabbix, de les fusionner (il enregistre également la configuration, la base de données locale) et de le restituer au serveur Zabbix. Le serveur lui-même effectuera ensuite le prétraitement lorsqu'il le recevra.
L’intérêt pour les proxys est compréhensible. Nous allons le vérifier. C'est un sujet intéressant.
Un: – L'idée était la suivante : si vous pouvez patcher les pollers, vous pouvez les patcher sur le proxy et corriger l'interaction avec le serveur, et adapter le préprocesseur à ces fins uniquement sur le serveur.
MM : – Je pense que c’est encore plus simple. Vous prenez le code, appliquez un correctif, puis configurez-le comme vous le souhaitez : collectez des serveurs proxy (par exemple, avec ODBC) et distribuez le code corrigé sur tous les systèmes. Si nécessaire, collectez un proxy, si nécessaire, un serveur.
Un: – Très probablement, vous n’aurez pas à corriger en plus la transmission proxy vers le serveur ?
L'HME : - Non, c'est standard.
MM : – En fait, une des idées ne sonnait pas. Nous avons toujours maintenu un équilibre entre l’explosion des idées et la quantité de changements et la facilité d’accompagnement.
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