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'une 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. Une erreur est alors 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 à 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.

Détection de la présence des "VMWare tools"

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

Détection d'un pourcentage élevé de "stolen CPU"

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. Une 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 produisent 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 correctement.

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

Dans une configuration avec plusieurs royaumes, il est plus difficile de vérifier que les données de métrologie sont bien écrites et peuvent être lues pour chaque royaume.

Il existe 2 types d'erreur:

• Les erreurs d'écriture
• Les erreurs de lecture

Vous êtes dans ce cas, si le message suivant apparaît : 

This realm might produce data that are not stored anywhere (no Graphite backend configured)

Dans notre exemple : Un broker dans le royaume France 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 France.

Correction : Ajouter le module Graphite-Perfdata sur le broker

Vous êtes dans ce cas, si le message suivant apparaît : 

Brokers for this realm have different Graphite backends

Dans notre exemple : Un broker et son spare dans le royaume Corse avec la configuration par défaut du module Graphite-Perfdata

Correction : Pour garder la cohérence des données, il faut que le broker et son spare écrivent dans la même base. Il faut donc définir un nouveau module.

Dans notre exemple il faut créer le module Graphite-Perfdata-Corse :

define module {
    #======== Module identity =========
    # Module name. Must be unique
    module_name                  Graphite-Perfdata-Corse

    # Module type (to load module code). Do not edit.
    module_type                 graphite_perfdata

    #======== Graphite address =========
    # host:  graphite server address (ip or fqdn)
    host                        broker-master-3

    # port:  tcp port of the graphite server
    port                        2003

}

Puis l'ajouter dans les 2 brokers : /etc/shinken/broker/broker-master3.cfg et /etc/shinken/broker/broker-master5.cfg

modules                   Simple-log, WebUI, sla, Livestatus, Graphite-Perfdata-Corse

Vous êtes dans ce cas, si le message suivant apparaît : 

Realm * is an unknown realm.

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

 graphite_backends         fr:212.47.233.21,*:127.0.0.1

Correction : Préciser un nom de royaume qui existe.

Dans notre exemple, ce sera le royaume "France": 

 graphite_backends         France:212.47.233.21,*:127.0.0.1

Vous êtes dans ce cas, si le message suivant apparaît : 

Realm * can't be accessed by the broker *

Dans notre exemple : Broker-master3 ne gère pas les sous royaume, mais dans la configuration du module webui est précisée l'adresse d'un royaume fils.

Correction : Ajouter la gestion des sous royaume à votre broker en passant à une la propriété manage_sub_realms.

Dans notre exemple, il faut modifier /etc/shinken/brokers/broker-master3.cfg

manage_sub_realms        1

Vous êtes dans ce cas, si le message suivant apparaît : 

Realm * does not have any broker which write graphite data

Dans notre exemple : Broker-master3 sur le royaume n’écrit pas les données du royaume "France" à cause de la configuration de son module graphite.

realm_store_only     Corse,Bordeaux

Correction : Autoriser son module graphite à sauvegarder tout les royaumes.

Vous êtes dans ce cas, si le message suivant apparaît : 

The Graphite server on * does not contain data for this realm

Dans notre exemple : le serveur 212.47.233.21 gère que les royaumes Sudouest et Bordeaux mais la configuration de webui précise que les données de Corse sont sur 212.47.233.21.

 graphite_backends         Corse:212.47.233.21, *:127.0.0.1

Correction : Préciser un serveur qui gère les données du royaume qui pose problème.

Dans notre exemple, l'adresse 163.172.153.106 qui gère les données du royaume "Corse" :

 graphite_backends         Corse:163.172.153.106, *:127.0.0.1

Vous êtes dans ce cas, si le message suivant apparaît : 

The server on * is not a known Graphite server

Dans notre exemple : La configuration de webui précise que les données du royaume "Corse" sont sur le serveur "toto" qui n'est pas un serveur graphite connu.

 graphite_backends         Corse:toto, *:127.0.0.1

Correction : Préciser un serveur qui gère les données du royaume posant problème. 

Dans notre exemple, on ajoute un serveur (163.172.153.106) qui gère les données du royaume "Corse" :

 graphite_backends         Corse:163.172.153.106, *:127.0.0.1

Enfin, les erreurs de graphites sont maintenant comptés par le module Webui et elle sont retournées dans les erreurs de lecture.