Page History

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.

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 adresses précises.

Le démon est injoignable

Le Scheduler "scheduler-vm3" est injoignable.

Dans ce cas, on exécute 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 est en cours d'arrêt

Lorsque le démon est en cours d'arrêt, shinken-healthcheck le signale, et les informations relatives aux modules ne sont plus disponibles.

Le démon n'a pas encore reçu sa configuration de l'Arbiter

Lorsque de l'on démarre ou redémarre un démon, celui-ci demande sa configuration à l'Arbiter. Il est possible que l'Arbiter mette du temps à l'envoyer.

Dans ce cas un message " AT RISK " sera affiché indiquant que le démon n'a pas encore été contacté par l'Arbiter.

Le démon

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.

Conflit d'Arbiter sur un démon

Lors d'une mauvaise configuration, il arrive que 2 installations différentes de Shinken Entreprise pointent vers un même démon. Chaque Arbiter va détecter des incohérences, et ils vont constamment renvoyer des configurations (contradictoires entre elles) afin de les corriger, ce qui fait que le démon ne va jamais réussir à travailler correctement.

Dans ce cas, une erreur est affichée dans le shinken-healthcheck indiquant le conflit d'Arbiter.

Pour chaque Arbiter, sont donnés son nom ainsi que de quelle installation Shinken (Architecture) il provient afin de les retrouver et corriger immédiatement l'erreur de configuration.

La dernière connexion de l'Arbiter remonte à trop longtemps

La configuration de l'Arbiter n'a pas été trouvé

Ce message apparaît quand la commande healthcheck utilise l'option --locale ou -l et que la propriété  host_name  n'a été renseignée dans aucun fichier de configuration de ou des Arbiter(s).

Pour résoudre ce problème, il faut dans le fichier de configuration de l'Arbiter qui est présent sur cette machine (situé dans  /etc/shinken/arbiters/),  changer la propriété host_name  avec le nom de la machine (qui est trouvable grâce à la commande  hostname) 

Les serveurs ne sont pas à la même heure

Si le serveur n'est pas à la même heure que le serveur Arbiter (qui fait office de référence), une erreur CRITICAL sera levée, car des temps différents sur les différents serveurs vont avoir des effets désastreux sur la cohérence des données de supervision.

Un démon est bloqué et doit être redémarré

Si un démon arrive dans un état bloqué à cause d'un bug par exemple, il ne fonctionnera plus correctement et doit être redémarré. Vous aurez l'erreur suivante:

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 à côté 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.

Dans le cas d'un démon Broker, une ligne supplémentaire va être affichée afin d'indiquer de quel démon master il est le spare.

Un démon master a un démon spare de désigné ( seulement pour les Brokers )

Quand un démon master a un démon spare de désigné ( via sa propriété spare_daemon ) alors il sera listé.

Un démon master autorise son spare à ne pas avoir la même liste de modules

Quand un master autorise son spare à ne pas avoir la même liste de modules, via la propriété "broker__manage_spare__spare_must_have_the_same_list_of_module_type"

le texte entre parenthèses le précise ( voir la configuration du broker master )

Un démon master n'a pas de démon spare de désigné ( seulement pour les Brokers )

Quand un démon master n'a pas de démon spare, ceci sera affiché.

Un démon spare qui n'a pas de démon master ( seulement pour les Brokers )

Quand un démon spare n'est le spare d'aucun autre démon, il est noté comme inutilisé.

Informations et détections dans le cadre de virtualisation Vmware

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"

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

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, ou bien il passe trop de temps à lire les fichiers snapshots.

La valeur "CPU Stolen" en pourcentage est utilisée pour la détection. Si cette valeur :

• est située entre 5% et 10%, alors un message de type "AT RISK" apparaît
• si elle est supérieure ou égale à 10% alors un message de type "ERROR" apparaît.

Si vous recevez un de ces messages, plusieurs options sont possibles :

• Réduisez le nombre d'allocations de VCPU sur votre VM
• Augmentez vos ressources CPU physiques de vos ESXi
• Déplacer vos VM sur un autre serveur physique moins sollicité en terme CPU
• Réduisez le nombre de snapshots présents sur vos VMs

Pour plus de détail sur cet indicateur et des solutions pour réduire le CPU Stolen se référer à la page dédiée à ce sujet.

Le démon Gatherer n'est pas disponible

a chargé une configuration enregistrée

