Contexte

Le check Broker - DB - Connection vérifie le temps de connexion à la base de données.

Paramétrage

Le check utilise la ligne de commande suivante :

$PLUGINSDIR$/check_shinkendb.py -D -H "$HOSTADDRESS$" -P "$_HOSTDB_PORT$" --connection-method "$_HOSTDB_CONNECTION_METHOD$" 
--ssh-user "$_HOSTDB_SSH_USER$" --ssh-keyfile "$_HOSTDB_SSH_KEY$" --ssh-tunnel-timeout "$_HOSTDB_SSH_TUNNEL_TIMEOUT$" 
-A connect -W "$_HOSTDB_CONNECT_WARN$" -C "$_HOSTDB_CONNECT_CRIT$"

Données utilisées provenant du modèle

Données communes pour les checks du modèle

Pas de données communes pour ce check.

Données spécifiques pour ce check

Les données DFE ( Duplicate Foreach )

 Pas de données DFE pour ce check.

Données utilisées provenant du check

Pas de données spécifiques pour ce check.

Données globales

Propriétés de l'hôte

Résultat

Exemple

Interprétation

Statut

Il peut prendre deux 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 :
  • CHECK_SHINKEN_TIMEOUT
    
    

• Voici un tableau récapitulatif du statut attendu suivant le retour de sonde :
  
  

Résultat

Renvoi au format texte : 

• Si les modules du démon fonctionne correctement
• le nombre de worker par module

Résultat Long

Précise la liste des modules du démon avec le nombre d'hôtes géré

Description des erreurs

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 la commande shinken-healtcheck, afin qu'il soit rapidement identifié et corrigé.

Problème de conflits d'Arbiters

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

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érence des données de supervision.

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
    
    

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)
    
    

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.

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

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.
    
    

Le démon est en cours d'arrêt

Lorsque le démon est en cours d'arrêt, le check le signale, et les informations relatives aux modules ne sont plus disponibles

Métriques