Erreur de surcharge des disques de logsEn cas de disques trop lent sur le volume des logs, le check sera mis en WARNING avec l'erreur suivante.
Erreur de vol de CPUSeulement si votre machine virtuelle est hébergé sur un hyperviseur VMWare
|
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é.
|
|
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.
|
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.
![]() |
Si la dernière connexion de l'Arbiter remonte à trop de temps, le démon va lever un WARNING . Ceci peux être dû:
|
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. |
|
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é :
|
Lorsque le démon est en cours d'arrêt, le check le signale, et les informations relatives aux modules ne sont plus disponibles
|