When Are Host Checks Performed?
Hosts are checked by the Shinken Enterprise daemon:
- At regular intervals, as defined by the check interval and retry interval options in your host definition.
- On-demand when a check associated with the host changes state.
On-demand as needed as part of the host reachability logic (dependencies).Regularly scheduled host checks are optional.
If you set the check_interval option in your host definition to zero (0), Shinken Enterprise will not perform checks of the hosts on a regular basis.
It will, however, still perform on-demand checks of the host as needed for other parts of the monitoring logic.
 Image Removed | On-demand checks are made when a service associated with the host changes state because Shinken Enterprise needs to know if the host has also changed state. Services that change state are often an indicator that the host may have also changed state.
For example, if Shinken Enterprise detects that the "HTTP" check associated with a host just changed from a CRITICAL to an OK state, it may indicate that the host just recovered from a reboot and is now back up and running.
On-demand checks of hosts are also made as part of the dependencies logic. Shinken Enterprise is designed to detect network outages as quickly as possible, and distinguish between DOWN and UNREACHABLE host states. These are very different states and can help an administrator to quickly locate the cause of a network outage.Quand sont lancés les checks des hôtes? Les hôtes sont vérifiés par les démons Shinken Enterprise : - A intervalles réguliers, tels que défini dans la définition de l'hôte .
- A la demande quand il y a un changement d'état du check associé à l'hôte .
- A la demande selon la logique de dépendance de l'hôte .
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 . | Image Added |
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 | |
| | |
Dependencies and You can define parents that prevent Shinken Enterprise from checking the status of a host depending on the state of one or more other hosts. More information on dependencies can be found on the depdency logic pageet 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" . | |
| | |
Parallelization of Host Parallélisation des Checks |
All checks are run in parallel| Tous les checks sont lancés en parallèle. | |
| | |
Host States |
Hosts that are checked can be in one of three different statesEtats des hôtes |
Les hôtes vérifiés peuvent être dans 3 états différents : | |
| | |
Host State Determination |
Host checks are performed by commands, which can return a state of 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, |
or | ou CRITICAL. Shinken Enterprise |
does translate these plugin return codes into host states of | traduit les codes retour des sondes par un état d'hôte qui est soit UP, DOWN, |
or The table below shows how plugin return codes correspond with preliminary host states. Some post-processing (which is described later) is done which may then alter the final host state.| 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. | | Résultats de Commande | Etat de l'hôte |
|---|
|
Command result | Host state |
|---|
| OK | UP | | WARNING | DOWN | | UNKNOWN | DOWN | | CRITICAL | DOWN |
|
If the preliminary host state is Preliminary Host state | Parent host state |
Si l'état principal de l'hôte est DOWN, Shinken Enterprise |
will attempt to see if the host is really DOWN or if it is UNREACHABLE. The distinction between DOWN and UNREACHABLE host states is important, as it allows admins to determine root cause of network outages faster. The following table shows how Shinken Enterprise makes a final state determination based on the state of the hosts parent(s). A host's parents are defined in the parents directive in host definition.| 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) | | Etat de l'hôte précédent | Etat de l'hôte parent |
|---|
|
At least one parent is | Au moins un parent est UP | DOWN | | DOWN |
|
All parents are eitheir DOWN or | Tous les parents sont, soit DOWN ou UNREACHEABLE | UNREACHABLE |
|
More information on how Shinken Enterprise distinguishes between DOWN and UNREACHABLE states can be found on the dependency logic page
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" . | |
| | |
Host State Changes |
As you are probably well aware, hosts don't always stay in one state. Things break, patches get applied, and servers need to be rebooted. When Shinken Enterprise checks the status of hosts, it will be able to detect when a host changes between 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, |
and UNREACHABLE states and take appropriate action.These state changes result in different state et UNREACHABLE et de prendre les actions appropriées . Ces changements d'états résultent en différent types (HARD or SOFT), |
which can trigger event handlers to be run and notifications to be sent out. Detecting and dealing with state changes is what Shinken Enterprise Enterprise is all about.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" |
When hosts change state too frequently they are considered to be flapping. A good example of a flapping host would be a server that keeps spontaneously rebooting as soon as the operating system loads. That's always a fun scenario to have to deal with.
Shinken Enterprise can detect when hosts start flapping, and can cancel notifications until flapping stops and the host's state stabilizes. More information on the flap detection logic can be found on the flapping page