| Scroll Ignore | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||
|
Contexte
Shinken propose deux modes de supervision des hôtes et des checks :
- Actif : Shinken planifie et exécute directement les commandes de vérification. L'exécution des vérifications se fait à intervalles réguliers.
- Passif : Shinken accepte et intègre les résultats depuis des outils externes, sans lancer lui-même les commandes de vérification. Ce mode est particulièrement adapté aux éléments dont le statut ne peut pas être déterminé efficacement à intervalles fixes — par exemple, des processus asynchrones comme des jobs batch ou des sauvegardes — ou encore des équipements situés derrière un pare-feu, empêchant une connexion directe depuis un Poller.
Ces deux modes peuvent être combinés. Il est ainsi possible de planifier des vérifications via Shinken ( mode actif ) tout en acceptant des résultats issus d’outils externes ( mode passif ).
Par défaut, les deux modes sont activés sur les hôtes et les checks.
| Panel |
|---|
|
Mode actif
Fonctionnement du mode actif
Les caractéristiques du mode actif sont :
- La sonde est exécutée par le Poller.
- Elle est lancée à intervalles réguliers.
Fonctionnement détaillé du mode actif :
- Ordonnancement par le Scheduler : Le Scheduler est responsable de la planification des vérifications. Chaque check ou hôte dispose d’une fréquence de vérification configurable, définissant à quel intervalle il doit être supervisé.
- Exécution de la sonde par le Poller : Le Poller exécute la commande de vérification associée à l’élément. Cette commande :
collecte les données nécessaires depuis l’équipement supervisé,
analyse ces données pour déterminer :
le statut ( OK, ATTENTION, CRITIQUE, INCONNU ),
le résultat court,
le résultat long,
les métriques.
- Le Poller transmet ensuite ces informations au Scheduler.
- Traitement par le Scheduler : Le Scheduler analyse les résultats reçus et, selon l’état et la configuration, déclenche les actions appropriées. Cela peut inclure l’envoi de notifications ou l'exécution de commandes via le gestionnaire d’événements, qui seront ensuite prises en charge et exécutées par un Reactionner.
Activer le mode actif
Le mode actif pour les checks et les hôtes est activé par défaut dans Shinken.
La configuration du mode actif se trouve dans l'onglet Supervision de l'élément.
La propriété Actif activé ( clé d'import active_checks_enabled ) permet d'activer ou de désactiver ce mode, soit sur un hôte ( voir la page Éditer un Hôte ), soit sur un check ( voir la page Editer un check appliqué à un hôte ).
| Panel |
|---|
|
Paramétrer la fréquence de vérification
La configuration de l’intervalle des vérifications dans Shinken est paramétrable pour chaque hôte ou chaque check.
Deux paramètres contrôlent la fréquence des contrôles :
- Intervalle entre les vérifications ( clé d'import : check_interval ) : Lorsque le statut d'un élément est confirmé ( voir la page Statut confirmé ( HARD ) et non confirmé ( SOFT ) ) , il est vérifié périodiquement selon cet intervalle.
- Intervalle de nouvelles tentatives de confirmations d'état ( clé d'import : retry_interval ) : Après le premier statut NON-OK, le statut devient non confirmé. Tant que le statut reste non confirmé, les vérifications sont réalisées périodiquement selon cet intervalle. Une fois l’état confirmé à nouveau, l’intervalle revient à celui défini par l'Intervalle entre les vérifications.
Sur l'Interface de Visualisation, il est possible de forcer la vérification du statut. Cette action n’impacte pas la planification des prochaines vérifications.
| Anchor | ||||
|---|---|---|---|---|
|
Mode passif
Usages du mode passif
Le mode passif est adapté dans les situations suivantes :
- Checks asynchrones : Certains processus sont naturellement asynchrones et ne peuvent pas être efficacement supervisés par des vérifications à intervalles réguliers. Cela concerne notamment des tâches comme les jobs batch ou les sauvegardes, où il n'est pas possible de prédire précisément le moment de leur achèvement ou d’un changement d’état.
- Équipements protégés par un pare-feu : Lorsque des équipements sont situés derrière un pare-feu qui empêche le Poller de lancer des sondes pour interroger leur état, le mode passif devient indispensable
Mode actif
Introduction
Shinken Enterprise est capable de superviser des hôtes et les checks de deux façons différentes:
- activement
- passivement
L'utilisation des checks actifs est la plus courante.
Comment sont réalisés les checks actifs ?
Les caractéristiques principales du mode actif sont les suivantes :
- Les checks actifs sont initiés par le Poller.
- Ils sont lancés à intervalle régulier
Lorsque Shinken Enterprise doit vérifier les statuts d'un hôte ou d'un check,
- il lance une sonde
- Le sonde va alors vérifier l'état de l'hôte et
- il collecte les données dont il a besoin sur l'équipement,
- Il les traite pour calculer le statut, le résultat, le résultat long, et les métriques.
- Le Poller récupère ces 4 informations et les transmets au Scheduler.
- Le démon Scheduler va analyser ces 4 informations et lancer les actions appropriées si nécessaire ( e.g. envoi de notifications, etc ).
| Panel |
|---|
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").
- 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".
- À la demande:
- Le lancement à la demande peut s'effectuer sans aucune contrainte, lorsqu'on a besoin de connaître le tout dernier état d'un hôte.
- ( via l'interface de Visualisation )
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 attendent de recevoir de l’extérieur le statut, le résultat, le resultat long et les métriques de l’extérieur.
- La sonde n'est donc pas lancée un Poller Shinken,
- mais ces informations sont fourni par n'importe quel autre application / script du moment qu'elle peut communiquer vers Shinken et les fournir au format d'une sortie de sonde ( voir Les Sondes => Créer sa sonde(API) )
- C'est le Receiver qui doit être ciblé pour envoyé ces informations
- Une fois reçu, les informations sont traités comme si c’était Shinken qui les avaient exécuter.
La principale différence avec les checks actifs réside donc dans son lancement externe et dans le fait que les informations peuvent arriver n'importe quand ( pas forcément ordonnancées de manière régulière ).
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 ).
- Des équipements derrière un firewall ne permettant pas au Poller de lancer des sondes pour les interroger.
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 ) : Le nombre de traps SNMP 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.
Comment fonctionne le mode passif
Voici le fonctionnement en détail.
- Une application externe vérifie le statut d'un hôte ou d'un check.
- d’alertes de sécurité générés sur une période donnée est imprévisible. Les superviser à intervalles fixes serait inefficace. Le mode passif permet de capturer ces événements immédiatement dès leur survenue.
- Intervalle de vérification trop court : Parfois, l'intervalle de vérification requis est inférieur à l'intervalle minimum d'ordonnancement possible dans Shinken ( une minute ). Dans ce cas, il est possible de superviser à une fréquence plus importante l'élément avec un script ou un agent et de transmettre les résultats à Shinken via un check avec le mode passif activé.
Fonctionnement du mode passif
Les caractéristiques du mode passif sont :
- La sonde n'est pas exécutée par le Poller mais par un outil externe/script.
- Les résultats de la sonde sont envoyés au Receiver.
- La fréquence des résultats dépend de la fréquence d'envoi des résultats par l'outil externe.
Fonctionnement détaillé du mode passif :
- Vérification du statut : Une application externe se charge de la vérification du statut et de récupérer les informations
- Transmission des résultats au Receiver : L'outil externe transmet les données au module de type "
ws-arbiter" sur le Receiver ( voir la pageModule receiver-module-webservice ) selon le format supporté par Shinken ( voir la pageLes Sondes ). - Traitement par le Scheduler : Le Scheduler analyse les résultats reçus et, selon l’état et la configuration, déclenche les actions appropriées. Cela peut inclure l’envoi de notifications ou l'exécution de commandes via le gestionnaire d’événements, qui seront ensuite prises en charge et exécutées par un Reactionner. Le traitement est similaire en mode passif et en mode actif.
Activer le mode passif
Soumettre les résultats de checks/hôtes passifs
Pour pouvoir soumettre un résultat passif dans l'architecture Shinken, il faut :
- Activer le module de type "
ws-arbiter" sur le Receiver (
- voir la pageModule receiver-module-webservice).
- Transmette les résultats à l’API exposée par le module du Receiver ( port 7760 par défaut ).
- S'assurer que le résultat des sondes respectent le format supporté par Shinken ( voir la pageLes Sondes ).
- Shinken Enterprise lit le check passif et l'envoi au démon approprié .
- Shinken Enterprise reçoit les résultats toutes les secondes et scanne la file d'attente . Chaque résultat trouvé dans la file est traité de la même façon - que le check soit actif ou passif. Shinken Enterprise peut envoyer des notifications, log alerts, etc. en fonction du contenu du résultat.
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.
| Panel |
|---|
Activer le mode passif
Pour activer le mode passif dans Shinken Enterprise, vous devez réaliser les actions suivantes:
- Activer dans le fichier shinken.cfg , le paramètre "accept_passive_service_checks" à 1 ( voir Fichier de configuration ( shinken.cfg ) ).
- Activer la propriété "Passif activé " sur votre hôte et votre check ( "passive_checks_enable" a 1 au format cfg ) .
Activer le mode passif sur les checks et hôtes
Le mode passif est activé par défaut pour les hôtes et les checks dans Shinken.
La configuration du mode passif se trouve dans l'onglet Supervision de l'élément.
La propriété Passif activé ( clé d'import passive_checks_enabled ) permet d'activer ou de désactiver ce mode sur un hôte ( voir la page Éditer un Hôte ) ou sur un check ( voir la page Editer un check appliqué à un hôte ainsi que ses pages sœurs ).
Il est important de noter que l’activation du mode passif pour un hôte et pour ses checks n’est pas liée. Par exemple, un hôte peut avoir le mode passif désactivé, tout en ayant un ou plusieurs checks avec le mode passif activé.
| Panel |
|---|
|
Gestion de l'expiration des statuts reçus
En mode passif, la mise à jour de l’état d’un élément est assurée par un outil externe.
L’absence de résultat peut être ambiguë : elle peut signifier qu’aucune erreur n’est survenue, ou au contraire qu’un problème empêche la transmission des données ( défaillance réseau, arrêt du script ).
Pour détecter ces situations, Shinken permet de définir un seuil d’expiration des états reçus des outils externe ( clé d'import freshness_threshold ). Dès que ce seuil est dépassé, une commande de vérification est automatiquement exécutée afin de confirmer l’état réel du service.
Lorsque Shinken ne reçoit aucun résultat pendant une durée supérieure à ce seuil :
Il considère le statut comme expiré.
Il exécute alors la commande définie par la propriété Commande de vérification ( clé d'import check_command ).
Cette commande sera relancée périodiquement, à un intervalle correspondant au seuil d’expiration, jusqu’à ce qu’un nouveau résultat soit reçu.
La propriété Vérification que l'état reçu des outils externes ne soit pas expiré( clé d'import check_freshness )permet d’activer ou désactiver cette fonctionnalité pour chaque hôte ou check.
| Warning |
|---|
La propriété Commande de vérification est commune aux modes passif et actif. Lorsque les deux modes sont activés, la même commande est utilisée à la fois pour les vérifications planifiées par Shinken et pour celles déclenchées automatiquement en cas d’expiration du résultat. |
Si le mode actif et passif sont activés
La gestion de l’expiration des statuts ne sera active que si l’élément est exclusivement en mode passif.
Si un élément combine les modes actif et passif, le mécanisme d’expiration des statuts ne s’applique pas même s'il est configuré.
Si seul le mode passif est activé
Si la gestion de l’expiration des statuts n’est pas activée, l’absence de résultats peut masquer des problèmes critiques, tels qu’une coupure réseau ou une défaillance de l’outil externe.
Il est donc fortement recommandé d’activer le mécanisme d’expiration des statuts afin de confirmer l’état réel du service.
Deux approches sont possibles :
- Développer une commande spécifique : Cette commande a pour rôle de vérifier s’il existe effectivement un problème lorsque le seuil d’expiration est dépassé. Par exemple, elle peut contrôler l’état des équipements réseau pour déterminer si leur indisponibilité explique l’absence de retours.
- Utiliser la commande livrée par Shinken cmd-check__shinken-build-result : Lorsque le développement d’une commande dédiée n’est pas envisageable, Shinken propose cette commande générique. Elle permet de construire le retour de la sonde ( statut, résultat, résumé et métriques ) à partir d'arguments.
- Couplée au mécanisme d’expiration des statuts, elle peut générer une erreur dès que le seuil est franchi, afin d’alerter rapidement sur un risque lié à l’absence de réponse.
- Grâce à l’utilisation des variables ( voir la pageLes Variables ( Remplacement dynamique de contenu - Anciennement les Macros ) ), il est également possible de réutiliser les résultats de la dernière vérification pour générer un retour cohérent et adapté à la situation.
La commande cmd-check__shinken-build-result dispose des options suivantes :
| Scroll Title | |||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||
|
Exemple de gestion de l'expiration de l'état d'un check en mode passif à l'aide de la commande cmd-check__shinken-build-result
On crée un check appliqué à l'hôte "CHECK WITH PASSIVE MODE" avec le mode passif d'activé et le mode actif de désactivé.
On active l'expiration du statut avec un seuil d'expiration de 30 secondes.
| Panel |
|---|
|
On utilise comme commande de vérification, la commande fournie par Shinken cmd-check__shinken-build-result.
La commande utilise trois paramètres :
- La donnée du check STATUS.
- La donnée du check OUTPUT.
- La variable : $LONGSERVICEOUTPUT$.
| Panel |
|---|
|
On crée les données sur le check.
- STATUS : 2
- OUTPUT : Le résultat du check a expiré. Vérifier l'état du réseau et de l'élément.
Il faut ensuite attacher le check sur un hôte en le pousser en production.
| Panel |
|---|
|
Si Shinken ne reçoit aucune donnée pour ce check pendant plus de 30 secondes, la commande de vérification est automatiquement exécutée afin de signaler une suspicion sur l’état du service.
Dans l’Interface de Visualisation, le check apparaît alors en erreur, accompagné du résultat court défini, et du précédent résultat long.
| Panel |
|---|
|
Soumettre les résultats de checks passifs
Pour permettre la soumission de check passif dans votre achitecture Shinken, vous devez activer un module du receiver: le webservices-reciever
La documentation ( Module receiver-module-webservice ) du module vous décrit comment envoyer des checks externes aux Receivers.| Excerpt | |||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||
|