Poller - $KEY$ - Running Well

Contexte

Vérifie que le démon Poller peut être correctement contacté sur le réseau et affiche son numéro de version.

Affiche également le nombre d'éléments qu'il gère dans un tableau, en distinguant les hôtes, les Clusters et les Checks et le Total des éléments. (   Résultat court   )

Présente la liste les démons auxquels le Scheduler doit se connecter, et l'état des connexions (  Résultat long  ).

Donne un état des modules chargés (  Résultat long  ).

Paramétrage

Le check utilise la ligne de commande suivante :

$PLUGINSDIR$/check_shinken -H "$HOSTADDRESS$" -p "$ARG2$" --shinkenversion "$SHINKENVERSION$" -t scheduler -m $ARG1$ -l "lck-$LASTSERVICECHECK$" --passive_poller_latency "$_HOSTPASSIVE_POLLER_LATENCY$" --timeout "$_HOSTCHECK_SHINKEN_TIMEOUT$" -w "$_HOSTTHRESHOLD_CPU_STOLEN_WARNING$" -c "$_HOSTTHRESHOLD_CPU_STOLEN_CRITICAL$" --scheduler_too_old_retention_save_margin "$_HOSTSCHEDULER__RETENTION__RENTENTION-IS-TOO-OLD-AFTER_X_MINUTES$"

Données utilisées provenant du modèle

Données communes pour les checks du modèle

Provenant du modèle shinken

Provenant du modèle shinken-daemon

Provenant du modèle shinken-poller

Données spécifiques pour ce check

Les données DFE ( Duplicate Foreach )

Données utilisées provenant du check

  Pas de données provenant du check pour ce check.

Données globales

Résultat

Exemple

Exemple d'un état de santé dégradé du Poller

Lorsque le Poller rencontre des problèmes qui peuvent signifier un fonctionnement dégradé, ces problèmes sont également remontés dans le résultat du check "Poller - Running Well".

Lorsque certains checks ont un temps d'exécution supérieur aux différents seuils définis, ils sont répertoriés dans le résultat du check "Poller - Running Well" pour permettre d'avertir des potentielles erreurs sur ces checks ou du Poller.

Dans l'exemple, le check signale que 10 checks ont pris plus que 10 secondes pour s'exécuter pendant les 20 dernières minutes, et ont leur exécution a donc été arrêtée de force.

La durée de temps ( en secondes ) durant laquelle les checks sont conservés dans l'ensemble des checks en timeout est configurable dans le fichier de configuration du Poller concerné.

Il est également possible de définir un seuil de tolérance afin d'afficher un avertissement seulement lorsqu'il y a plus qu'un certain nombre de checks en timeout. Pour cela, il faut modifier la donnée NB_CHECK_IN_TIMEOUT_TOLERATE dans l'hôte concerné dans la configuration.

define poller {
    ...
    keep_timeout_time    1200
    ...
}

Interprétation

Statut

Il peut prendre quatre valeurs  OK / CRITIQUE / ATTENTION   /   INCONNU .

• Le statut va dépendre du retour de sonde et de la configuration spécifique du check pour les données suivantes :
  •   THRESHOLD_CPU_STOLEN_CRITICAL
    
  •  THRESHOLD_CPU_STOLEN_WARNING
  •  SCHEDULER__RETENTION__RENTENTION-IS-TOO-OLD-AFTER_X_MINUTES    
  •  CHECK_SHINKEN_TIMEOUT 

• Voici un tableau récapitulatif du statut attendu suivant le retour de sonde :

Les vérifications communes

Les vérifications spécifiques

Résultat

Renvoi au format texte : 

• Une mention qui indique si le Poller est actif ou passif. Dans l'exemple, on a affaire à un Poller actif.
• La liste des tags du Poller. Dans l'exemple, aucun tag n'est défini sur le Poller.
• La latence de connexion avec le ou les Schedulers du royaume et des sous-royaumes

Résultat Long

Pas de résultat long pour ce check.

Description des erreurs

