Mode actif
Introduction
Shinken Enterprise est capable de superviser des hôtes et les checks de 2 façons différentes: activement ou passivement. L'utilisation des checks actifs est la plus courante.
Les caractéristiques principales du mode actif 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 statuts d'un hôte ou d'un check, il lance un plugin et présente les informations sur ce qui doit être vérifié. Le plugin va alors vérifier l'état de l'hôte et remonter le résultat vers 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". S'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.
Mode passif
Introduction
Shinken Enterprise permet également de superviser les hôtes et les checks de façon passive. Les caractéristiques principales du mode passif 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 par nature, ils ne peuvent être supervisés efficacement en vérifiant leur statut à intervalles réguliers et planifiés (comme un batch ou une sauvegarde)
- Localisation derrière un firewall ne permettant pas de lancer les checks depuis l'hôte de supervision
Exemples de checks asynchrones nécessitant d'être supervisés en mode passif :
- traps "SNMP" et alertes de sécurité. Vous ne savez jamais combien (si il y en a) de traps ou d'alertes seront remontées dans un intervalle donné. Il est donc impossible de simplement superviser leur état toutes les x minutes.
- les checks agrégés tournant avec un agent. Il peut être nécessaire de lancer ce checks à des intervalles beaucoup plus courts .
- check proposant les résultats intervenant directement dans une application sans utilisation de fichier log intermédiaires (syslog, event log, etc.).
Comment fonctionne le mode passif
Voici le fonctionnement en détail.
Le traitement du résultat d'un check actif ou passif est le même. Cela permet d'intégrer facilement les informations de statuts provenant d'applications tierces. |
Activer le mode passif
Pour activer le mode passif dans Shinken Enterprise, vous devez réaliser les actions suivantes:
- activer le paramètre "accept_passive_service_checks directive" à 1 (dans shinken.cfg).
- activer le paramètre "passive_checks_enable" à vrai dans la définition de votre hôte et votre check.
Si vous voulez l'activer globalement, activer le paramètre "accept_passive_check_checks directive" à 0.
Pour désactiver ce mode sur un ou plusieurs hôtes et checks, utilisez le paramètre "passive_checks_enabled directive" dans la définition de l'hôte et du check.
Soumettre les résultats de checks passifs
Vous pouvez vous référer à Enable webservice for passive checks pour voir comment envoyer des checks externes aux receivers.


Add Comment