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
Graphite
Comment interpréter les erreurs courantes du Healthcheck
Différentes erreurs classiques et leurs explications:
- Un demon est eteint ou injoignable par le reseau
- Un module a redémarré
- Erreurs 500
- Erreurs graphite (ecriture et lecture)
- Décalage de temps
- Différence de version
- Spare
Données de sortie
La sortie de la commande est constituée de plusieurs parties:
- Architecture: au sujet de la configuration des démons. On retrouve pour chaque démon
- son type, son nom et le fait d'être configuré en spare
- la configuration est elle valide
- la connexion vers le démon est elle valide
- la version est elle la même que celle de l'arbiter
- le démon communique t'il bien avec l'arbiter et à il la même heure que celui-ci
- dans le cadre de poller et reactionner, la tag list, ainsi que les erreurs pouvant intervenir sur les workers
- les modules du démon sont ils bien configurés
- la communication avec autres démons est elle opérationnel
- Libs: au sujet des librairies installées et nécessaires à Shinken Enterprise
- Licence key: au sujet de votre clé de licence
- Modules:au sujet des Interfaces Utilisateurs
- Storage: au sujet du stockage dans mongodb et dans graphite
Il y a 3 niveaux en sortie:
- 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.
Exemple d'informations envoyées
Voici un extrait de vérification pour un démon :
|
On peut voir ici deux problèmes :
- Le broker ici configuré est en adresse "localhost". C'est cette adresse qui est distribué aux démons pour contacter le broker, ce qui signifie qu'avec cette adresse, aucun démon distant ne pourra contacter ce broker
- Un sous-module, ici l'authentification active-directory, est en erreur
- Par ailleurs le démon est dans la bonne version, contacte correctement les autres satellites, et n'a pas de décalage temporel avec l'arbiter.