Page History

Description du modèle

Modèle d'hôte correspondant:  shinken-broker    (notez que ce modèle hérite du modèle shinken, shinken-deamon et shinken-broker-db)

Afin de superviser le démon Broker, le modèle  shinken-broker  appliqué à votre hôte, attachera plusieurs checks qui vérifieront la santé et la performance de ce démon.

Checks

• Broker - $KEY$ - Alive
  
  Vérifie que le démon Broker peut être correctement contacté sur le réseau ; la version du démon est affichée également ( Résultat court ) et aussi que les modules sont opérationnels ( Résultat long ).
  Si jamais le démon Arbiter est en exécution sur une machine virtuelle supervisée par VMware, alors le pourcentage de temps de vol de CPU ( CPU Ready ) sera affiché.

• Broker - $KEY$ - Performance API Connection
  
  Vérifie les temps de connexion vers le Broker
  

• Broker - $KEY$ - Performance Modules Queues
  
  Vérifie les performances des modules du Broker
  

• Broker - DB - Connection
  
  Vérifie le temps de connexion à la base de données

• Broker - DB - Last Flush Time
  
  Vérifie la durée du dernier "Flush" de la base de données

• Broker - DB - Open Connections
  
  Vérifie le nombre de connexions en cours sur la base de données

Si un démon spare n'est pas obligé n'a pas à avoir la même liste de module que son master

Quand le master est configuré pour avoir un spare qui n'a pas la même liste de modules que lui, le check ajoute un message d'information le précisant :

Consulter l'option suivante dans la configuration du master ( voir la page Le Broker )

Paramétrage des Checks

Les checks du Broker peuvent être configurés via des données fournies par le modèle.

Les données suivantes sont disponibles:

Voir la page de Sécurisation des connexions aux bases MongoDB pour plus d'information sur un paramétrage sécurisé.

Détail des commandes

Description des erreurs de Broker - $KEY$ - Alive

Erreur de surcharge des disques de logs

• En cas de disques trop lent sur le volume des logs, le check sera mis en WARNING avec l'erreur suivante.

Erreur de vol de CPU

Seulement si votre machine virtuelle est hébergé sur un hyperviseur VMWare

• Votre machine à du vol de CPU :
  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.
  • Vous pouvez avoir plus d'information sur cet indicateur et comment réduire la parte de temps de la VM sur la page Machine VMWare avec un fort taux de CPU Stolen (%ready + %costop)

Un démon spare n'est assigné sur aucun démon master

• Un spare n'est pas assigné à un démon master: lorsqu’un démon Broker spare n'est assigné par aucun démon master, il est inutile, et remonte en erreur dans le check, tout comme dans le shinken-healtcheck, afin qu'il soit rapidement identifié et corrigé.

Erreur d'un démon bloqué, qui doit être redémarré

• Si un démon est dans un état bloqué, il doit être redémarré. Si c'est le cas:
  • les checks seront en ERROR avec le message suivant,
  • il faut ouvrir un ticket à votre support pour analyser le blocage

Le démon a bloqué une tentative de chargement d'objet malveillant

Il est possible qu'un démon puisse détecter et bloquer une tentative d'injection d'objet malveillant par le biais de l'une de ses routes.

Un message est remonté :

• le nombre total de ces tentatives que le démon a bloqué ce jour ( le compte commence à minuit ) ;
• pour chacune des tentatives ( maximum 3 ) :
  • descriptif de l'objet que l'attaquant essaye de charger,
  • sa provenance de l'attaque, par exemple le nom de la route utilisée, et l'IP à la source de l'attaque,
  • sa date.

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.