Lorsque le module last-configuration-recorder est actif, pour les démons de type :

• Broker,
• Poller,
• Reactionner,
• Receiver et
• Scheduler,

Au démarrage, le démon charge la précédente configuration qu'il a reçue de l'Arbiter, en attendant que ce dernier le contacte.

• Il permet un redémarrage du démon même si l'Arbiter ne peut pas joindre le démon ( ex : coupure réseau  )
• Cela permet aussi de rendre le redémarrage du démon plus rapide ( dans le cas où l'Arbiter n'a pas changé de version de configuration ).

Un message  " AT RISK " indique que le démon n'a pas encore été contacté par l'Arbiter

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.

Conflit d'Arbiter sur un démon

Lors d'une mauvaise configuration, il arrive que 2 installations différentes de Shinken Entreprise pointent vers un même démon. Chaque Arbiter va détecter des incohérences, et ils vont constamment renvoyer des configurations ( contradictoires entre elles ) afin de les corriger, ce qui fait que le démon ne va jamais réussir à travailler correctement.

Dans ce cas, une erreur est affichée dans le shinken-healthcheck indiquant le conflit d'Arbiter.

Pour chaque Arbiter, est donné son nom, son uuid, son adresse IP ainsi que de quelle installation Shinken ( Architecture ) il provient, afin de les retrouver et de corriger immédiatement l'erreur de configuration.

La dernière connexion de l'Arbiter remonte à trop longtemps

Si la dernière connexion de l'Arbiter remonte à trop de temps, le démon va lever un AT RISK . Ceci peut être dû :

• Les Arbiters MASTER et SPARE sont réellement éteints
• Les Arbiter MASTER et SPARE sont en train d'envoyer des configurations à d'autres démons, et ne peuvent donc pas contacter ce démon pour l'instant.

Le temps pris en compte comme limite de dernière connexion est de check_interval * max_check_attempts du démon ( définis dans sa configuration ). Les valeurs par défauts sont de 60s*3, soit 3 minutes.

La configuration de l'Arbiter n'a pas été trouvé

Ce message apparaît quand la commande healthcheck utilise l'option --locale ou -l et que la propriété  host_name  n'a été renseignée dans aucun fichier de configuration de ou des Arbiter(s).

Pour résoudre ce problème, il faut dans le fichier de configuration de l'Arbiter qui est présent sur cette machine (situé dans  /etc/shinken/arbiters/),  changer la propriété host_name  avec le nom de la machine ( qui est trouvable grâce à la commande hostname ) 

Les serveurs ne sont pas à la même heure

Si le serveur n'est pas à la même heure que le serveur Arbiter ( qui fait office de référence ), une erreur CRITICAL sera levée, car des temps différents sur les différents serveurs vont avoir des effets désastreux sur la cohérence des données de supervision.

Un démon est bloqué et doit être redémarré

Si un démon arrive dans un état bloqué à cause d'un bug par exemple, il ne fonctionnera plus correctement et doit être redémarré. L'erreur suivante est alors remontée :

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 à côté du nom du démon.

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

Dans le cas d'un démon Broker, une ligne supplémentaire va être affichée afin d'indiquer de quel démon master, il est le spare.

Un démon master a un démon spare de désigné ( seulement pour les Brokers )

Quand un démon master a un démon spare de désigné (via sa propriété spare_daemon ) alors, il sera listé.

Un démon master autorise son spare à ne pas avoir la même liste de modules

Quand un master autorise son spare à ne pas avoir la même liste de modules, via la propriété "broker__manage_spare__spare_must_have_the_same_list_of_module_type"

le texte entre parenthèses le précise ( voir la Le Broker )

Un démon master n'a pas de démon spare de désigné ( seulement pour les Brokers )

Quand un démon master n'a pas de démon spare, ceci sera affiché.

Un démon spare qui n'a pas de démon master ( seulement pour les Brokers )

Quand un démon spare n'est le spare d'aucun autre démon, il est noté comme inutilisé.

Informations et détections dans le cadre de virtualisation Vmware

Il est possible de virtualiser l'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 le 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 la VM ( Machine virtuelle ). Si ces derniers ne sont pas installés, alors une information sera affichée.

Il est conseillé de toujours avoir les "VM tools" installés, et à jour, sur l'ensemble du parc de VM.

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

RHEL / CentOS 7

