Qu'est-ce que le Health Check ?
Le Health Check est une commande présente dans toute installation Shinken Entreprise qui permet de vérifiier le bon fonctionnement de Shinken Entreprise.
Cet outil est utilisé pour vérifier :
- L'état de l'installation de Shinken Enterprise (version des démons).
- L'état des principales options de configuration réseau (ports, adresses).
- L'état des modules et sous-modules activés sur les démons.
- L'état des connexions réseau et la synchronisation d'horloge entre les démons.
Le Health Check est donc un outil de diagnostic général qui peut détecter les problèmes les plus importants. Cependant, il ne fournit pas autant d'informations et de détail que les checks fournis par Shinken pour son propre monitoring, par exemple des indicateurs de performance.
Usage
shinken-healthcheck |
Principales options
| Option | Option longue | Description |
|---|---|---|
-h | --help | Affiche le message d'aide |
-v | --version | Affiche la version de Shinken Entreprise installée |
-l | --local | Effectue une vérification des démons locaux seulement |
| -g | --global | Effectue une vérification complète des démons (doit être lancé depuis la machine comportant l'Arbiter et le Synchronizer). Sur une machine avec un Arbiter et un Synchronizer, un Health Check global est effectué sauf si un Health Check local est explicitement demandé. |
| --debug | Active l'affichage des données de debug dans la sortie de la commande. Utile seulement dans le cas d'un envoie de ces données aux équipes de support de Shinken Solutions. | |
| -f | --file | Ecrit la sortie de la commande dans un fichier. La sortie de la commande est également affichée. |
| --output-directory | Dossier dans lequel sera placé le fichier de sortie. Par défaut, le dossier courant est utilisé. | |
| --output-name | Fichier dans lequel sera placé le fichier de sortie. Valeur par défaut: shinken-healthcheck_$(DATE).txt | |
| --timeout | Temps en secondes a partir duquel un démon sera considéré comme injoignable. Par défaut: 3 secondes | |
| --modules-warning-expire | Temps en minutes pendant lequel un redémarrage de module génère une alerte. Par défaut 120 (2 heures), valeur maximale 1440 (24 heures) |
La commande shinken-healthcheck sépare sa vérification en plusieurs parties qui sont décrites dans les sections suivantes.
Informations de version
|
La première section visible dans le Healthcheck est l'affichage de la version installée, ainsi que la première version installée sur ce serveur.
Vérification de l'architecture
Etat des démons
Le Healthcheck affiche ensuite pour tous les démons activés dans la configuration, différentes informations indiquant le bon fonctionnement du démon:
- Le type et le nom du démon. Si celui est un Spare, une mention "SPARE" est présente à la suite du nom du démon.
- La configuration est elle valide ?
- Le démon est-il joignable sur le port trouvé dans la configuration ?
- La version actuelle du démon. Si il y a une différence de version entre l'Arbiter et le démon, un message d'erreur indique cette différence.
- Connection avec l'Arbiter, ainsi que le décalage de temps entre le démon et l'Arbiter.
- Si plusieurs Arbiters envoient une configuration au démon, un message d'erreur indique que 2 Arbiters sont en conflit, en précisant l'URL de chacun de ces arbiters.
- Liste des autres démons à contacter pour pouvoir fonctionner correctement (section "Talk to").
- Etat des modules, et le cas échéant des sous-modules. Si un module a redémarré récemment, un avertissement sera affiché en indiquant la liste des derniers redémarrages du module ou sous-modules.
- Champs spécifiques au démon
- Liste des tags pour le Poller et Reactionner, ainsi que les éventuelles erreurs sur les workers.
|
Dans l'affichage de l'état des démons, ainsi que dans les sections suivantes, plusieurs états peuvent être retournés:
- OK: Tout va bien
- AT RISK: Problème pouvant potentiellement nuire au fonctionnement du système.
- ERROR: Une erreur bloquante a été détectée.
Royaumes et sous-royaumes
Dans une configuration de Shinken Entreprise, les démons peuvent être répartis sur plusieurs machines.
Dans le Healthcheck, les démons sont regroupés en fonction de la machine sur laquelle ils sont installés.
On voit dans l'exemple ci-contre qu'un Poller est installé sur la machine d'adresse 192.168.1.35, et qu'un Arbiter et un Broker sont installés et activés sur la machine vm3 (172.16.0.3).
|
Si plusieurs royaumes sont définis, la sortie de shinken-healthcheck organise les machines par royaume et sous-royaumes, puis les démons sont répartis par machine d'installation.
Dans l'exemple ci-contre, on voit que la configuration comporte 4 royaumes, agencés comme suivant:
- Un royaume principal: France
- Un Sous Royaume: Corse
- Un Sous Royaume: Sud Ouest
- Un Sous Royaume: Bordeaux
On voit aussi, pour chaque royaume, les démons activés ainsi que la machine sur laquelle ils sont installés. Dans l'exemple de healthcheck, on peut faire le récapitulatif suivant:
- Royaume France: 8 démons répartis sur 2 machines
- Machine d'adresse a.a.a.a: Poller
- Machine master1 (b.b.b.b): Arbiter, Broker, Poller, Reactionner, Synchronizer, Receiver, Scheduler
- Royaume France/Corse: 3 démons installés sur une seule machine
- Machine master2 (d.d.d.d): Broker, Poller, Scheduler
- Royaume France/Sud Ouest: Un démon installé sur une machine
- Machine master2: Broker
- Royaume France/Sud Ouest/Bordeaux: 2 démons installés
- Machine master2: Poller, Scheduler
-----------------
| Realm /France |
-----------------
--------------
| In France/ |
--------------
- a.a.a.a (a.a.a.a):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[poller: poller-windows1]
....
- master1 (b.b.b.b):
^^^^^^^^^^^^^^^^^^^^^^^^^^
[arbiter: arbiter-master]
...
[broker: broker-master]
...
[poller: poller-master1]
...
[reactionner: reactionner-master]
...
[synchronizer: synchronizer-master]
...
[receiver: receiver-1]
...
[scheduler: scheduler-master]
...
-----------------------
| Realm /France/Corse |
-----------------------
-------------
| In Corse/ |
-------------
- master3 (d.d.d.d):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[broker: broker-master-3]
...
[poller: poller-master3]
...
[scheduler: scheduler-master3]
...
---------------------------
| Realm /France/Sud Ouest |
---------------------------
-----------------
| In Sud Ouest/ |
-----------------
- master2 (c.c.c.c):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[broker: broker-master-2]
...
------------------------------------
| Realm /France/Sud Ouest/Bordeaux |
------------------------------------
----------------
| In Bordeaux/ |
----------------
- master2 (c.c.c.c):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[poller: poller-master2]
...
[scheduler: scheduler-master2]
... |
Vérification de la licence
Cette section du Healthcheck affiche des informations sur la licence en cours.
Elle affiche le propriétaire de la licence, le type de licence, et la date d'expiration de la licence.
Si le nombre de noeuds est dépassé ou que la licence est expirée, une erreur sera affichée dans cette section.
|
Vérification des librairies externes
Shinken Entreprise utilise de nombreuses librairies externes pour fonctionner.
Cette partie du Healthcheck vérifie que toutes les librairies nécessaires au bon fonctionnement de Shinken Entreprise sont installées sur la machine, ainsi que leur version.
En cas d'erreur sur une des librairies, une erreur est affichée indiquant la nature de l'erreur.
|
Vérification des interfaces de Configuration et Visualisation
La section Modules effectue des vérifications sur le fonctionnement des interfaces de Configuration et Visualisation. Pour chaque interface, le Healthcheck vérifie que la base de données Mongo est accessible, et que les paramètres d'authentification sont bien définis.
|
Vérification des espaces de stockage
Shinken Entreprise sauvegarde les données de métrologie dans un serveur Graphite. Si la configuration de la sauvegarde des données de métrologies est simple pour une configuration basique, elle devient rapidement compliquée lorsque la configuration comporte plusieurs royaumes avec plusieurs Brokers.
Lorsque plusieurs Broker sont dans un même royaume, il faut s'assurer que les Brokers écrivent les données de métrologie au même endroit (sur le ou les mêmes serveurs Graphite). Il faut également s'assurer que toutes les interfaces de Visualisation d'un royaumes lisent les données de métrologie sur le même serveur, afin d'assurer une cohérence des données. Aussi, il faut s'assurer de ne pas avoir oublié de configurer au moins un broker d'un royaume pour écrire les données de métrologie dans la base Graphite, sans quoi aucune donnée de métrologie ne sera sauvegardée.
Le Healthcheck possède donc une section dédiée à la vérification des espaces de stockage des données de métrologie, qui vérifie que les données de métrologie sont bien sauvegardées pour chaque royaume, que toutes les interfaces de visualisation lisent bien les données de métrologie au bon endroit, et que les serveurs de métrologie sont effectivement joignables et aptes à sauvegarder des données.
La première section de la vérification des espaces de stockage Graphite s'occupe de vérifier que pour chaque royaume, les données de métrologie sont bien sauvegardées dans au moins un serveur Graphite.
Sur l'exemple ci-contre, on voit que tous les royaumes ont bien au moins un Broker qui permet la sauvegarde des données de métrologie:
- Le royaume Corse sauvegarde ses données de métrologie sur le serveur 192.168.1.47
- Le royaume Metropole sauvegarde ses données de métrologie sur le serveur 172.16.0.3
- Le royaume Reunion sauvegarde ses données de métrologie sur le serveur 192.168.1.35
Si un royaume ne possède aucun Broker sauvegardant les données de métrologie, une erreur sera affichée.
On note que si il n'y a aucun hôte à superviser dans le royaume, le Broker n'a pas besoin de sauvegarder de données de métrologie, et donc ne sera pas indiqué en erreur si il ne sauvegarde pas de données dans Graphite.
|
La vérification des espaces de stockage vérifie ensuite si toutes les interfaces de Visualisation d'un royaume.
Pour chaque royaume défini dans la configuration, le healthcheck va vérifier qu'il existe bien au moins un Broker de ce royaume permettant d'afficher les données de métrologie.
Si le royaume comporte plusieurs Brokers, le healthcheck vérifie que tous les Brokers ont la même configuration en ce qui concerne le serveur Graphite à utiliser pour récupérer les données de métrologie.
|
Enfin, lors de la vérification des espaces de stockage, le healthcheck cherche à déterminer si tous les serveurs utilisés dans les différents royaumes pour stocker des données de métrologie sont joignables.
Le healthcheck vérifie également que tous ces serveurs permettent bien de lire et écrire des données.
Ainsi, pour chaque serveur, le healthcheck tente d'effectuer une écriture et une lecture de données, et affiche le résultat.
On voit ici dans l'exemple que tous les serveurs utilisés pour le stockage des données de métrologie sont bien joignables et permettent effectivement d'écrire et de lire des données de métrologie.
|
Comment interpréter les informations et erreurs courantes du Healthcheck
Le healthcheck peut afficher de nombreux cas d'erreur différents. Aussi, certaines informations importantes sont présentées régulièrement. Pour faciliter l'utilisation du Healthcheck, cette section présente ces différentes informations et erreurs courantes, accompagnées de leur interprétation.
Différentes erreurs classiques et leurs explications:
- OK Un demon est eteint ou injoignable par le reseau
- OK Un module a redémarré
- OK Erreurs 500
- Erreurs graphite (ecriture et lecture)
- OK Décalage de temps
- OK Différence de version
- OK Spare
Le démon est configuré avec l'adresse "localhost"
Puisque les démons constituant une installation de Shinken Entreprise ont pour vocation à être utilisés dans une architecture distribuée, il ne faut pas définir les démons avec des adresses locales. Les démons vont devoir communiquer entre eux, il faut donc les configurer avec une adresse précise pour éviter tout problème dans une architecture distribuée.
Cette erreur est très fréquemment rencontrée dans le healthcheck puisque dans l'installation par défaut de Shinken Entreprise, les démons utilisent l'adresse localhost. Dès que des démons seront utilisés dans la même configuration sur plusieurs machines différentes, il est impératif d'utiliser des adresse précises.
|
Le démon est injoignable
Le Scheduler "scheduler-vm3" est injoignable.
Dans ce cas, on execute le healthcheck sur la machine vm3. On peut donc déduire que le démon est éteint.
Sur un démon hébergé sur une machine distante, il faudra d'abord déterminer si la machine est joignable avant de pouvoir affirmer que le démon est éteint. Un healthcheck local sur la machine hébergeant le démon peut confirmer cette hypothèse.
|
Le démon et son Arbiter ont des versions différentes
Pour garantir un bon fonctionnement, il faut que tous les démons présents dans la configuration possèdent la même version de Shinken Entreprise.
Dans ce cas, le poller "poller-domtom" et l'Arbiter n'ont pas la même version installée, ce qui peut provoquer des dysfonctionnements.
|
Décalage de temps entre 2 démons
Puisque Shinken Entreprise repose sur une architecture distribuée composée de plusieurs démons, la synchronisation de l'horloge entre les démons est un point important pour un bon fonctionnement du système.
Dans le healthcheck, si un démon ne possède pas la même heure que l'Arbiter, un erreur est affichée et indique le décalage horaire.
Dans l'exemple, le poller "poller-domtom" possède un décalage horaire de 4160 secondes avec l'Arbiter "arbiter-vm3".
|
Un démon est configuré en tant que Spare
Un démon peut être configuré en tant que Spare. Un démon Spare est par défaut inactif, et devient actif lorsqu'un démon principal n'est plus disponible, afin d'assurer une continuité du service.
Pour pouvoir identifier facilement les démons Spare dans l'architecture, une mention "Spare" est présente a coté du nom du démon.
|
Un module a redémarré de manière imprévue
Certains démons de Shinken Entreprise utilisent des modules qui permettent d'étendre leur fonctionnalités. Il arrive que ces modules redémarrent pour des raisons diverses et variées.
Lorsqu'un module a redémarré dans les 2 dernières heures, un avertissement est affiché pour le module en question, car il peut s'agir d'un problème récurrent et/ou potentiellement gênant. Un analyse des logs peut permettre d'avoir plus d'informations sur les erreurs du module.
|
Erreur de communication entre les démons
Les différents démons de Shinken Entreprise communiquent entre eux pour fonctionner. Il arrive que des erreurs de communications soient remarquées et génèrent des erreurs, qui sont alors notifiées dans le healthcheck dans la section du démon concerné.
Il est à noter que ces erreurs ne sont pas forcément fatales au bon fonctionnement de Shinken Entreprise, mais qu'elles nécessitent une attention particulière.
|
Erreurs de configuration concernant les données de métrologie
Dans une configuration avec plusieurs royaumes, il est plus difficile de vérifier que les données de métrologie sont bien écrite et peuvent être lues pour chaque royaume.
Il existe 2 types d'erreur:
- Les erreurs d'écriture
- Les erreurs de lecture
Dans l'exemple, le healthcheck nous indique qu'aucun Broker n'écrit de métrologie de données pour le royaume Corse.
Il faudra donc vérifier qu'il existe bien un module Graphite-Perfdata configuré sur au moins un Broker du royaume Corse.
|
Pour la lecture des données, l'erreur nous indique ici que dans la configuration, le serveur à utiliser pour la lecture des données ne contient pas de données de métrologie pour ce royaume.
|
Aussi, dans un royaume, pour des raisons de cohérence et pour éviter une corruption de données, il faut que tous les brokers soient configurés de la même manière pour les données de métrologie .
Dans l'erreur ci-contre, le healthcheck nous indique que les 2 broker "broker-corse" et "broker-corse-spare" ne sont pas configurés pour écrire leur données sur le même serveur:
- "broker-corse" n'écrit pas de données de métrologie
- "broker-corse-spare" écrit ses données sur le serveur 172.16.0.3
|
