Page History

Contexte

Vérifie que le démon Scheduler 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  ).

La supervision d'un démon Scheduler présente un grand nombre de statistiques de performances qui permettent de visualiser le travail d'ordonnancement effectué par le Scheduler, ainsi que les statistiques des Poller qui viennent se connecter à celui-ci.

Le démon Scheduler va effectuer tout le travail d'ordonnancement, et c'est à lui que vont s'adresser ( en autres ) les démons Poller et Reactionner pour récupérer les checks et les notifications à effectuer. Son bon fonctionnement est donc vital au bon fonctionnement de votre architecture Shinken. Aussi, pour dimensionner correctement une installation Shinken Entreprise, il est important de pouvoir visualiser combien de checks ses Poller satellites peuvent traiter, ainsi que leurs utilisations CPU et RAM.

Les checks du Scheduler fournis dans le pack Shinken proposent donc un grand nombre de données sur les performances du Scheduler et de ses Pollers.

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

Données spécifiques pour ce check

 Pas de données spécifiqiue 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

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    
  •  POLLER_NB_CHECK_IN_TIMEOUT_TOLERATE
  •  CHECK_SHINKEN_TIMEOUT 

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

Résultat

Renvoi au format texte : 

• L'état de fonctionnement du Scheduler, ainsi que le nombre d'hôtes, de clusters, de checks et le nombre total d'éléments gérés par le Scheduler.

Résultat Long

• Le nombre de checks effectués par seconde par le Poller supervisé.

Résultat Long

Dans le Résultat long du check "Poller - Performance", deux tableaux présentent des statistiques sur les temps d'exécution des checks dans le Poller.

• Le premier tableau affiche les 5 checks consommant le plus de temps CPU parmi l'ensemble des checks exécutés sur le Poller.
  Dans ce tableau, pour chaque check sont affichés le nom du check, l'hôte sur lequel il est accroché, et le temps d'exécution du check.

• Un deuxième tableau présente la répartition du temps d'exécution des checks. Dans le tableau en exemple, on voit que les checks exécutés sur ce Poller s'exécutent majoritairement en moins de 50ms.

Renvoi au format texte :

Métriques