Présentation
Tous ceux qui utilisent le système de surveillance Zabbix et surveillent son développement savent qu'avec la sortie de Zabbix 3.4, nous avons une grande fonctionnalité - les éléments dépendants (éléments de données dépendants), sur lesquels il y avait déjà un article de blog
correspondant sur Zabbix. Cependant, sous la forme dans laquelle il a été introduit en 3.4, son utilisation «au maximum» était problématique en raison du fait que les macros LLD n'étaient pas prises en charge pour une utilisation dans les règles de prétraitement (
ZBXNEXT-4109 ), ainsi qu'en tant que «parent» Un seul qui a été créé par la règle LLD elle
- même (
ZBXNEXT-4200 ) a pu être sélectionné dans l'élément de données. En bref, j'ai dû tout faire exactement comme décrit dans le lien ci-dessus - pour travailler avec vos mains, ce qui, avec un grand nombre de mesures, a causé beaucoup de désagréments. Cependant, avec la sortie de Zabbix 4.0alpha9, tout a changé.
Un peu d'histoire
Pour moi, la fonctionnalité décrite était importante car notre entreprise utilise plusieurs systèmes de stockage HP, à savoir HP MSA 2040/2050, dont les métriques sont supprimées par des requêtes à leur API XML à l'aide d'un
script Python .
Au tout début, lorsque la tâche consistait à surveiller l'équipement désigné et qu'une option a été trouvée à l'aide de l'API, il s'est avéré que dans le cas le plus simple, afin de connaître, par exemple, l'état de santé d'un composant du système de stockage, il était nécessaire de faire deux requêtes:
- Demander un jeton d'authentification (clé de session);
- La demande elle-même, renvoyant des informations sur le composant.
Imaginez maintenant que le stockage se compose de 24 disques (ou peut-être plus), de deux blocs d'alimentation, d'une paire de contrôleurs, de ventilateurs, de plusieurs pools de disques, etc. - nous multiplions tout cela par 2 et obtenons plus de 50 éléments de données, ce qui équivaut au même nombre de demandes à API à chaque minute vérifie. Si vous essayez de suivre cette voie, l'API se «dépose» rapidement et, après tout, nous ne parlons que de demander la «santé» des composants, sans tenir compte des autres mesures possibles et intéressantes - température, heures de fonctionnement pour les disques durs, vitesse du ventilateur, etc.
La première décision que j'ai prise pour décharger l'API, avant même la sortie de la version 3.4 de Zabbix, a été de créer un cache pour le jeton reçu, dont la valeur a été écrite dans le fichier et stockée pendant N minutes. Cela a permis de réduire le nombre d'appels à l'API d'exactement deux fois, cependant, la situation n'a pas beaucoup changé - il était difficile d'obtenir autre chose que l'état de santé. À cette époque, j'ai visité le Zabbix Moscow Meetup 2017, hébergé par Badoo, où j'ai découvert la fonctionnalité des éléments de données dépendants mentionnés ci-dessus.
Le script a été modifié pour pouvoir donner des objets JSON détaillés contenant des informations qui nous intéressent sur divers composants du référentiel et sa sortie a commencé à ressembler à ceci au lieu d'une seule chaîne ou de valeurs numériques:
{"1.1":{"health":"OK","health-num":"0","error":"0","temperature":"24","power-on-hours":"27267"},"1.2":{"health":"OK","health-num":"0","error":"0","temperature":"23","power-on-hours":"27266"},"1.3":{"health":"OK","health-num":"0","error":"0","temperature":"24","power-on-hours":"27336"}, ... }
Ceci est un exemple avec les données fournies sur tous les disques de stockage. Pour les autres composants, l'image est similaire - la clé est l'ID du composant et la valeur est un objet JSON contenant les métriques nécessaires.
Tout allait bien, mais les nuances décrites au début de l'article sont rapidement apparues - toutes les métriques dépendantes ont dû être créées et mises à jour manuellement, ce qui était plutôt pénible (environ 300 métriques par système de stockage plus déclencheurs et graphiques). LLD pourrait nous sauver, mais ici, lors de la création du prototype, il ne nous a pas permis de spécifier celui qui n'a pas été créé par la règle elle-même en tant qu'élément parent, et a abandonné le hack sale en créant un élément fictif via LLD et en remplaçant son ID d'article dans la base de données par celui souhaité Serveur Zabbix. Les demandes de fonctionnalités mentionnées sont rapidement apparues dans le suivi des bogues Zabbix, ce qui a indiqué que cette fonctionnalité était importante non seulement pour moi.
Parce que toutes les opérations préparatoires de ma part ont été achevées, j'ai décidé de tolérer et de ne pas produire de solutions temporaires, telles que la génération de modèles dynamiques, et j'ai seulement attendu la fermeture des ZBXNEXT indiqués au début de l'article et tout récemment, cela a été fait.
À quoi ça ressemble maintenant
Pour démontrer les nouvelles fonctionnalités de Zabbix, nous prenons:
- Stockage HPE MSA 2040 disponible via HTTP / HTTPS;
- Serveur Zabbix 4.0alpha9 installé à partir du référentiel officiel sur CentOS 7.5.1804;
- Un script écrit en Python de la troisième version et nous permettant de détecter les composants de stockage (LLD) et de renvoyer des données au format JSON pour l'analyse côté serveur Zabbix en utilisant le chemin JSON.
L'élément de données parent sera une «vérification externe» qui appelle le script avec les arguments nécessaires et stocke les données reçues sous forme de texte.
La préparation
Le script Python est installé conformément à la
documentation et possède une bibliothèque «requêtes» dans les dépendances Python. Si vous avez une distribution basée sur RHEL, vous pouvez l'installer à l'aide du gestionnaire de packages yum:
[root@zabbix]
Ou en utilisant pip:
[root@zabbix]
Vous pouvez tester le script à partir du shell en demandant, par exemple, des données LLD sur les disques:
[root@zabbix]
Configuration de l'hôte
Vous devez d'abord créer des éléments de données parents qui contiendront toutes les mesures dont nous avons besoin. Par exemple, créez un tel élément pour les disques physiques:
Nom - spécifiez arbitrairement;
Type - vérification externe;
La clé est d'appeler le script avec les paramètres nécessaires (voir la
documentation du
script sur GitHub);
Type d'information - texte;
Intervalle de mise à jour - l'exemple utilise une macro personnalisée {$ UPDATE} s'étendant jusqu'à la valeur "1m";
La période de stockage de l'historique est d'un jour. Je pense que le stockage de l'élément de données parent n'a plus de sens.
Vérifiez les dernières données de l'élément créé:
JSON arrive, puis tout se fait correctement.
La prochaine consistera à configurer des règles de découverte qui trouveront tous les composants disponibles pour la surveillance et créeront des éléments et des déclencheurs dépendants. Poursuivant l'exemple avec des disques physiques, cela ressemblera à ceci:
Après avoir créé la règle LLD, vous devrez prototyper les éléments de données. Créons un tel prototype, en utilisant les données de température comme exemple:
Nom - spécifiez arbitrairement;
Le type dépend. En tant qu'élément de données parent, sélectionnez l'élément correspondant créé précédemment;
Clé - nous ferons preuve d'imagination, mais nous devons tenir compte du fait que chaque clé doit être unique, nous allons donc y inclure la macro LLD;
Type d'information - dans ce cas numérique;
Période de stockage de l'historique - dans l'exemple, il s'agit d'une macro personnalisée, indiquée à votre discrétion;
La période de stockage de tendance est, encore une fois, une macro personnalisée;
J'ai également ajouté un prototype de l '«Application» - vous pouvez facilement y lier des mesures liées à un composant.
Dans l'onglet «Prétraitement», créez une étape de type «Chemin JSON» avec une règle qui récupère les relevés de température:
L'expression d'étape ressemble à ceci:
$['{#DISK.ID}']['temperature']Veuillez noter que vous pouvez maintenant utiliser des macros LLD dans l'expression, ce qui non seulement simplifie considérablement notre travail, mais facilite également de telles choses (vous auriez déjà été envoyé à l'API Zabbix).
Ensuite, par analogie avec la température, créez les prototypes restants des éléments de données:
À ce stade, vous pouvez vérifier le résultat en accédant aux "Données récentes" sur l'hôte. Si tout vous convient, nous continuons à travailler davantage. Je me suis retrouvé avec l'image suivante:
Nous attendons la mise à jour du cache de configuration ou le poussons manuellement pour mettre à jour:
[root@zabbix]
Après cela, vous pouvez utiliser un autre "truc" sympa de la version 4.0 - le bouton "Vérifier maintenant" pour exécuter les règles LLD créées:
J'ai obtenu le résultat suivant:
Conclusion
En conséquence, avec seulement neuf demandes à l'API XML, nous avons pu obtenir plus de trois cents mesures à partir d'un nœud de réseau, y consacrer un minimum de temps et obtenir une flexibilité maximale. LLD nous donnera la possibilité de détecter automatiquement les nouveaux composants ou de mettre à jour les anciens.
Merci d'avoir lu, des liens vers les matériaux utilisés, ainsi que vers le modèle actuel pour le HPE MSA P2000G3 / 2040/2050 se trouvent ci-dessous.
PS Soit dit en passant, dans la version 4.0, un nouveau type de vérifications est également introduit - un agent HTTP, qui, associé au prétraitement et au chemin XML, peut potentiellement nous éviter d'utiliser des scripts externes - vous n'avez qu'à résoudre le problème d'obtention d'un jeton d'authentification, qui doit toujours être mis à jour périodiquement. L'une des options que je vois est l'utilisation d'une macro globale avec ce jeton, qui peut être mise à jour via l'API Zabbix par couronne, incl. les personnes intéressées peuvent développer cette idée. =)
ScriptModèle de partage ZabbixÉléments de données dépendantsChemin JsonZabbix 4.0alpha9