Qu'est-ce que le Health Check ?
Le Healthcheck est une commande présente dans toute installation Shinken Entreprise qui permet de vérifier 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 Healthcheck 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 fournissent 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). Par défaut sur une machine avec un Arbiter et un Synchronizer, un Healthcheck global est effectué sauf si un Healthcheck 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 | Écrit 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) | |
| --show-history | Affiche l'historique des installations et données de Shinken Entreprise sur ce serveur |
La commande Shinken-healthcheck sépare sa vérification en plusieurs parties qui sont décrites dans les sections suivantes.
Lancement centralisé de toute l'architecture ou local uniquement
La commande Shinken-healthcheck peut être utilisée dans deux modes de fonctionnements différents :
- Vérification globale de toute l'architecture
- Ce mode est le mode par défaut de la commande
- La commande vérifie l'ensemble des serveurs à distance et local, telle que définie dans ses fichiers cfg
- Peut être lancé avec l'option --global ou -g
- Vérification locale
- Ce mode vérifie que les démons locaux à la machine, sans vérifier les notions de royaumes
- Ce mode est automatiquement sélectionné quand:
- On est sur le serveur de l'arbiter spare
- On est sur un serveur qui n'a pas d'arbiter
- Peut être lancé avec l'option --local ou -l
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. S’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").
- État 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 nœuds 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 du statut du chiffrement des champs protégés
La sous-section Encryption status donne des informations sur le chiffrement des champs protégés :
- Protection activée ou pas (et nom de la clé si elle est activée)
- Si la clé n'a pas été sauvegardée ou si la clé ne peut pas être chargée, une erreur est affichée
- S’il y a une incohérence de configuration du chiffrement ( voir la page Mécanismes de sécurisation des données), le message d’erreur correspondant sera affiché.
|
Vérification des espaces de stockage
Graphite
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 Brokers sont dans un même royaume, il faut s'assurer que les Brokers n'écrivent pas 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 broker lisent les données de métrologie de tous les royaumes et sous-royaume que le broker gère, 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 pour ce royaume.
La commande shinken-healthcheck possède une section dédiée à la vérification des espaces de stockage des données de métrologie, qui vérifie que les brokers de chaque royaume sont configurés pour sauvegarder les données, que tous les modules Webui sont configurés correctement pour lire les données stockées dans les serveurs graphite de chaque royaume ou sous-royaume et que les serveurs de métrologie sont effectivement joignables et aptes à sauvegarder des données.
Vérification de la configuration de la sauvegarde des données de métrologie
La première section de la vérification vérifie qu'il y au moins un broker pour chaque royaume ou sous-royaume configuré pour sauvegarder les données de métrologie.
Dans l'exemple ci-contre, nous pouvons voir qu'il y a un broker configuré par royaume, pour sauvegarder les données métrologie sur trois serveurs graphite différents
- Les données métrologie du royaume Metropole sont stockées par le broker broker-metropole-02 sur le serveur graphite 172.16.0.181
- Les données métrologie du royaume Corse sont stockées par le broker broker-corse sur le serveur graphite 192.168.1.24
- Les données métrologie du royaume Reunion sont stockées par le broker broker-reunion sur le serveur graphite 192.168.1.148
Si un royaume n'est configuré sur aucune Broker sauvegardant les données de métrologie, une erreur sera affichée.
On note que s'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.
Vérification de la configuration pour la lecture des données de métrologie
Cette section vérifie que chaque module webui à un serveur graphite de configuré pour chaque royaume (ou sous royaume) que gère le broker.
Si le royaume comporte plusieurs Brokers, le healthcheck vérifie que tous les Brokers ont ont une configuration différente en ce qui concerne le serveur Graphite à utiliser pour récupérer les données de métrologie.
Dans l'exemple ci-contre, nous pouvons voir que la vérification de configuration de la lecture s'effectue pour module webui de chaque broker et que pour chaque module, la commande shinken-healthcheck test la configuration pour les différents royaumes présent sur le broker.
Si un royaume est inconnu ou non géré par le broker, la vérification retournera une erreur pour ce royaume.
Vérification du bon fonctionnement des serveurs graphite
Cette section vérifie que tous les serveurs graphite configuré dans les brokers sont joignables et qu'ils permettent bien de lire et d'écrire les données de métrologie
Ainsi, pour chaque serveur, la commande shinken-healthcheck demande au Broker d'essayer d'effectuer une écriture et une lecture de données, et affiche le résultat (nombre d'hôte sauvegardé).
Dans cette exemple ci-contre, nous voyons que pour chaque serveurs graphite, la commande vérifie que les brokers qui sont associé à ce serveur arrive à :
- Joindre le serveur
- Ecrire des données
- Lire des données
Affichage lorsque la gestion des données de performance est désactivé
Lorsque dans la configuration avancé de shinken (shinken.cfg) l'option de gestion des données de performance (process_performance_data) est désactivé, la section "graphite" de la commande shinken-healthcheck va :
- Informer que la fonctionnalité de gestion des données de performance est désactivé
- Mettre un AT RISK pour chaque broker ayant un module "graphite_perfdata" configuré
|
Vérification des addons
La section suivante du Healthcheck affiche l'état des différents addons actifs sur la machine.
La liste des addons actuellement activés est affichés, avec pour chacun, leur statut ainsi que l'état de différentes vérifications.
Puisque les addons peuvent avoir chacun un fonctionnement différent, les vérifications effectuées différent selon l'addon.
|
Structure des royaumes
La dernière section du Healthcheck l'état de la structure des royaumes.
Si la configuration des royaumes est erronée, les autres vérifications ne sont pas faites et seule cette erreur est affichée.
La copie d'écran montre une erreur, car deux royaumes ont été définis comme royaumes par défaut.
Historique des installations et de la configuration
Le Healthcheck affiche par défaut la version initiale d'installation ainsi que la version actuellement installée.
Il est possible d'obtenir des informations supplémentaires sur l'historique de l'installation en utilisant l'option "--show-history" de la commande "shinken-healthcheck":
shinken-healthcheck --show-history |
Ce paramètre affiche des informations sur l'évolution de Shinken Entreprise depuis son installation initiale.
L'utilisation de cette option est surtout pratique lorsque vous communiquez avec le support Shinken, qui utilisera les informations remontées pour plus facilement retrouver l'origine de votre problème.
Historique des mises à jour
L'option --show-history affiche d'abord une liste triée chronologiquement des différentes versions de Shinken installées sur la machine courante.
On peut donc voir facilement, pour une date donnée, quelle était la version de Shinken installée.
Cette option est également utile pour communiquer avec le support Shinken, pour détecter des erreurs de configuration liées à des anciennes versions de Shinken.
Historique des données
Après l'historique des installations vient l'historique des données présentes dans Shinken. Cet historique de données est séparé en plusieurs sections correspondant chacune à un type de donnée différente:
- Configuration (configuration de Shinken, élément de supervision)
- SLA (historique des états des éléments supervisés et données de SLA)
- Métrologie (métriques)
- Données utilisateurs (données sauvegardées dans l'interface de visualisation)
On dispose encore d'une liste chronologique présentant les différentes opérations effectuées sur les données:
- Mise à jour
- Restauration d'une sauvegarde
- Exécution du script de nettoyage des données, qui retravaille la configuration automatiquement lors d'une mise à jour pour la rendre compatible avec les dernières versions de Shinken Entreprise
- Installation et désinstallation d'un patch
- Installation et désinstallation d'un add-on
Historique des paramètres de chiffrement des données
Le dernier type d'information remonté par l'option --show-history est l'historique des paramètres de chiffrement des données sensibles.
A chaque fois que les paramètres de chiffrement sont modifiés et déclenchent un changement dans le chiffrement des données (activation, désactivation, changement des champs chiffrés), une entrée sera ajoutée dans la liste des modifications.
L'état d'activation, le nom de la clé utilisée, l'état de sauvegarde de la clé ainsi que la liste de définition des données à chiffrer sont affichés pour chaque entrée de la liste.
Notez que le statut de sauvegarde de la clé peut être différent du statut affiché dans la section [Encryption Status] :
- dans la section [Encryption Status], shinken-healthcheck affiche l'état actuel.
- dans l'historique, shinken-healthcheck affiche l'état au moment de la modification de la configuration.
Seuls les cinq derniers changements sont conservés.
|
