Checks actifs

Introduction

Shinken Enterprise est capable de superviser des hôtes de 2 façons différentes :activement ou passivement . L'utilisation des checks actifs est la plus courante. Les caractéristiques principales des checks actifs sont les suivantes : 

• les checks actifs sont initiés par le poller Shinken Enterprise 

• ils sont lancés à intervalle régulier

Comment sont réalisés les checks actifs?

Les checks actifs sont initiés par la logique définie dans les démons dans Shinken Enterprise . Lorsque Shinken Enterprise doit vérifier les statut d'un hôte, il lance un plugin et présente les informations sur ce qui doit être vérifié. Le plugin va alors vérifié l'état de l'hôte et remonté le résultat ver le démon Shinken Enterprise . Le démon scheduler va traiter le résultat et lancer les actions appropriées si nécessaire (e.g. envoi de notifications, etc).

Quand sont lancés les checks actifs?

Ils sont exécutés:

• à intervalles réguliers, tel que défini dans le paramétrage du check ("check_interval" et "retry_interval") 

• à la demande

Si un hôte est dans l'état "HARD", il sera vérifié activement selon la définition dans le "check_interval". Si il est dans un état "SOFT" , il sera vérifié selon la définition dans "retry_interval".

Le lancement à la demande peut s'effectuer sans aucun contrainte, lorsqu'on a besoin de connaître le tout dernier état d'un hôte. 

Checks passifs

Introduction

Shinken Enterprise permet également de superviser les hôtes de façon passive. Les caractéristiques principales des checks passifs sont les suivantes:

• les checks passifs sont lancés par des applications ou process externes 

• les résultats sont envoyés au démon Shinken Enterprise pour traitement 

La principale différence avec les checks actifs réside donc dans son lancement externe. 

Usages des checks passifs

les checks passifs sont utiles dans les cas :

• checks asynchrones part nature, they cannot or would not be monitored effectively by polling their status on a regularly scheduled basis, like backup or batchs

• Located behind a firewall and cannot be checked actively from the monitoring host

Examples of asynchronous checks that lend themselves to being monitored passively include:

• "SNMP" traps and security alerts. You never know how many (if any) traps or alerts you'll receive in a given time frame, so it's not possible to just monitor their status every few minutes.

• Aggregated checks from a host running an agent. Checks may be run at much lower intervals on hosts running an agent.

• Submitting check results that happen directly within an application without using an intermediate log file(syslog, event log, etc.).

How Passive Checks Work

Here's how passive checks work in more detail. An external application checks the status of a host or check. The external application writes the results of the check to the webservice of the receiver. Its configuration and API is defined at Enable webservice for passive checks. Shinken Enterprise reads the passive checks and push them to the appropriate daemons. Shinken Enterprise will get results each second and scan the check result queue. Each check result that is found in the queue is processed in the same way - regardless  whether the check was active or passive. Shinken Enterprise may send out notifications, log alerts, etc. depending on the check result information. The processing of active and passive check results is essentially the same. This allows for seamless integration of status information from external applications with Shinken Enterprise.

Enabling Passive Checks

In order to enable passive checks in Shinken Enterprise, you'll need to do the following:

• Set accept_passive_service_checks directive is set to 1 (in shinken.cfg).

• Set the passive_checks_enable" directive in your host and check definitions is set to True.

If you want to disable processing of passive checks on a global basis, set the accept_passive_check_checks directive to 0.

If you want to disable passive checks for just a few hosts or checks, use the "passive_checks_enabled" directive in the host and/or check definitions to do so.

Submitting Passive check Results

You can look at the Enable webservice for passive checks about how to send external checks to the receivers.

Passive Checks and Host States

Unlike with active host checks, Shinken Enterprise does not (by default) attempt to determine whether or host is DOWN or UNREACHABLE with passive checks. Rather, Shinken Enterprise takes the passive check result to be the actual state the host is in and doesn't try to determine the hosts' actual state using the reachability logic . This can cause problems if you are submitting passive checks from a remote host.

Passive host checks are treated as HARD states.