RHEL / Alma / Rocky 8 et 9

Debian 13

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

Enfin, si la configuration de virtualisation ne permet pas à une machine virtuelle une utilisation correcte des CPU physiques de son hôte via les VCPU qui lui sont associées, alors une information sera affichée. Les VCPU n'arrivent pas à traiter assez rapidement toutes les demandes d'exécution, ou bien il passe trop de temps à lire les fichiers snapshots.

La valeur "CPU Stolen" en pourcentage est utilisée pour la détection. Si cette valeur :

• est située entre 5% et 10%, alors un message de type "AT RISK" apparaît
• si elle est supérieure ou égale à 10% alors un message de type "ERROR" apparaît.

Si un de ces messages survient, plusieurs options sont possibles :

• Réduire le nombre d'allocations de VCPU sur la VM
• Augmenter les ressources CPU physiques des ESXi
• Déplacer les VM sur un autre serveur physique moins sollicité en terme CPU
• Réduire le nombre de snapshots présents sur les VMs

Pour plus de détails sur cet indicateur et des solutions pour réduire le CPU Stolen se référer à la page Machine VMWare avec un fort taux de CPU Stolen (%ready + %costop).

Le démon Gatherer n'est pas disponible

La récupération des données de VMWare sont faites via le Gatherer qui écrit le fichier

/dev/shm/vmware_stats_export.dat que chaque démon va lire pour répondre au Shinken-healthcheck.

Si le Gatherer est éteint ( il est automatiquement démarré lorsqu'on démarre un démon shinken ), alors ce fichier ne sera plus mis à jour et les informations ne seront plus fiables.

Si le fichier n'est plus mis à jour depuis plus d'une minute, alors un "AT RISK" sera affiché sur le Shinken healtcheck.

Vérifier dans les logs du Gatherer ce qui est la source du problème, et ensuite, si besoin, relancer le Gatherer sur le serveur distant via la commande :

service-shinken-gatherer restart

Un module a redémarré de manière imprévue

Certains démons de Shinken Entreprise utilisent des modules qui permettent d'étendre leurs 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.

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.

Erreur d'encodage dans les fichiers de configuration d'un démon

Si les fichiers de configuration des démons situés dans /etc/shinken ne pas encoder en utf-8.

Dans l'exemple ci-contre le fichier arbiter-master.cfg ne respecte pas le bon encodage ( utf-8 ) et apparaît en erreur dans le résultat de la commande shinken-healthcheck.

Correction : Il suffit de réencoder le fichier au format utf-8

Un scheduler n'a pas de broker ou de poller ou de reactionner

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 besoin de ces autres démons pour fonctionner.

En cas de mauvaise configuration de démons et/ou de royaumes, un Scheduler peut ne pas être défini comme cible d'un autre démon ( Poller/Reactionner/Broker ).

Un module a mis trop de temps à répondre aux demandes d'informations/statistiques

En cas de surcharge d'un module, ce dernier peut mettre trop de temps pour répondre aux demandes d'informations ( 2 secondes, retentées une fois ), ce qui va faire une erreur au niveau du module.

Erreurs de cohérence de configuration entre une WebUI et ses modules de rapports

Le module webui__module_report_handler vérifie que les modules de génération de rapport ( broker__module_report_builder ) configurés sont accessibles et utilisables par la WebUI pour générer un rapport.

Cas 1 : Un des modules de génération de rapport n'est pas joignable

Cas 2 : La WebUI ne peut pas s'authentifier, avec le jeton configuré, a au moins un des modules de génération des rapports configurés

Cas 3 : Au moins un des modules de génération des rapports configurés n'appartient pas à la bonne architecture Shinken ( il dépend d'un autre Arbiter ) .

Cas 4 : Au moins un des modules de génération des rapports configurés n'est pas dans le bon royaume.

Cas 5 : Au moins un des modules de génération des rapports configurés n'utilise pas les paramètres de calcul pour les SLA de l'Interface de Visualisation.

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 écrites et peuvent être lues pour chaque royaume.

Il existe 2 types d'erreurs :

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

Les erreurs d'écriture

Cas 1 : Les données d'un royaume ne sont pas sauvegardées

C'est le cas, si le message suivant apparaît : 

[*] 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 Toulouse 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 Toulouse.

Correction : Ajouter le module Graphite-Perfdata sur le broker

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

C'est le cas, si le message suivant apparaît : 

