Contexte
Le modèle shinken-reactionner vous permet de superviser un hôte hébergeant le démon Reactionner.
Description du modèle
Modèle d'hôte correspondant: shinken-reactionner (notez que ce modèle hérite du modèle shinken et shinken-deamon )
Afin de superviser le démon Reactionner, le modèle shinken- reactionner appliqué à votre hôte, attachera plusieurs checks qui vérifieront la santé et la performance de ce démon.
Checks
- Reactionner - $KEY$ - Running Well
Vérifie que le Reactionner est joignable sur le réseau, affiche son numéro de version, ses tags et le statut de connexion avec les Schedulers
- Reactionner - $KEY$ - Performance
Affiche les statistiques des performances de l'exécution des checks dans le ReactionnerSi jamais le démon Arbiter est en exécution sur une machine virtuelle supervisé par VMware, alors le pourcentage de temps de vol de CPU (CPU Ready) sera affiché.
Paramètre du check
Les checks du Reactionner peuvent être configurés via des données fournies par le modèle.
Les données suivantes sont disponibles pour le Reactionner:
| 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 Reactionner | http | shinken |
| CHECK_SHINKEN_TIMEOUT | Timeout utilisé pour établir la connexion avec le Reactionner | 3 | shinken |
| REACTIONNER_PORT | Port utilisé pour établir la connexion avec le Reactionner | 7769 | Locale |
| REACTIONNER_LIST | Liste de Reactionner (Multi-démon) | reactionner-master$($_HOSTREACTIONNER_PORT$)$ | Locale - Duplicate For Each |
| NB_CHECK_IN_TIMEOUT_TOLERATE | Nombre de checks en timeout provoquant une sortie en erreur du check | 0 | Locale |
| REACTIONNER_NB_CHECK_IN_TIMEOUT_TOLERATE | Nombre de checks en timeout provoquant une sortie en erreur du check | $_HOSTNB_CHECK_IN_TIMEOUT_TOLERATE$ | Locale |
| ACTIVE_REACTIONNER_LATENCY | Latence de connexion (en secondes) au-delà de laquelle le check sort en erreur | 0.5 | Locale |
| THRESHOLD_CPU_STOLEN_WARNING | Seuil de CPU volé (en pourcentage) sur une machine virtuelle supervisée par VMware avant de déclencher un warning | 5 | shinken-deamon |
| THRESHOLD_CPU_STOLEN_CRITICAL | Seuil de CPU volé (en pourcentage) sur une machine virtuelle supervisée par VMware avant de déclencher un critique | 10 | shinken-deamon |
Détail des commandes
Nom du check | Commande du check | Ligne de commande |
|---|---|---|
| Reactionner - $KEY$ - Performance | check_shinken_reactionner!stats!$VALUE1$ | $PLUGINSDIR$/check_shinken -H "$HOSTADDRESS$" -p "$ARG2$" --shinkenversion "$SHINKENVERSION$" -t reactionner -m $ARG1$ --active_reactionner_latency "$_HOSTACTIVE_REACTIONNER_LATENCY$" --check_tolerate "$_HOSTNB_CHECK_IN_TIMEOUT_TOLERATE$" --timeout $_HOSTCHECK_SHINKEN_TIMEOUT$ -w $_HOSTTHRESHOLD_CPU_STOLEN_WARNING$ -c $_HOSTTHRESHOLD_CPU_STOLEN_CRITICAL$ |
| Reactionner - $KEY$ - Running Well | check_shinken_reactionner!alive!$VALUE1$ | $PLUGINSDIR$/check_shinken -H "$HOSTADDRESS$" -p " $ARG2$ " --shinkenversion "$SHINKENVERSION$" -t reactionner -m $ARG1$ --active_reactionner_latency "$_HOSTACTIVE_REACTIONNER_LATENCY$" --check_tolerate "$_HOSTNB_CHECK_IN_TIMEOUT_TOLERATE$" --timeout $_HOSTCHECK_SHINKEN_TIMEOUT$ -w $_HOSTTHRESHOLD_CPU_STOLEN_WARNING$ -c $_HOSTTHRESHOLD_CPU_STOLEN_CRITICAL$ |
Les modes dépréciés ("-m") :
- api_connection
- cpu_load
- overload_protection
Description des erreurs de Reactionner - $KEY$ - Running Well
Problème de surcharge des disques constaté lors de l'écriture de logs
- En cas de disques trop lent sur le volume des logs, le check sera mis en WARNING avec l'erreur suivante.
|
Problème de conflits d'Arbiters
- Conflit 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érents, mais qui ont le même nom. On sort également en CRITICAL mais en avertissant que les noms sont identiques, et en indiquant comment retrouver les serveurs en question, en trouvant leur valeur dans le fichier /var/lib/shinken/server.uuid
|
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érences des données de supervision.
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 peux être dû:
- les arbiters MASTER et SPARE sont réellement éteints
- les arbiter 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 temps pris en compte comme limite de dernière connexion est de check_interval * max_check_attempts du démon (définis dans sa configuration). Les valeurs par défauts sont de 60s*3, soit 3 minutes.
|
Description des erreurs de Reactionner - $KEY$ - Performance
Erreur de vol de CPU
- Conflit d'Arbiters qui ont le même nom d'Architecture :
Lorsque le CPU se fait voler trop de temps de calcul, le check sera mis en WARNING ou en CRITIQUE (en fonction du taux de vol) avec l'erreur suivante.