Erreur d'un démon bloqué, qui doit être redémarré

• Si un démon est dans un état bloqué, il doit être redémarré. Si c'est le cas :
  • les checks seront en ERROR avec le message suivant,
  • il faut ouvrir un ticket au support pour analyser le blocage

Un démon spare n'est assigné sur aucun démon master

Un spare n'est pas assigné à un démon master :

Lorsqu’un démon Broker spare n'est assigné par aucun démon master, il est inutile, et remonte en erreur dans le check, tout comme dans la commande shinken-healthcheck, afin qu'il soit rapidement identifié et corrigé.

Problème de conflits d'Arbiters

• Conflits d'Arbiters :
  
  Si le démon est contacté par des Arbiters qui ne sont pas sur la même architecture ( par exemple un Arbiter de Production et un autre de l'environnement de Testing ), le check sera mis en CRITICAL .

• Conflit d'Arbiters qui ont le même nom d'Architecture :

Comme dans le cas précédent, le démon est contacté par des Arbiters d'architectures différentes, mais qui ont le même nom. On sort également en CRITICAL mais en avertissant que les noms sont identiques, et en indiquant où changer le nom des architectures.

Les serveurs ne sont pas à la même heure

Si le serveur n'est pas à la même heure que le serveur Arbiter ( qui fait office de référence ), une erreur CRITICAL sera levée, car des temps différents sur les différents serveurs va avoir des effets désastreux sur la cohérence des données de supervision.

Erreur de surcharge des disques de logs

En cas de disques trop lent sur le volume des logs, le check sera mis en WARNING avec l'erreur suivante.

Le démon a bloqué une tentative de chargement d'objet malveillant

Il est possible qu'un démon puisse détecter et bloquer une tentative d'injection d'objet malveillant par le biais de l'une de ses routes.

Un message est remonté :

• le nombre total de ces tentatives que le démon a bloquées ce jour ( le compte commence à minuit ) ;
• pour chacune des tentatives ( maximum 3 ) :
  • descriptif de l'objet que l'attaquant essaye de charger,
  • sa provenance de l'attaque, par exemple le nom de la route utilisée, et l'IP à la source de l'attaque,
  • sa date.

Le démon est en cours d'arrêt

Lorsque le démon est en cours d'arrêt, le check le signale, et les informations relatives aux modules ne sont plus disponibles :

La dernière connexion de l'Arbiter remonte à trop longtemps

Si la dernière connexion de l'Arbiter remonte à trop de temps, le démon va lever un WARNING . Ceci peut être dû :

• Les Arbiters MASTER et SPARE sont réellement éteints
• Les Arbiters MASTER et SPARE sont en train d'envoyer des configurations à d'autres démons, et ne peuvent donc pas contacter ce démon pour l'instant.

Le démon a chargé une configuration enregistrée

Lorsque le module last-configuration-recorder est actif, pour les démons de type

• Broker,
• Poller,
• Reactionner,
• Receiver et
• Scheduler,

Au démarrage, le démon charge la précédente configuration qu'il a reçue de l'Arbiter, en attendant que ce dernier le contacte.

• Il permet un redémarrage du démon même si l'Arbiter ne peut pas joindre le démon ( ex : coupure réseau  ),
• Cela permet aussi de rendre le redémarrage du démon plus rapide, dans le cas où l'Arbiter n'a pas changé de version de configuration.

Un WARNING indique que le démon n'a pas encore été contacté par l'Arbiter.

Erreur de vol de CPU

Seulement si la machine virtuelle est hébergée sur un hyperviseur VMWare

• Si la VM se fait voler trop de temps de calcul (CPU Stolen), le check sera mis en WARNING ou en CRITIQUE ( en fonction du taux de vol fixé par défaut ou indiqué par l'utilisateur ).
  • on peut avoir plus d'informations sur cet indicateur et comment réduire la perte de temps de la VM sur la page Machine VMWare avec un fort taux de CPU Stolen (%ready + %costop)

Métriques