Qu'est-ce que le shinken-healthcheck ?

Le shinken-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 shinken-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 sa propre supervision, par exemple des indicateurs de performance.

Usage

Principales options

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

L'option --version ou -v nous donnes les informations suivantes :

• Original installed version : C'est la toute première version de Shinken qui a été installée
• Updated version : C'est la version actuelle de Shinken
• Updated patch : C'est le nom du patch actuellement installé. Si aucun patch est installé, alors cette ligne ne s'affiche pas

Vérification de l'architecture

Etat des démons

La commande shinken-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 qu'un ou plusieurs Arbiters sont en conflit.
• 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.

Cas spécifique au Synchronizer - Vérification du statut du chiffrement des propriétés et données protégées

La sous-section "Encryption status" donne des informations sur le chiffrement des propriétés et données protégées :

• 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 du chiffrement ), le message d’erreur correspondant sera affiché.

Royaumes et sous-royaumes

Dans une configuration de Shinken Entreprise, les démons peuvent être répartis sur plusieurs machines.

Dans la commande shinken-healthcheck, les démons sont regroupés en fonction de la machine sur laquelle ils sont installés.

On voit dans l'exemple ci-dessous 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).

Vérification de la licence

Cette section du shinken-healthcheck affiche des informations sur la licence en cours.

A noter que cette section ne s'affiche que sur les serveurs hébergeant un Arbiter ou un Broker.

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 shinken-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 espaces de stockage

Graphite

S hinken 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 vérifier 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.

Pour cette partie, nous allons utiliser une configuration avec un royaume par défaut (Metropole) et deux sous royaumes (Corse et Reunion).

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 a 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 deux serveurs graphite différent :

• Les données métrologie du royaume France sont stockées par le broker broker-france sur le serveur graphite 192.168.1.23
• Les données métrologie du royaume Bordeaux sont stockées par le broker broker-bordeaux sur le serveur graphite 192.168.1.131

Si un royaume n'est configuré sur aucun 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 s'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 a configuré pour chaque royaume ( ou sous royaume ) un serveur graphite que gère le broker.

Dans l'exemple ci-dessous, 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 teste la configuration pour les différents royaumes présents 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 présente tous les serveurs graphite répertoriés lors de la lecture de la configuration. Un serveur est déterminé par les modules de type "graphite_perfdata" utilisés et également par les graphite_backend de chaque module de type "webui" utilisées.

Chaque serveur graphite est identifié de manière unique par son adresse IP : il est possible que le module "graphite_perfdata" utilise un nom DNS et le module "Webui" une adresse IP. Si les modules utilisent l'adresse de boucle locale ( 127.0.0.1 ), elle sera également remplacée par l'adresse IP du broker sur lequel il tourne.

Pour chaque serveur deux catégories sont affichées : la partie écriture et la partie lecture.

La partie écriture ( Write connexion status ) affiche :

• Le port utilisé pour la communiquer avec le service carbon-cache.
• L'état de la connexion pour chaque module de type "graphite_perdata" qui est configuré pour écrire sur ce serveur.
• Le port utilisé par ce serveur est affiché en information si les connexions des modules sont OK ( sinon il sera absent ).
• Les royaumes qui sont écrits sur ce serveur sont affichés en information si les connexions des modules sont OK ( sinon il sera absent ).
• Si aucun module n'écrit d'information, cela sera affiché en AT RISK .

La partie lecture ( Read connection status ) affiche :

• Le port utilisé pour la communiquer avec le service Graphite.
• L'état de la connexion pour chaque module de type "Webui" qui est configuré pour lire des données sur ce serveur.
• Le nombre d'hôtes qui est accessible sur ce serveur est affiché en information si les connexions des modules sont OK ( sinon il sera absent ).
• Si aucun module ne lit d'informations sur ce serveur, cela sera affiché en AT RISK .

Affichage lorsque la gestion des données de performance est désactivé

Lorsque dans la configuration ( voir la page Configuration avancée ( shinken.cfg ) ), l'option de gestion des données de performance ( process_performance_data ) est désactivée, la section "graphite" de la commande shinken-healthcheck va :

• Informer que la fonctionnalité de gestion des données de performance est désactivée
• Mettre un AT RISK pour chaque broker ayant un module " graphite_perfdata" configuré

Vérification des addons

La section suivante du shinken-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 shinken-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 shinken-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 et désinstallé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 à d’anciennes versions de Shinken.

Description des champs de la sortie de l'historique :

Historique des données

Après l'historique des installations vient l'historique des données de Shinken. Cet historique des données est séparé en plusieurs sections correspondantes 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
• Modules : configuration des modules

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.

À 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 des définitions 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.

Comment interpréter les informations et erreurs courantes du shinken-healthcheck

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

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.

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

Ce message apparaît quand la commande shinken-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 )

