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 - Running Well | Vérifie que le Poller est joignable sur le réseau, affiche ses tags et le statut de connexion avec les schedulers |
|
| Poller - 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 |
| NB_CHECK_IN_TIMEOUT_TOLERATE | Nombre de checks en timeout provoquant une sortie en erreur du check | 0 | Locale |
| ACTIVE_POLLER_LATENCY | Latence de connexion (en secondes) au-delà de laquelle le check sort en erreur | 0.5 | Locale |
Interprétation des données 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 Poller 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.
|
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.
C'est donc un signe indiquant qu'il faudrait ajouter un Poller supplémentaire dans l'architecture Shinken.
|
|
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 consomme majoritairement entre 50ms et 200ms.
Si le temps moyen d'execution des checks est très long, ou très court, il est possible de modifier les réglagles des périodes de temps du tableau dans le fichier de configuration du poller concerné.
Dans le fichier de configuration du Poller en question, l'option "exec_stat_range" doit être modifiée.
define poller {
...
# Ranges for the check : poller statistics
#exec_stat_range 50, 100, 200, 300, 400
...
} |
Utilisation du CPU
Le Poller se limite intelligemment selon différent 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).