Page History

Contexte

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 Pollers 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 l'architecture Shinken. Aussi, pour dimensionner correctement une installation Shinken Entreprise, il est important de pouvoir visualiser combien de checks ses Poller Pollers 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

Provenant du modèle shinken

Provenant du modèle shinken-daemon

Provenant du modèle shinken-scheduler

Données spécifiques pour ce check

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

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.
  

  
  

Les vérifications communes

Les vérifications spécifiques

Résultat

Renvoi au format texte : 

• 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.

Description des erreurs

Problèmes réseau

Latence réseau importante vers des Pollers passif

Quand la connexion vers un ou plusieurs Pollers passifs souffre d'une latence réseau trop importante, cette information est remontée dans le résultat court  

La récupération des données de connectivité prend trop de temps

Le timeout du check est trop court

Quand le timeout associé à ce check est inférieur au paramètre timeout renseigné dans la configuration d'un des démons que doit contacter le Scheduler, il se peut que la connexion vers ce démon échoue lors du test de connectivité.

Résultat court :

Un message d'avertissement signale que certains démons nécessitent un timeout plus élevé pour être contacté, et une valeur conseillée est affichée.

Résultat long :

Dans ce cas, le Status dans le  résultat long  précise que l'erreur peut être liée au délai trop court accordé pour tester la connexion. Il est alors conseillé d'augmenter le timeout du check pour que le test soit pertinent.

Démons passifs injoignables

Métriques

Résultat long :

Le tableau du résultat long , indique les problèmes de connectivité dans la colonne Status, avec un message précisant leur nature. 

Schedulers injoignables

Résultat court  :

Quand le Scheduler ne parvient pas à communiquer avec un ou plusieurs Schedulers du royaume, ceux-ci sont listés avec :

• Leur nom
• Leur adresse
• Leur port de connexion

Un compteur indiquant le nombre de Schedulers injoignables et le nombre total de Schedulers disponibles est également affiché.

L'indisponibilité d'un ou plusieurs Scheduler pouvant perturber le calcul des états de clusters, un message d'avertissement le précisant est également ajouté.

Résultat long  :

Le tableau listant les connexions du Scheduler, indique les problèmes de connectivité vers les autres Schedulers dans la colonne Status, avec un message précisant la nature du problème.

Problème de conflits d'Arbiters

• 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 de vos architectures.

Métriques