Contexte
Le modèle shinken-poller vous permet de superviser un hôte hébergeant le démon Poller.
Description du modèle
Modèle d'hôte correspondant: shinken-poller (notez que ce modèle hérite du modèle shinken)
Afin de superviser le démon Poller, le modèle shinken-poller appliqué à votre hôte, attachera plusieurs checks qui vérifieront la santé et la performance de ce démon.
Checks
| Nom du check | Description | Exemple de résultat |
|---|---|---|
| Poller - $KEY$ - Running Well | Vérifie que le Poller est joignable sur le réseau avec son numéro de version, affiche ses tags et le statut de connexion avec les schedulers |  |
| Poller - $KEY$ - Performance | Affiche les statistiques des performances de l'exécution des checks dans le Poller |
|
Paramétrage des checks
Les checks du Poller peuvent être configurés via des données fournies par le modèle.
Les données suivantes sont disponibles pour le Poller:
| Nom de la donnée | Description | Valeur par défaut | Hérité du modèle d'hôte ou locale |
|---|---|---|---|
| SHINKEN_PROTOCOL | Protocole utilisé pour établir la connexion avec le Poller | http | shinken |
| POLLER_PORT | Port utilisé pour établir la connexion avec le poller | 7771 | Locale |
| POLLER_LIST | Liste de Poller (Multi-démon) | poller-master$($_HOSTPOLLER_PORT$)$ | Locale - Duplicate For Each |
| NB_CHECK_IN_TIMEOUT_TOLERATE | Nombre de checks en timeout provoquant une sortie en erreur du check | 0 | Locale |
| POLLER_NB_CHECK_IN_TIMEOUT_TOLERATE | Nombre de checks en timeout provoquant une sortie en erreur du check | $_HOSTNB_CHECK_IN_TIMEOUT_TOLERATE$ | Locale |
| ACTIVE_POLLER_LATENCY | Latence de connexion (en secondes) au-delà de laquelle le check sort en erreur | 0.5 | Locale |
Données de performances
Les checks du modèle shinken-poller enregistrent des données de performance, qui peuvent ensuite être affichées dans l'interface de Visualisation sur l'Onglet Graphes ou bien le Widget Graphique.
| Nom du check | Nom de la métrique | Explication |
|---|---|---|
Poller - $KEY$ - Running Well | nb_check_in_timeout | Nombre de checks qui sont entrés en timeout sur le Poller pendant les 20 dernières minutes. Cette durée est configurable dans le fichier de configuration du Poller, avec l'option keep_timeout_time (par défaut 1200s) |
Poller - $KEY$ - Performance | nb_action_done_per_sec | Nombre moyen de checks exécutés par le Poller (moyenne glissante calculée sur 1mn) |
Poller - $KEY$ - Performance | poller_load_state | Booléen (0 ou 100) qui indique si le Poller a atteint sa charge maximale:
|
Poller - $KEY$ - Performance | cpu_usage_percent | Pourcentage de temps processeur utilisé par le Poller |
Poller - $KEY$ - Performance | used_ram_percent | Pourcentage de mémoire utilisée sur le serveur |
Détail des commandes
Nom du check | Commande du check | Ligne de commande |
|---|---|---|
| Poller - $KEY$ - Performance | check_shinken_poller!stats!$VALUE1$ | $PLUGINSDIR$/check_shinken -H "$HOSTADDRESS$" -p "$ARG2$" --shinkenversion "$SHINKENVERSION$" -t poller -m $ARG1$ --active_poller_latency "$_HOSTACTIVE_POLLER_LATENCY$" --check_tolerate "$_HOSTNB_CHECK_IN_TIMEOUT_TOLERATE$" |
| Poller - $KEY$ - Running Well | check_shinken_poller!alive!$VALUE1$ | $PLUGINSDIR$/check_shinken -H "$HOSTADDRESS$" -p "$ARG2$" --shinkenversion "$SHINKENVERSION$" -t poller -m $ARG1$ --active_poller_latency "$_HOSTACTIVE_POLLER_LATENCY$" --check_tolerate "$_HOSTNB_CHECK_IN_TIMEOUT_TOLERATE$" |
Les modes dépréciés ("-m") :
- api_connection
- cpu_load
- overload_protection
Interprétation des données de l'état de santé du Poller
Statistiques de l'état de santé du Poller
Le check "Poller - Running Well" vérifié l'état de santé du Poller supervisé.
Il remonte plusieurs informations sur le statut du Poller:
- 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.
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 nous 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) pendant 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 une 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 des statistiques de performance du Poller
La supervision d'un démon Poller présente un grand nombre de statistiques de performances qui permettent de visualiser le travail effectué par le Poller. Le Poller a pour rôle d'executer les checks.
Il est ainsi souvent un des premiers démons que l'on regarde lorsqu'on veut visualiser combien de checks sont exécutés. Aussi, pour dimensionner correctement une installation Shinken Entreprise, il est important de pouvoir visualiser combien de checks un Poller est capable d'exécuter pour pouvoir décider d'ajouter ou retirer des Pollers de la configuration.
Les checks du Poller fournis dans le pack Shinken fournissent donc un grand nombre de données sur les performances du Poller.
Statistiques générales sur l’exécution des checks
La première statistique remontée par le check est le nombre de checks effectués par seconde par le Poller supervisé.
Dans cet exemple, le Poller effectue 1.9 checks par seconde en moyenne, tous checks confondus.
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 est affiché 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.
Charge du Poller
Le check du Poller fournit aussi la charge du Poller. Il s'agit d'un indicateur général indiquant si le Poller peut encore supporter des checks supplémentaires, ou si il est chargé au maximum. Cet indicateur n'est pas lié aux autres indicateurs de performances de la machine (File d'attente CPU, mémoire).
Une pastille orange précédant la mention "Poller load" signifie que le Poller ne peut plus prendre de checks supplémentaires. Cette pastille indique que le Poller fonctionne à la vitesse maximale qui lui est permise par le processeur.
C'est donc un signe indiquant qu'il faudrait ajouter un Poller supplémentaire dans l'architecture Shinken.
Utilisation du CPU
Le Poller se limite intelligemment selon différents critères pour éviter de surcharger inutilement la machine sur laquelle il est exécuté. Le premier critère de limitation est l'utilisation du CPU de la machine par le démon (et l'exécution des checks).
Si le Poller se rend compte que le CPU de la machine sur laquelle il est exécuté est surchargé, il se régule pour exécuter moins de checks et éviter de rendre la machine inutilisable.
Dans le check "Poller - Performance", la quantité de CPU utilisée par les checks est affichée dans le Résultat du check.
Si le CPU de la machine hébergeant le Poller est utilisé de manière intensive, le résultat du check "Poller - Performance" avertit de l'utilisation trop élevée du CPU. Dans ce cas, le Poller se limite et n’exécute plus de checks supplémentaires tant que l'utilisation du CPU est trop élevée.
La ligne indiquant la charge du Poller indique alors que le CPU est surchargé.
Utilisation de la mémoire (RAM)
Si le CPU n'est pas le facteur limitant pour le fonctionnement du Poller, l'état de la mémoire du serveur est alors vérifiée. Dans le résultat du check "Poller - Performance", l'utilisation de la mémoire sur le serveur est indiquée.
Si l'utilisation de la mémoire (RAM) sur le serveur dépasse le seuil définit dans la configuration du Poller, le résultat du check "Poller - Performance" affiche une avertissement indiquant l'utilisation excessive de la mémoire. Lorsque cet avertissement est affiché, le Poller n'exécute plus de checks supplémentaires tant que l'utilisation de la mémoire est supérieure au seuil défini.
Vérification de la charge de la machine
Le Poller possède une dernière mesure de performance qu'il observe et selon laquelle il limite son activité. Après la vérification de l'utilisation du CPU du Poller et de la mémoire du serveur, le Poller vérifie le nombre de processus dans la file d'attente du processeur.
En fonction de la limite de processus dans la file d'attente du processeur, le Poller décide si il faut exécuter des checks supplémentaires.
Le nombre de processus dans la file d'attente du processeur est affiché dans le résultat du check "Poller - Performance".
Le nombre de processus dans la file d'attente du processeur est aussi accompagné d'une pastille indiquant le statut de cette mesure. Lorsque le nombre de processus est supérieur à la limite définie dans la configuration, cette pastille indique ce dépassement.
Dans ce cas, le Poller n'exécutera plus de checks supplémentaires tant que le nombre de processus dans la file d'attente du processeur sera supérieur au seuil choisi.