Décalage de temps entre 2 démons

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 shinken-healthcheck, si un démon ne possède pas la même heure que l'Arbiter, une 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 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 page 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 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 avec 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, 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 Machine VMWare avec un fort taux de CPU Stolen (%ready + %costop) .

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

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

Haute disponibilité de la base de métrologie (Graphite)

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

[*] 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 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 ( 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

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érifiez qu'il n'y a pas d'erreur 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

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

Realm [*] : This realm can't be accessed by the broker *. 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

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éder aux 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

Dans le cas où le royaume n'a pas de graphite backend mais qu'il n'a pas d'hôtes, alors le message change et devient un " AT RISK " car il est nécessaire d'avoir des hôtes pour l'affichage des graphiques :

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 24 heures 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 dossiers de stockage du serveur graphite).

Cas 7 : Le port de Graphite n'est pas correct

The Graphite backend [ GRAPHITE_BACKEND ] is_incorrect : The port [ HTTP_PORT ] is not valid. Valid values are integers from 0 to 65535.

Quand un port incorrect est utilisé dans le graphite backend, une erreur est remontée dans le shinken-healthcheck pour nous l'indiquer.

 graphite_backends         *:192.168.1.23:invalid

Correction : Il faut changer le port du "graphite_backend" concerné par un port qui existe ( un entier compris entre 0 et 65535 inclus )

 graphite_backends         *:192.168.1.23:8080

Cas 8 : L'adresse locale des serveurs de lecture ou d'écriture de Graphite n'a pas pu être résolu

Lorsqu'un graphite_backends d'un module WebUI ou qu'un module Graphite-Perfdata utilise une adresse locale ( localhost ou 127.0.0.1 ), il est possible que le shinken-healthcheck n'arrive pas à résoudre son adresse IP ( remplacer localhost ou 127.0.0.1 par sa réelle IP )

 graphite_backends         *:localhost

host                       localhost

Dans ce cas, on remplace l'adresse par _127.0.0.1_ et l'on averti que son IP locale n'a pas pu être résolue :

Correction : L'erreur provient du fait que le shinken-healthcheck a eu un problème lors de l'ouverture de socket. Cela peut provenir de la configuration réseau du serveur.

Cas 9 : Aucune adresse n'a été fournie dans le graphite_backends

The Graphite backend [ GRAPHITE_BACKEND ] is incorrect : The hostname or IP address is empty or not found.

Si dans un graphite_backends, une adresse n'a pas de nom d'hôte ou d'adresse IP, une erreur est remontée dans le shinken-healthcheck :

 graphite_backends         *::80

Correction : Corriger l'adresse en question pour rajouter une adresse IP ou on nom de l'hôte.

Cas 10 : Aucun royaume n'a été précisé dans le graphite_backends

The Graphite backend [ GRAPHITE_BACKEND ] is incorrect : Format error detected. It needs at least a realm and a hostname : <REALM>:<HOSTNAME>

Si un des backends renseigné dans la WebUI n'a pas le bon format, un message d'erreur nous averti qu'un backend n'est pas correct en plus de montrer un rappel du format.

Exemple de configuration incorrecte :

 graphite_backends         *:162.168.1.23:80, 192.168.1.23

Correction : Enlever le backend problématique ou rajouter les informations manquantes ( Royaume ou adresse )

Cas 11 : Le protocole utilisé dans le Graphite backend n'est pas correct

The Graphite backend [ GRAPHITE_BACKEND ] is incorrect : The protocol [ PROTOCOL ] is unknown

Lorsque le protocole du Graphite backend n'est pas valide, un message d'erreur est remonté dans la catégorie correspondante.

Exemple de configuration incorrecte :

 graphite_backends         *:192.168.1.23:80, France:htt://192.168.1.23:80

Correction : Changer le protocole pour un protocole valide : http ou https

Le démon a bloqué une tentative de chargement d'objet malveillant

There were [ X ] security breaches blocked today (last 3):
    AT RISK: ( OBJECT_NAME ) by "HTTP_ROUTE_NAME" by IP=ATTACKER_IP" at YYYY-MM-DD HH:MM:SS
    AT RISK: ( OBJECT_NAME ) by "HTTP_ROUTE_NAME" by IP=ATTACKER_IP" at YYYY-MM-DD HH:MM:SS
    AT RISK: ( OBJECT_NAME ) by "HTTP_ROUTE_NAME" by IP=ATTACKER_IP" at YYYY-MM-DD HH:MM:SS

Il est possible qu'un démon puisse détecter et bloquer une tentative d'injection d'objet malveillant par le biais de l'une de ses routes.

Un message est remonté :

• le nombre total de ces tentatives que le démon a bloqué ce jour ( le compte commence à minuit ) ;
• pour chacune des tentatives ( maximum 3 ) :
  • descriptif de l'objet que l'attaquant essaye de charger,
  • sa provenance de l'attaque, par exemple le nom de la route utilisée, et l'IP à la source de l'attaque,
  • sa date.