Contexte
Le Pack Shinken est inclus dans votre installation de Shinken Entreprise afin d'avoir une bonne visibilité de la santé de votre architecture de supervision.
Afin de pouvoir superviser les démons de l'architecture, la source cfg-file-shinken comprend un certain nombre de modèles d'hôte qu'il faudra importer et appliquer sur vos serveurs hébergeant vos démons Shinken.
Les différents modèles mis à votre disposition sont les suivants :
- shinken-arbiter
- shinken-broker
- shinken-broker-module-sla
- shinken-poller
- shinken-reactionner
- shinken-receiver
- shinken-scheduler
- shinken-synchronizer
Une fois les modèles appliqués, les checks apparaîtront dans l'onglet "Checks" de votre hôte.
Voici un exemple des différents checks du pack Shinken sur un hôte.
Il n'est pas conseillé d'ajouter des éléments dans ce pack, car les fichiers du pack sont remplacés à chaque mise à jour de shinken-enterprise.
Si vous souhaiter ajouter des éléments à votre configuration, nous vous conseillons de créer une sources cfg.
Cas particuliers
Détection de la haute disponibilité
Les modèles d'hôte du pack Shinken permettent de détecter les environnements distribués avec des démons configurés en Spare.
Dans le cas ou un démon est spare, une pastille bleue "SPARE" est affichée a coté du statut de la vérification:
Lorsqu'un Spare prend le relais, une pastille "RUNNING" est rajoutée à la mention "SPARE" :
Détection de la haute disponibilité dans le cas du Broker
Le Broker a plus d'informations à disposition concernant la haute disponibilité, car un spare doit être assigné à un démon master.
Lorsqu'un démon master a un spare de configuré, le nom de ce dernier sera affiché:
Lorsqu'un démon n'a pas de spare de configuré, l'affichage sera:
Concernant un démon spare, il affichera le démon master qu'il remplacera si besoin:
Lorsque le remplacement arrive, l'affichage change pour montrer qu'il est passé actif:
Détection d'erreurs de communication entre démons
Les checks du pack Shinken ont la capacité de détecter les problèmes de communication entre les démons.
En effet, si le démon supervisé lance un appel (API) et qu'il échoue, alors l'erreur sera écrite dans les logs de ce démon (Les fichiers Logs) et un Warning sera remonté :
La vérification se base sur les dernières 24h. Si toutes les communications aboutissent correctement durant les dernières 24h, le message disparaîtra et vous retrouverez un état OK.
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.
Détection des différences de versions
Les checks du pack Shinken sont également capables de détecter des différences de version entres les démons, et d'afficher l'information dans le retour du check.
Par exemple ici le retour du check "Arbiter - Performance" :
Par exemple ici le retour du check "Scheduler - Performance", indiquant une différence de version avec un Poller :
Détection d'un module défaillant
Si un module vient à s’arrêter ou à redémarrer, les checks du pack Shinken le détecteront.
Voici par exemple le check "Alive" du Broker, qui détecte un problème sur le module Livestatus :
Détection du mode Passif des démons Poller et Reactionner
Les checks "Poller - Running Well" et "Reactionner - Running Well" du pack Shinken permettent de détecter et donc afficher si un démon est en mode passif.
Voici un exemple avec le check du Reactionner :
