Zabbix est un excellent produit pour les administrateurs de gros systèmes logiciels et matériels. Il est si bon qu'il peut être utilisé non seulement par les grandes entreprises, mais aussi par les petites et moyennes entreprises, et même dans un projet pour pet . En général, j'ai peu d'expérience avec Zabbix et je peux recommander son utilisation en toute sécurité.
Certes, je ne peux pas dire que je comprends la « philosophie de Zabbix ». Malgré la vaste documentation détaillée en russe, il m'a été difficile de me plonger dans le monde de Zabbix - j'avais l'impression que les développeurs et moi appelions les mêmes choses sous des noms différents. Peut-être parce que Zabbix a été créé par des administrateurs pour des administrateurs, mais je suis toujours plus développeur et utilisateur.
Cependant, pour exécuter Zabbix et surveiller les principaux paramètres des systèmes informatiques (processeur, mémoire, etc.), les compétences d'un utilisateur Linux régulier suffisent. Il existe un grand nombre de plug-ins de développeurs tiers qui étendent les capacités de Zabbix. Pour mes besoins, j'avais besoin de configurer la surveillance du serveur Redis. J'ai fouillé un peu dans le code des plug-ins disponibles et, à l'aide de leur exemple, j'ai découvert que l'architecture de Zabbix vous permet de simplement connecter tous les paramètres du système d'information qui peuvent être exprimés sous forme numérique à la surveillance.
Sous le chat - un exemple de plugin Zabbix avec mon explication de la terminologie Zabbix. Pour certains, cet exemple semblera naïf, mais pour certains, il sera plus facile de se familiariser avec les concepts. Dans tous les cas, Zabbix est suffisamment grand pour le ressentir sous différents angles.
Concepts de base
En bref sur certains des concepts utilisés dans Zabbix: agents , éléments , déclencheurs , actions , notifications , modèles .
Serveur et agents
Du point de vue de l'utilisateur, Zabbix est divisé en deux grandes parties: serveur et agents. Le serveur est situé sur une machine, qui collecte et stocke des données statistiques, et des agents sur les machines à partir desquelles les données sont collectées:
Options de surveillance
Toute quantité qui peut être exprimée sous forme numérique ou chaîne est appelée dans la terminologie de Zabbix - un élément de données (élément). Chaque élément est associé à une clé unique (nom). Voici des exemples d'éléments de données:
- system.cpu.load [percpu, avg1] : 0.1167
- system.uname : "Linux supru 4.15.0-50-generic # 54-Ubuntu SMP lun 6 mai 18:46:08 UTC 2019 x86_64"
Les valeurs de ces éléments de données (paramètres de surveillance) sont attachées au temps; l'historique des valeurs des paramètres est stocké dans la base de données du serveur.
Les événements
Lorsqu'un événement se produit dans Zabbix, un déclencheur se déclenche. Par exemple
- {system.cpu.load [percpu, avg1] .avg (5m)}> 10 - la valeur moyenne du paramètre au cours des 5 dernières minutes a dépassé "10"
- {system.uname.diff (0)}> 0 - la valeur actuelle du paramètre n'est pas égale à la valeur précédente
En fait, les déclencheurs sont des formules dans lesquelles les paramètres de surveillance (actuels et enregistrés) agissent comme des variables et qui produisent true / false en sortie.
Actions et alertes
En cas d'événement (déclencheur), le serveur peut effectuer une action. Par exemple, envoyez une alerte par e-mail à une adresse donnée (" Problème: l'hôte est inaccessible pendant 5 minutes "). En outre, une action peut être effectuée si le déclencheur revient à son état d'origine (« Résolu: l'hôte est inaccessible pendant 5 minutes »). Tous les événements (déclenchement de commutation) sont enregistrés côté serveur.
Patterns
Zabbix permet de configurer des règles de surveillance pour un hôte individuel, ainsi que de créer un modèle de règle (modèle) qui peut être appliqué à différents hôtes:
L'exemple montre que le modèle «Template App SSH Service» décrit une application (Applications), un paramètre de surveillance (Items), un déclencheur (Triggers). Des descriptions de graphiques, d'écrans, de règles de découverte et de scripts Web sont également disponibles.
Définition de la tâche pour le plugin
Position de départ
Zabbix lui-même propose son propre plugin pour surveiller l'état de Redis, mais sur ma version du serveur (4.2.8) je n'ai pas pu l'utiliser (plugin pour la version 4.4 et supérieure). Des solutions de tiers sont également proposées (une dizaine d'options pour différentes versions de Zabbix, il n'y a que les trois premières dans l'image):
Chacun d'eux avait ses propres avantages et inconvénients, devait regarder à l'intérieur pour choisir. Le meilleur, à mon avis, était le plugin Shakeeljaveed / zabbix-redis-userparamaters , qui comprenait deux fichiers:
- README.md
- redis-userparameter.conf
Je devais travailler un peu "stylos", mais sur son exemple, il est devenu un peu plus clair comment les données de l'agent vont au serveur. À la suggestion de l'auteur Javeed Shakeel, l' état de Redis a été réinitialisé toutes les 2 minutes par la couronne dans le /tmp/redismetric :
*/2 * * * * /usr/bin/redis-cli info > /tmp/redismetric
Ensuite, chaque paramètre de surveillance a été extrait par l'agent du /tmp/redismetric à l'aide des outils du système d'exploitation lui-même. Des instructions ont été placées dans la configuration de l'agent Zabbix /etc/zabbix/zabbix_agent.conf.d/userparameter_redis.conf . Par exemple, used_memory l'instruction de récupération du paramètre used_memory (utilisation de la mémoire par le serveur Redis):
UserParameter=used_memory,grep -w 'used_memory' /tmp/redismetric | cut -d: -f2
Autrement dit, dans le /tmp/redismetric avec la sortie de redis-cli INFO , la chaîne ( grep -w ... ) est recherchée par la clé used_memory
used_memory:7153216
qui est ensuite divisé en colonnes par le séparateur ":" ( cut -d: -f2 ). En sortie, l'agent reçoit le numéro 7153216 et l'affecte au paramètre used_memory .
Il reste à configurer le serveur via l'interface Web afin qu'il envoie périodiquement des demandes à l'agent pour recevoir des données en utilisant le paramètre used_memory , après quoi les données commencent à être used_memory sur le serveur, stockées dans la base de données, vous pouvez l'utiliser pour construire des graphiques et créer des déclencheurs qui répondent aux modifications de ce paramètre.
But
La tâche de surveiller l'état de tout système n'est pas seulement la collecte de statistiques, mais aussi un avertissement sur la survenance de situations nécessitant une intervention humaine. Comme je travaille avec Redis en tant qu'utilisateur très novice, j'ai dû chercher des informations sur les paramètres de "santé" auxquels prêter attention et ce qu'ils signifient. L'article le plus digne était " 6 mesures de surveillance Crucial Redis que vous devez surveiller ". Après l'avoir analysé, je suis arrivé à la conclusion que «pour un bonheur complet», je dois collecter des données pour détecter les événements suivants:
- Fragmentation de la mémoire: used_memory_rss / used_memory> 1.5
- Faible taux d'accès au cache: (keyspace_hits) / (keyspace_hits + keyspace_misses) <0,8
- Connexions rejetées: rejeté_connexions> 0
- Clés expulsées: evicted_keys> 0
Je souhaitais également collecter des statistiques sur des paramètres supplémentaires (version Redis, disponibilité, etc.). En général, ayant une idée générale de la façon dont les données sont collectées par l'agent et transmises au serveur, la liste de souhaits peut être considérablement limitée. En conséquence, nous avons obtenu une liste de paramètres pour la surveillance à partir de 12 positions.
Créez votre propre plugin
Options de surveillance
Le plugin que j'ai analysé a supposé l'exécution d'une commande distincte pour obtenir un paramètre distinct (élément de données, élément):
grep -w 'used_memory' /tmp/redismetric | cut -d: -f2
Autrement dit, pour obtenir des données sur 12 paramètres, l'agent devra exécuter différents ensembles de commandes 12 fois. Et si j'ai besoin de surveiller des paramètres difficiles à extraire par une chaîne de commandes et que je dois écrire un script shell séparé ou un programme à part entière? Pour une telle "liste de souhaits", Zabbix propose une variante avec des éléments de données dépendants. Son essence est que du côté de l'agent, le script forme un ensemble de données (par exemple, au format JSON), qui est transmis au serveur en tant que paramètre de chaîne. Ensuite, côté serveur, les données reçues sont analysées et des paramètres élémentaires individuels en sont extraits.
Élément de données principal
J'ai décrit l' redis.info données principal redis.info type de chaîne avec une période de mise à jour de 1 min, sans enregistrer l'historique des modifications:
Vraisemblablement, le JSON suivant devrait être généré côté agent:
{ "version": "4.0.9", "uptime": 1897336, "used_memory": 1054943416, "used_memory_rss": 1138159616, "keyspace_hits": 75810274, "keyspace_misses": 13545949, "connected_clients": 15, "rdb_last_save_time": 1580126954, "total_connections_received": 1258614, "rejected_connections": 0, "expired_keys": 60270, "evicted_keys": 0 }
après quoi ce texte doit être redis.info au serveur en tant redis.info données redis.info , mais pas enregistré, mais servir de base à d'autres éléments de données (paramètres de surveillance).
Élément de données dépendant
Le paramètre de test redis.info.version dépend de redis.info et stocke ses valeurs dans la base de données pendant 90 jours. La fréquence de surveillance des paramètres dépend de l'élément de base ( redis.info ):
La redis.info.version paramètre redis.info.version est extraite de la valeur redis.info à l'aide des instructions JSONPath:
Un schéma similaire décrit les éléments de données dépendants restants (paramètres de surveillance), qui sont transmis sous forme de JSON. Voici un exemple de la description du paramètre numérique redis.info.used_memory :
Tout est assez transparent, à l'exception des Units et Trend storage period . Je n'ai pas compris le deuxième point, je l'ai laissé par défaut, et les unités de mesure sont expliquées dans la documentation . Dans ce cas, la valeur de redis.info.used_memory est mesurée en octets et réduite à kilo / mega / giga /...- octets dans l'interface Web.
La formule pour extraire une valeur de JSON est: JSONPath = $.used_memory
Élément de données calculé
Pour calculer la fragmentation de la mémoire, la relation used_memory_rss / used_memory est utilisée et, sur sa base, un déclencheur est déterminé qui se déclenche lorsque le rapport dépasse 1,5. Zabbix a un type d'élément de données calculé:
La valeur du paramètre redis.info.used_memory_ratio calculée toutes les minutes sur la base des dernières valeurs de deux autres paramètres ( redis.info.used_memory_rss et redis.info.used_memory ), est stockée dans la base de données pendant 90 jours, etc.
DĂ©clencheurs
Voici un exemple de déclencheur qui se déclenche lorsque la mémoire est trop fragmentée:
Rien d'inhabituel, à l'exception du format d'expression utilisé dans la formule de changement d'état du déclencheur. Zabbix a un concepteur de formulaire, vous pouvez l'utiliser ou vous référer à la documentation / exemples (la liste des déclencheurs est disponible via l'interface web à " Configuration / Templates / $ {TemplateName} / Triggers ").
Un déclencheur peut être basé sur tous les éléments de données (élément), quel que soit leur type (principal, dépendant, calculé).
Configuration de l'agent
Génération JSON
Pour obtenir les valeurs des paramètres de surveillance et la formation de JSON, j'utilise ce script shell:
J'ai placé ce script dans le fichier /var/lib/zabbix/user_parameter/redis/get_info.sh sur le serveur avec Redis, sur lequel l'agent Zabbix est déjà installé. L'utilisateur sous lequel l'agent Zabbix est zabbix (généralement zabbix ) doit avoir l'autorisation d'exécuter le fichier get_info.sh .
Fichier userparameter_XXX.conf
Côté agent, des paramètres de surveillance supplémentaires sont userparameter_*.conf dans les userparameter_*.conf du répertoire userparameter_*.conf . Par conséquent, afin que l'agent découvre comment il doit collecter des données sur le paramètre redis.info , j'ai créé le fichier /etc/zabbix/zabbix_agentd.d/userparameter_redis.conf avec le contenu suivant:
UserParameter=redis.info,/var/lib/zabbix/user_parameter/redis/get_info.sh
Autrement dit, pour obtenir des données sur le paramètre redis.info agent doit exécuter le script /var/lib/zabbix/user_parameter/redis/get_info.sh et transférer le résultat de l'exécution sur le serveur.
Après avoir redémarré l'agent Zabbix ( sudo service zabbix-agent restart ), il devient possible de collecter des données pour le paramètre redis.info et de les envoyer au serveur.
Résumé
Comprendre Zabbix m'est venu (et vient toujours) assez dur. Néanmoins, je le considère comme un excellent outil, surtout après que la simplicité d'ajouter mes propres paramètres de surveillance (éléments de données) s'est ouverte pour moi. Dans l'ensemble, il suffit d'ajouter un fichier au serveur avec l'agent ( userparameter_XXX.conf ) avec une commande shell pour collecter des données et configurer le serveur Zabbix pour recevoir ces données via l'interface Web. Et c'est tout - vous pouvez accumuler des données, créer des graphiques, analyser les changements et créer un déclencheur qui répond à ces changements.
Le code du modèle, le fichier userparameter_redis.conf et le script get_info.sh peuvent être consultés dans le projet flancer32 / zabbix_plugin_redis .
Merci à tous ceux qui ont lu jusqu'à la fin, et surtout à ceux qui ont trouvé quelque chose d'utile dans la publication.