[*] 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 ( France ) ont un même module graphite qui va écrire les données sur le même serveur graphite ( 192.168.1.23  )

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. Il faut donc :

• 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 ; consulter 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 prend 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 prend 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 * 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éfini dans la configuration Shinken.

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

Cas 5 : Le port de Graphite-Perfdata est invalide

Lors que le module Graphite-Perfdata est configuré avec un port qui n'est pas un port HTTP valide, l'erreur est remontée dans le shinken-healthcheck.

Correction : Changer le port de Graphite-Perfdata ( par défaut dans /etc/shinken/modules/graphite.cfg ) par un port HTTP valide.

Cas 6 : Le nom de l'hôte de Graphite-Perfdata est invalide

Lorsque le module Graphite Perfdata est configuré avec un hôte vide, une erreur est remontée dans le shinken-healthcheck

Correction : Changer le nom d'hôte dans la configuration de Graphite Perfdata ( par défaut dans /etc/shinken/modules/graphite.cfg ) par un nom d'hôte ou une adresse IP valide

Les erreurs de lecture

Cas 1 : La configuration du module webui.cfg précise un royaume qui n'existe pas

C'est le cas, si le message suivant apparaît : 

Realm [*] : This realm is an unknown realm. Know realms are : *

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

    graphite_backends         Bordeaux:192.168.1.23, France:192.168.1.23

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

    graphite_backends         *:192.168.1.23:80

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

C'est le

Un module a redémarré de manière imprévue

Certains démons de Shinken Entreprise utilisent des modules qui permettent d'étendre leurs 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.

Erreur de communication entre les démons

Erreur d'encodage dans les fichiers de configuration d'un démon

Si les fichiers de configuration des démons situés dans /etc/shinken ne pas encodé en utf-8.

Dans l'exemple ci-contre le fichier arbiter-master.cfg ne respecte pas le bon encodage ( utf-8 ) et apparaît en erreur dans le résultat de la commande shinken-healthcheck.

Correction : Il vous suffit de réencoder le fichier au format utf-8

Un scheduler n'a pas de broker ou de poller ou de reactionner

Un module a mis trop de temps à répondre aux demandes d'informations/statistiques

En cas de surcharge d'un module, ce dernier peut mettre trop de temps pour répondre aux demandes d'informations ( 2 secondes, retentées une fois ), ce qui va faire une erreur au niveau du module.

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 écrites et peuvent être lues pour chaque royaume.

Il existe 2 types d'erreurs:

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

Les erreurs d'écriture

Cas 1 : Les données d'un royaume ne sont pas sauvegardé

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

[*] 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 Toulouse 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 Toulouse.

Correction : Ajouter le module Graphite-Perfdata sur le broker

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

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

Realm [*] : This realm iscan't stored on same backendsbe accessed by multiple brokers : bythe broker * on graphite *(*) and by broker * on graphite * (*)

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

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

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

Cas 5 : Le port de Graphite-Perfdata est invalide

. It can access to : *

Il y a 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-royaumes 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

C'est le cas, si le message suivant apparaît :

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

C'est le cas, si le message suivant apparaît :

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

C'est le cas, si le message suivant apparaît :

Lors que le module Graphite-Perfdata est configuré avec un port qui n'est pas un port HTTP valide, l'erreur est remontée dans le shinken-healthcheck.

Correction : Changer le port de Graphite-Perfdata ( par défaut dans /etc/shinken/modules/graphite.cfg ) par un port HTTP valide.

Cas 6 : Le nom de l'hôte de Graphite-Perfdata est invalide

Lorsque le module Graphite Perfdata est configuré avec un hôte vide, une erreur est remontée dans le shinken-healthcheck

Correction : Changer le nom d'hôte dans la configuration de Graphite Perfdata ( par défaut dans /etc/shinken/modules/graphite.cfg ) par un nom d'hôte ou une adresse IP valide

Les erreurs de lecture

Cas 1 : La configuration du module webui.cfg précise un royaume qui n'existe pas

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

Realm [*] : This No graphics will be displayed as this realm is annot unknownpresent realm. Know realms are : *

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

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éder aux métriques sur les hôtes du royaume Reunion sur la webui webui-02-validation16-01

    graphite_backends         BordeauxCorse:192.168.1.2353, France:192.168.1.23

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

    graphite_backends         *:192.168.1.23:80

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