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 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

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.

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.

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
• Si 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ée.

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.

Cette section vérifie que chaque module webui à un serveur graphite de configuré pour chaque royaume (ou sous royaume) que gère le broker.

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.

Cette section vérifie que tous les serveurs graphite configurés 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és à ce serveur arrive à : 

• Joindre le serveur,
• Ecrire des données,
• Lire des données.

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.

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.

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.

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

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.

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 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.

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.

Lors d'un mauvaise configuration, il arrive que 2 installations différentes de Shinken Entreprise utilisent les démons du même serveur.

Dans ce cas, plusieurs Arbiters envoient une configuration contradictoire au même démon. Dans ce cas, une erreur est affichée dans le healthcheck indiquant le conflit d'Arbiter.

Pour chaque Arbiter, le nom et l'adresse de l'Arbiter concerné sont également indiqués.

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 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.

Si le démon prend la main afin d'assurer la continuité de service, alors une mention additionnelle "RUNNING" est affichée.

Il se peut que vous décidiez de virtualiser votre architecture Shinken, ou simplement quelques uns des démons, avec VMWare.

Si c'est le cas, une ligne sera ajoutée dans la sortie du "shinken-healthcheck" et précisera que votre satellite fonctionne sur une architecture VMWare.

Une vérification sera faite sur la présence ou non des "VMWare tools" sur votre VM (Machine virtuelle). Si ces derniers ne sont pas installés, alors une information sera affichée.

Nous vous conseillons de toujours avoir vos VM tools installés, et à jour, sur l'ensemble de votre parc de VM.

Ces utilitaires peuvent être installés via le paquet "open-vm-tools":

yum install open-vm-tools

Enfin, si votre configuration de virtualisation ne permet pas à votre machine virtuelle une utilisation correcte des CPU physiques de son hôte via les VCPU que vous avez associés à celle ci, alors une information sera affichée. Vos VCPU n'arrivent pas à traiter assez rapidement toutes les demandes d'exécution.

La valeur "stolen CPU" en pourcentage est utilisée pour la détection. Si cette valeur dépasse 15%, alors un message de type "AT RISK" apparaît.

Si vous recevez ce message, plusieurs options sont possibles :

• Réduisez le nombre d'allocation de VCPU sur votre VM
• Augmentez vos ressources CPU pour vos VM
• Déplacer vos VM sur un autre serveur physique moins sollicité en terme CPU

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.

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.

