| Scroll Ignore | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||
|
Qu'est-ce que le
Health Checkshinken-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
| Code Block |
|---|
| Table of Contents | ||||
|---|---|---|---|---|
|
|
Usage
| |||
shinken-healthcheck |
Principales options
| Option | Option longue | Description |
|---|---|---|
| - |
| h | --help | Affiche le message d'aide |
| -v | --version | Affiche la version de Shinken Entreprise installée |
| -l | --local | Effectue une vérification des démons locaux seulement |
| -g | --global | Effectue une vérification complète des démons ( doit être lancé depuis la machine comportant l'Arbiter et le Synchronizer ). Par défaut sur une machine avec un Arbiter et un Synchronizer, un |
| Healthcheck global est effectué sauf si un |
| Healthcheck local est explicitement demandé. | ||
| --debug | Active l'affichage des données de debug dans la sortie de la commande. |
| Cette option est utile seulement dans le cas d'un |
| envoi de ces données aux équipes de support de Shinken Solutions. | |
| -f | --file |
| Écris la sortie de la commande dans un fichier. La sortie de la commande est également affichée. | ||
| --output-directory | Dossier dans lequel sera placé le fichier de sortie. Par défaut, le dossier courant est utilisé. | |
| --output-name | Fichier dans lequel sera placé le fichier de sortie. Valeur par défaut: shinken-healthcheck_$(DATE).txt | |
| --timeout | Temps en secondes |
| à partir duquel un démon sera considéré comme injoignable. Par défaut: 3 secondes | ||
| --modules-warning-expire | Temps en minutes pendant lequel un redémarrage de module génère une alerte. Par défaut :120 ( 2 heures ), valeur maximale :1440 (24 heures) | |
| --show-history | Affiche l'historique des installations et |
| données de Shinken Entreprise sur ce serveur |
La commande
shinkenShinken-healthcheck sépare sa vérification en plusieurs parties qui sont décrites dans les sections suivantes.
Informations de version
| Panel |
|---|
La première section visible dans le Healthcheck est l'affichage de la version installée, ainsi que la première version installée sur ce serveur.
Vérification de l'architecture
Etat des démons
Le Healthcheck affiche ensuite pour tous les démons activés dans la configuration, différentes informations indiquant le bon fonctionnement du démon:
- Le type et le nom du démon. Si celui est un Spare, une mention "SPARE" est présente à la suite du nom du démon.
- La configuration est elle valide ?
- Le démon est-il joignable sur le port trouvé dans la configuration ?
- La version actuelle du démon. Si il y a une différence de version entre l'Arbiter et le démon, un message d'erreur indique cette différence.
- Connexion avec l'Arbiter, ainsi que le décalage de temps entre le démon et l'Arbiter.
- Si plusieurs Arbiters envoient une configuration au démon, un message d'erreur indique que 2 Arbiters sont en conflit, en précisant l'URL de chacun de ces arbiters.
- Liste des autres démons à contacter pour pouvoir fonctionner correctement (section "Talk to").
- État des modules, et le cas échéant des sous-modules. Si un module a redémarré récemment, un avertissement sera affiché en indiquant la liste des derniers redémarrages du module ou sous-modules.
- Champs spécifiques au démon
- Liste des tags pour le Poller et Reactionner, ainsi que les éventuelles erreurs sur les workers.
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
| Panel |
|---|
|
Vérification de l'architecture
Etat des démons
Le 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.
- Connexion 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, en précisant l'ip de chacun de ces Arbiters.
- Liste des autres démons à contacter pour pouvoir fonctionner correctement ( section "Talk to" ).
- État des modules, et le cas échéant des sous-modules. Si un module a redémarré récemment, un avertissement sera affiché en indiquant la liste des derniers redémarrages du module ou sous-modules.
- Champs spécifiques au démon
- Liste des tags pour le Poller et Reactionner ainsi que les éventuelles erreurs sur les workers.
| Panel |
|---|
|
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é.
| Panel |
|---|
|
| Panel |
|---|
|
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 ).
| Panel |
|---|
|
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 Shinken-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
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
|
| Panel |
|---|
Dans l'affichage de l'état des démons, ainsi que dans les sections suivantes, plusieurs états peuvent être retournés:
- OK: Tout va bien
- AT RISK: Problème pouvant potentiellement nuire au fonctionnement du système.
- ERROR: Une erreur bloquante a été détectée.
Royaumes et sous-royaumes
Dans une configuration de Shinken Entreprise, les démons peuvent être répartis sur plusieurs machines.
Dans le Healthcheck, les démons sont regroupés en fonction de la machine sur laquelle ils sont installés.
On voit dans l'exemple ci-contre qu'un Poller est installé sur la machine d'adresse 192.168.1.35, et qu'un Arbiter et un Broker sont installés et activés sur la machine vm3 (172.16.0.3).
| Panel |
|---|
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
| Code Block | ||||
|---|---|---|---|---|
| ||||
----------------- | Realm /France | ----------------- | Realm /France | ----------------- -------------- | In France/ | -------------- - a.a.a.a (a.a.a.a): ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [poller: poller-windows1] .... - master1 (b.b.b.b): ^^^^^^^^^^^^^^^^^^^^^^^^^^ [arbiter: arbiter-master] ... [broker: broker-master] ... [poller: poller-master1] ... [reactionner: reactionner-master] ... [synchronizer: synchronizer-master] ... [receiver: receiver-1] ... [scheduler: scheduler-master] ... ----------------------- | Realm /France/Corse | ----------------------- ------------- | In Corse/ | ------------- - master3 (d.d.d.d): ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [broker: broker-master-3] ... [poller: poller-master3] ... [scheduler: scheduler-master3] ... --------------------------- | Realm /France/Sud Ouest | --------------------------- ----------------- | In Sud Ouest/ | ----------------- - master2 (c.c.c.c): ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [broker: broker-master-2] ... ------------------------------------ | Realm /France/Sud Ouest/Bordeaux | ------------------------------------ ---------------- | In Bordeaux/ | ---------------- - master2 (c.c.c.c): ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [poller: poller-master2] ... [scheduler: scheduler-master2] ... |
Vérification de la licence
Cette section du
Shinken-healthcheck affiche des informations sur la licence en cours.
Elle affiche le propriétaire de la licence, le type de licence, et la date d'expiration de la licence.
Si le nombre de
nœuds est dépassé ou que la licence est expirée, une erreur sera affichée dans cette section.
| Info |
|---|
A noter que cette section ne s'affiche que sur les serveurs hébergeant un Arbiter ou un Broker. |
| Panel |
|---|
|
Vérification des
librairiesbibliothèques externes
Shinken Entreprise utilise de nombreuses librairies externes pour fonctionner.
La partie
Local Libraries du Shinken-healthcheck fournie les informations suivante pour les bibliothèques nécessaires au fonctionnement de Shinken Enterprise :
- Si elles sont bien présentes
- La version de python dans laquelle la bibliothèque est installée
- La version de la bibliothèque
- La liste des dépendances de la bibliothèque et leur version
| Panel |
|---|
|
En cas d'erreur
concernant l'une des
bibliothèques, un message d'erreur est
affiché indiquant la nature de l'erreur.
Vérification
du statut du chiffrement des champs protégésLa 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.
des espaces de stockage
Graphite
Shinken Entreprise sauvegarde les données de métrologie dans un serveur Graphite. Si la configuration de la sauvegarde des données de métrologies est simple pour une configuration basique,
| Panel |
|---|
| Panel |
|---|
|
Vérification des espaces de stockage
Shinken Entreprise sauvegarde les données de métrologie dans un serveur Graphite. Si la configuration de la sauvegarde des données de métrologies est simple pour une configuration basique, elle devient rapidement compliquée lorsque la configuration comporte plusieurs royaumes avec plusieurs Brokers.
Lorsque plusieurs Broker 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.
Le Healthcheck possède donc 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 données brokers de métrologie chaque royaume sont bien sauvegardées pour chaque royaumeconfigurés pour sauvegarder les données, que toutes les interfaces de visualisation lisent bien les données de métrologie au bon endroit, et 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.
La première section de la vérification des espaces de stockage Graphite s'occupe de vérifier que pour chaque royaume, les données de métrologie sont bien sauvegardées dans au moins un serveur Graphite.
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.
| Panel |
|---|
La vérification des espaces de stockage vérifie ensuite si toutes les interfaces de Visualisation d'un royaume.
Pour chaque royaume défini dans la configuration, le healthcheck va vérifier qu'il existe bien au moins un Broker de ce royaume permettant d'afficher les données de métrologie.
Si le royaume comporte plusieurs Brokers, le healthcheck vérifie que tous les Brokers ont la même configuration en ce qui concerne le serveur Graphite à utiliser pour récupérer les données de métrologie.
| Panel |
|---|
Enfin, lors de la vérification des espaces de stockage, le healthcheck cherche à déterminer si tous les serveurs utilisés dans les différents royaumes pour stocker des données de métrologie sont joignables.
Le healthcheck vérifie également que tous ces serveurs permettent bien de lire et écrire des données.
Ainsi, pour chaque serveur, le healthcheck demande au Broker d'essayer d'effectuer une écriture et une lecture de données, et affiche le résultat.
On voit ici dans l'exemple que tous les serveurs utilisés pour le stockage des données de métrologie sont bien joignables et permettent effectivement d'écrire et de lire des données de métrologie.
| Panel |
|---|
Vérification des addons
La section suivante du Healthcheck affiche l'état des différents addons actifs sur la machine.
La liste des addons actuellement activés est affichés, avec pour chacun, leur statut ainsi que l'état de différentes vérifications.
Puisque les addons peuvent avoir chacun un fonctionnement différent, les vérifications effectuées différent selon l'addon.
| Panel |
|---|
|
Structure des royaumes
La dernière section du Healthcheck l'état de la structure des royaumes.
Si la configuration des royaumes est erronée, les autres vérifications ne sont pas faites et seule cette erreur est affichée.
La copie d'écran montre une erreur, car deux royaumes ont été définis comme royaumes par défaut.
| Panel |
|---|
Historique des installations et de la configuration
Le Healthcheck affiche par défaut la version initiale d'installation ainsi que la version actuellement installée.
Il est possible d'obtenir des informations supplémentaires sur l'historique de l'installation en utilisant l'option "--show-history" de la commande "shinken-healthcheck":
| Code Block |
|---|
shinken-healthcheck --show-history |
Ce paramètre affiche des informations sur l'évolution de Shinken Entreprise depuis son installation initiale.
L'utilisation de cette option est surtout pratique lorsque vous communiquez avec le support Shinken, qui utilisera les informations remontées pour plus facilement retrouver l'origine de votre problème.
Historique des mises à jour
L'option --show-history affiche d'abord une liste triée chronologiquement des différentes versions de Shinken installées sur la machine courante.
On peut donc voir facilement, pour une date donnée, quelle était la version de Shinken installée.
Cette option est également utile pour communiquer avec le support Shinken, pour détecter des erreurs de configuration liées à des anciennes versions de Shinken.
| Panel |
|---|
Historique des données
Après l'historique des installations vient l'historique des données présentes dans Shinken. Cet historique de données est séparé en plusieurs sections correspondant chacune à un type de donnée différente:
- Configuration (configuration de Shinken, élément de supervision)
- SLA (historique des états des éléments supervisés et données de SLA)
- Métrologie (métriques)
- Données utilisateurs (données sauvegardées dans l'interface de visualisation)
On dispose encore d'une liste chronologique présentant les différentes opérations effectuées sur les données:
- Mise à jour
- Restauration d'une sauvegarde
- Exécution du script de nettoyage des données, qui retravaille la configuration automatiquement lors d'une mise à jour pour la rendre compatible avec les dernières versions de Shinken Entreprise
- Installation et désinstallation d'un patch
- Installation et désinstallation d'un add-on
| Panel |
|---|
Historique des paramètres de chiffrement des données
Le dernier type d'information remonté par l'option --show-history est l'historique des paramètres de chiffrement des données sensibles.
A chaque fois que les paramètres de chiffrement sont modifiés et déclenchent un changement dans le chiffrement des données (activation, désactivation, changement des champs chiffrés), une entrée sera ajoutée dans la liste des modifications.
L'état d'activation, le nom de la clé utilisée, l'état de sauvegarde de la clé ainsi que la liste de définition des données à chiffrer sont affichés pour chaque entrée de la liste.
Notez que le statut de sauvegarde de la clé peut être différent du statut affiché dans la section [Encryption Status]:- dans la section [Encryption Status], shinken-healthcheck affiche l'état actuel.
- dans l'historique, shinken-healthcheck affiche l'état au moment de la modification de la configuration.
Seuls les cinq derniers changements sont conservés.
| Panel |
|---|
|
Comment interpréter les informations et erreurs courantes du Healthcheck
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 adresse précises.
|
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.
| Panel |
|---|
|
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 .
| Panel |
|---|
|
Affichage lorsque la gestion des données de performance est désactivé
Lorsque dans la configuration avancée de Shinken ( 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é
| Panel |
|---|
|
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.
| Panel |
|---|
|
Structure des royaumes
L'avant-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.
| Panel |
|---|
|
Récapitulatif du healthcheck
Cette dernière section fait résume le nombre d'erreurs, d'informations et de AT RISK présent dans le résultat du Shinken-healthcheck. Cette section permet à l'utilisateur de ne plus faire défiler toutes les lignes du résultat afin de vérifier s'il y a des erreurs ou des avertissements.
Dans notre exemple, nous pouvons savoir aisément qu'il y a 4 erreurs et un avertissement dans le résultat du Shinken-healthcheck.
| Panel |
|---|
|
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":
| Code Block | ||||
|---|---|---|---|---|
| ||||
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 :
| Action | Description | Détails |
|---|---|---|
| INSTALLATION | Première installation de Shinken. |
|
| PATCH | Mise à jour de Shinken. |
Le nom de la version à la ligne correspond à la version vers la quelle la mise à jour est faite. |
| UNPATCH | Désinstalle une mise à jour. |
Le nom de la version à la ligne correspond à la version du patch désinstallé. |
| Panel |
|---|
|
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
| Action | Description | Détails |
|---|---|---|
| INSTALLATION | Première installation de Shinken. |
|
| UPDATE | Mise à jour de Shinken. |
|
| sanatize | Exécution du script de nettoyage des données. Retravaille les données lors d'une mise à jour ou restauration pour les rendre compatibles avec la version installée / restaurée. |
|
| RESTORE | Restauration d'une sauvegarde. Le type de données restaurées dépend des options utilisées lors du script de restauration. ( Voir la page : Shinken-backup et Shinken-restore, les commandes de sauvegarde et de restauration ) |
|
| Panel |
|---|
|
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.
| Panel |
|---|
|
| Panel |
|---|
Le démon est injoignable
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.
| Panel |
|---|
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.
| Panel |
|---|
Conflit d'Arbiter sur un démon
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.
| Panel |
|---|
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 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".
| Panel |
|---|
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 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.
| Panel |
|---|
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.
| Panel |
|---|
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":
| Code Block |
|---|
yum install open-vm-tools |
| Panel |
|---|
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
| Panel |
|---|
Un module a redémarré de manière imprévue
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.
| Panel |
|---|
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.
| Info |
|---|
Les erreurs de communication peuvent ne pas être graves et ne pas avoir d'incidence sur votre architecture Shinken. Cependant, si vous recevez des erreurs et que vous avez des doutes sur l'origine de ces problèmes de communication, par prévention, envoyez nous votre log pour analyse. |
| Panel |
|---|
Un scheduler n'a pas de broker ou de poller ou de reactionner
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).
| Info |
|---|
Si le scheduler est dans un sous royaume et qu'un poller/reactionner/broker est présent dans un royaume supérieur, ceci signifie que ce dernier n'a pas l'option manage_sub_realms activée. |
| Panel |
|---|
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'erreur:
- Les erreurs d'écriture
- Les erreurs de lecture
| Panel |
|---|
Les erreurs d'écriture
Cas 1 : Les données d'un royaume ne sont pas sauvegardé
This realm might produce data that are not stored anywhere (no Graphite backend configured)
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
| Panel | ||
|---|---|---|
| ||
Cas 2 : Plusieurs broker du même royaume écrivent dans des base graphite différente
Brokers for this realm have different Graphite backends
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 faire un nouveau module Graphite-Perfdata-Corse:
| Code Block |
|---|
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
} |
Et l'utiliser dans les 2 brokers : /etc/shinken/broker/broker-master3.cfg et /etc/shinken/broker/broker-maste5.cfg
| Code Block |
|---|
modules Simple-log, WebUI, sla, Livestatus, Graphite-Perfdata-Corse |
| Panel | ||
|---|---|---|
| ||
Les erreurs de lecture
Cas 1 : La configuration du module webi.cfg précise un royaume qui n'existe pas
Realm * is an unknown realm.
Exemple : Dans le fichier /etc/shinken/module/webi.cfg la configuration précise un royaume qui n'existe pas
| Code Block |
|---|
graphite_backends fr:212.47.233.21,*:127.0.0.1 |
Correction : Préciser un nom de royaume qui existe
| Code Block |
|---|
graphite_backends France:212.47.233.21,*:127.0.0.1 |
| Panel | ||
|---|---|---|
| ||
Cas 2 : La configuration du module webi.cfg précise un royaume non géré par le broker
Realm * can't be accessed by the broker *
Exemple : Broker-master3 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
Correction : Ajouter la gestion des sous royaume par mon broker dans /etc/shinken/brokers/broker-master3.cfg
| Code Block |
|---|
manage_sub_realms 1 |
| Panel | ||
|---|---|---|
| ||
Cas 3 : Il n'y a pas de broker qui gère les donnée que veux lire le broker
Realm * does not have any broker which write graphite data
Exemple : Broker-master3 sur le royaume n’écrit pas les données du royaume France à cause de la configuration de son module graphite
| Code Block |
|---|
realm_store_only Corse,Bordeaux |
Correction : Autoriser son module graphite à sauvegarder tout les royaumes
| Panel | ||
|---|---|---|
| ||
Cas 4 : Le serveur graphite précisé dans la configuration de webui ne gère pas les données de ce royaume
The Graphite server on * does not contain data for this realm
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
| Code Block |
|---|
graphite_backends Corse:212.47.233.21, *:127.0.0.1 |
Correction : Préciser un serveur qui gère les données de Corse :
| Code Block |
|---|
graphite_backends Corse:163.172.153.106, *:127.0.0.1 |
| Panel | ||
|---|---|---|
| ||
Cas 5 : 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
Exemple : La configuration de webui précise que les données de Corse sont sur toto qui n'est pas un serveur graphite connu
| Code Block |
|---|
graphite_backends Corse:toto, *:127.0.0.1 |
Correction : Préciser un serveur qui gère les données de Corse :
| Code Block |
|---|
graphite_backends Corse:163.172.153.106, *:127.0.0.1 |
| Panel | ||
|---|---|---|
| ||
Enfin, les erreurs de graphites sont maintenant comptés par le module Webui et elle sont retournées dans les erreurs de lecture.