Contexte

Le check Receiver - $KEY$ - Alive vérifie que le démon Receiver peut être correctement contacté sur le réseau.

Il donne également la version du démon ( Résultat court ) et ainsi que les modules opérationnels ( Résultat long ).

Paramétrage

Données utilisées provenant du modèle

Données communes pour les checks du modèle

Données spécifiques pour ce check

NomModifiable sur UnitésDéfautValeur par défaut à l'installation de ShinkenDescription
ARBITER_PORT

Modèle d'hôte

( Onglet Données )

---77737773

Configuration du port de communication avec du Receiver.

Autres check(s) impacté(s) :

Note : Cette valeur remplacera dans la commande la valeur $ARG2$

Les données DFE ( Duplicate Foreach )


Données utilisées provenant du check

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

Données globales

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 :
    • HOSTCHECK_SHINKEN_TIMEOUT

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

Situation

Statut

Si un démon est bloqué et doit être redémarré

CRITIQUE

Si il y a un problème de conflits d'Arbiters

CRITIQUE

si les serveurs ne sont pas à la même heure

CRITIQUE

Si erreur de surcharge des disques de logs

ATTENTION 

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

ATTENTION 

Si le démon est en cours d'arrêt

ATTENTION 

Si la dernière connexion de l'Arbiter remonte à trop longtemps

ATTENTION 

Si la sonde n'a pas eu de réponse avant le temps maximum

  • Si supérieur à HOSTCHECK_SHINKEN_TIMEOUT ( par défaut : 3 sec )
INCONNU

Résultat

Renvoi au format texte : 

  • Si le démon fonctionne correctement, la version installée et le temps qu'a pris le check pour établir la  communication avec le check.

Résultat Long

Précise le fonctionnement des modules du Receiver, leur statut, le nombre de redémarrages lors des 24 dernières heures, la date de dernier redémarrage et les sous-modules

Description des erreurs

Erreur de surcharge des disques de logs
  • Disque des logs trop lent :

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

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.

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