Les schedulers prodisent des jobs à effectuer pour les pollers/reactionners, ainsi que des données pour les brokers (par exemple pour l'interface de visualisation).Ils ont donc besoins de ces autres daemons pour fonctionner.

En cas de mauvaise configuration de daemons et/ou de royaumes, un scheduler peux ne pas être défini comme cible d'un autre daemon (poller/reactionner/broker).

Cas 1 : Les données d'un royaume ne sont pas sauvegardé
[*] There is no broker configured to write data for this realm. This realm might produce data that are not stored anywhere (no Graphite backend configured)

Exemple : Un broker dans le royaume Corse qui n'a pas de module graphite, mais il a un module webui, il n'y a donc pas de broker qui sauvegarde les données du royaume Corse.

Correction : Ajouter le module Graphite-Perfdata sur le broker

Cas 2 : Plusieurs broker du même royaume écrivent dans une même base graphite

[*] This realm is stored on same backends by multiple brokers : by broker * on graphite *(*) and by broker * on graphite * (*)

Exemple : Deux brokers sur le même royaume (Metropole) ont un même module graphite qui va écrire les données sur le même serveur graphite (172.16.0.181)

Toutes les métriques sont reçues et gérées par le broker. Chaque broker écrira donc les données dans le serveur graphite. Il y aura donc des données en double sur le serveur graphite.

Correction : Un seul broker doit écrire les données d'un royaume sur un serveur graphite. Vous pouvez :

• Enlever le module graphite_perfdata d'un des deux brokers
• créer un deuxième module graphite_perfdata qui écrira les données sur un serveur graphite différent. Afin de mettre en place de la haute disponibilité pour la base de métrologie; consultez la page Haute disponibilité de la base de métrologie (Graphite)

Cas 3 : le module graphite sauvegarde uniquement des royaumes différents de celui du broker

Broker * has module* with realm [*] in parameter realm_store_only, but this broker handle only realms : *

Le broker à un module graphite_perfdata qui sauvegarde les données uniquement pour un royaume qui est différent de celui ou ceux que le broker gère. Les royaumes gérés par le module sont cités dans le paramètre "realm_store_only". Si ce paramètre est commenté ou absent, le module prends en compte tous les royaumes que le broker gère.

Correction : Il faut changer le module de type graphite_perfdata pour un autre module qui gère le/les mêmes royaumes que le broker. Il est possible de mettre un module graphite_perfdata qui prends tous les royaumes (paramètre realm_store_only commenté).

Cas 4 : le paramètre realm_store_only contient un royaume qui n'existe pas

Module Graphite_Corse has realm [*] in parameter realm_store_only but this realm is unknown

Le paramètre "realm_store_only" contient un royaume qui n'est pas définit dans la configuration shinken.

Correction : vérifiez qu'il n'y a pas d'erreur dans le ou les noms de royaumes qui sont définit dans le paramètre "realm_store_only" dans le module graphite_perfdata cité dans la ligne d'erreur.

Cas 1 : La configuration du module webui.cfg précise un royaume qui n'existe pas
Realm [*] : This realm is an unknown realm. Know realms are : *

Exemple : Dans le fichier /etc/shinken/module/webui.cfg la configuration précise un royaume qui n'existe pas

    graphite_backends         corse:192.168.1.53, Reunion:192.168.1.148, Metropole:172.16.0.181

Correction : Préciser un nom de royaume qui existe 

    graphite_backends         Corse:192.168.1.53, Reunion:192.168.1.148, Metropole:172.16.0.181

Cas 2 : La configuration du module webui.cfg précise un royaume non géré par le broker

Realm [*] : This realm can't be accessed by the broker *. It can access to : *

Il y deux cas possibles :

Exemple 1 : le broker ne gère pas les sous royaume, mais dans la configuration du module webui est précisée l'adresse d'un royaume fils

Exemple 2 : le broker broker-reunion reçoit un module Webui_Reunion est configuré pour le royaume corse dont il ne s'occupe pas.

Correction :

• le royaume qui ne peut être accessible est un sous royaume du royaume qui est géré par le broker. Dans ce cas, il suffit de dire au broker de gérer les sous-royaumes : ajouter la gestion des sous royaume par le broker dans /etc/shinken/brokers/broker-master3.cfg

manage_sub_realms        1

• Le royaume n'est pas un sous royaume, il faut enlever le royaume non géré du module webui. Il est possible de spécifier le caractère * dans la définition des backend afin de dire que ce module webui prendra tous les royaumes et sous-royaumes du broker vers le même graphite_backend

Cas 3 : Le serveur graphite précisé dans la configuration de webui ne gère pas les données de ce royaume
Realm [*] : The Graphite server on * does not contain data for this realm

Exemple : Le serveur graphite qui est sur 192.168.1.53 sauvegarde uniquement les données du royaume Corse. Cependant, le broker broker-metropole-01 est configuré avec une webui qui va lire les données pour le royaume Metropole sur le serveur graphite 192.168.1.53.

 graphite_backends         Corse:192.168.1.53, Reunion:192.168.1.148, Metropole:192.168.1.53

Correction : Préciser un serveur qui gère les données du royaume Metropole: 

 graphite_backends         Corse:192.168.1.53, Reunion:192.168.1.148, Metropole:172.16.0.181

Cas 4 : Le serveur graphite précisé dans la configuration de webui n'est pas un serveur graphite connu 
The server on * is not a known Graphite server : There is no module graphite_perfdata that writes data on backend *

Exemple : La configuration de webui précise que les données du royaume Metropole sont sur 172.16.0.182 qui n'est pas un serveur graphite connu  (aucun module graphite_perfdata n'est configuré pour écrire des données sur ce serveur)

 graphite_backends         Corse:192.168.1.53, Reunion:192.168.1.148, Metropole:172.16.0.182

Correction : Préciser un serveur qui gère les données du royaume Metropole : 

 graphite_backends         Corse:192.168.1.53, Reunion:192.168.1.148, Metropole:172.16.0.181

Cas 5 : Le broker gère des royaumes qui ne sont pas configurés dans les graphite_backends de la webui

Realm [*] : No graphics will be displayed as this realm is not present in "graphite_backends" parameter

Exemple : Le broker broker-metropole-01 gère le royaume Metropole et ses deux sous-royaume Reunion et Corse. Dans la définition de la webui webui-02-validation16-01, le royaume Reunion est manquant. On ne pourra donc pas accèdez au métriques sur les hôtes du royaume Reunion sur la webui webui-02-validation16-01

 graphite_backends         Corse:192.168.1.53, Metropole:172.16.0.181

Correction : Il faut ajouter le royaume manquant spécifiquement, ou bien mettre le caractère * pour indiquer que tous les royaumes se situent sur le même serveur

 graphite_backends         Corse:192.168.1.53, Reunion:192.168.1.148, Metropole:172.16.0.181

Cas 6 :Le broker rencontre des erreurs pour lire les données sur les serveurs graphite

Graphite read error happened * times during the last 24h, check the /opt/graphite/storage/whisper read access on the graphite host

Le broker a rencontré des erreurs lors des dernières 24heures pour lire des métriques.

Correction : Il faut consulter les logs du broker concerné afin de connaître la nature de l'erreur. (problème de droits sur les dossier de stockage u serveur graphite)