Introduction | |
Quand sont lancés les checks des hôtes? Les hôtes sont vérifiés par les démons Shinken Enterprise :
| |
Les vérifications planifiées sont optionnelles. Si vous validez la valeur zéro dans le paramètre check_interval Shinken Enterprise ne lancera pas de |
vérifications régulières. On pourra cependant toujours lancer des vérifications à la demande . |  |
Les vérifications à la demande sont lancées lorsqu'un service associé à un hôte change d'état, car Shinken Enterprise a |
besoin de savoir si l'hôte a également changé d'état. Un service qui change d'état est très souvent un indicateur montrant que l'hôte a également changé d'état. Par exemple, si Shinken Enterprise détecte que le check "HTTP" associé à un hôte vient de passer de l'état CRITICAL à OK, cela peut vouloir dire que l'hôte vient juste de revenir suite à un reboot et est à nouveau opérationnel. Les vérifications à la demande sont également lancées dans le cadre |
de la gestion des dépendances. Shinken Enterprise est conçu pour détecter dès que possible les problèmes |
réseaux, et doit pouvoir faire la différence entre |
le statut DOWN et le statut UNREACHABLE . Cela doit aider l’administrateur à investiguer plus rapidement un |
problème | |
Checks et dépendances | |
| Vous pouvez définir des parents sur un hôte afin de ne pas avoir à vérifier le statut de tous les hôtes dépendants. Plus d'informations disponibles dans le paragraphe "gestion des dépendances" . | |
Parallélisation des Checks | |
| Tous les checks sont lancés en parallèle. | |
Etats des hôtes | |
Les hôtes vérifiés peuvent être dans 3 états différents :
| |
Détermination de l'état de l'hôte | |
| Les vérifications d'hôtes sont faites par des commandes, qui retournent un état soit OK, WARNING, UNKNOWN, ou CRITICAL. Shinken Enterprise traduit les codes retour des sondes par un état d'hôte qui est soit UP, DOWN, ou UNREACHABLE. La table ci-joint montre les correspondances entre les codes | |
| retours et l'état associé. Certains sous-process (décrits plus loin) peuvent modifier l'état final de l'hôte. |
|
| |||||||||
Si l'état principal de l'hôte est DOWN, Shinken Enterprise va tenter de déterminer si l'hôte est réellement DOWN ou |
| s'il est juste UNREACHABLE. La différence entre DOWN et UNREACHABLE est importante car elle permet de déterminer la réelle cause source du problème. Le tableau joint montre comment Shinken Enterprise défini le statut final en fonction du statut du parent (tel que précisé dans la définition de l'hôte) |
|
|
|
| ||
Plus d'information sur la façon dont Shinken Enterprise fait la distinction entre DOWN et UNREACHABLE sont |
| disponibles dans le paragraphe "gestion des dépendances" . | |
Changement d'état d'un hôte | |
Comme vous le savez certainement, un hôte ne reste jamais dans le même état tout le temps. Quand Shinken Enterprise vérifie le statut d'un hôte, il est capable de détecter un changement d'état entre UP, DOWN, | |
et UNREACHABLE et de prendre les actions appropriées . Ces changements d' |
états résultent en différent types (HARD or SOFT), qui peuvent lancer des événements et des notifications. Détecter et gérer tous ces changements d'état est l’essence même de Shinken Enterprise . Lorsque l'état d'un hôte change trop souvent, il est considéré comme comme étant en "flapping". Un bon exemple serait un serveur qui se reboot à chaque fois que l'OS charge. Shinken Enterprise peut détecter quand un hôte entre en statut flapping, et peut alors bloquer l'envoi de notifications tant que l'état n'est pas stabilisé. Plus d’informations disponibles dans le paragraphe "flapping". |