Page History

Contexte

Le check Broker - $KEY$ - Module Event Manager Writer permet de superviser la partie écriture du module Event Manager ( voir la page Module event-manager-writer ) au niveau du démon Broker (voir la page Le Broker )Livedata affiche les statistiques des requêtes effectuées comme :

• le nombre de requêtes effectuées sur la dernière heure,
• et le temps de réponse moyen des requêtes.

Paramétrage

Le check utilise la ligne de commande suivante :

$PLUGINSDIR$/check_shinken_module_event_manager_writer.py -H "$HOSTADDRESS$"  -p "$ARG1$$ARG2$" 
--shinkenversion "$SHINKENVERSION$" -t broker 
-m $ARG1$ -n $ARG3$ --livedata_warning "$_HOSTLIVEDATA_WARNING$" --livedata_error_displayed_limit "$_HOSTLIVEDATA_HOSTMINUTESDISPLAYED_OFERROR_STATS$LIMIT$" 
--timeout "$_HOSTCHECK_SHINKEN_TIMEOUT$"

Les données

Données utilisées provenant du modèle

Provenant du modèle shinken-daemon

Données

spécifiques pour ce check

LIVEDATA_

WARNING

Temps maximum durant lequel les checks peuvent s'exécuter (  en secondes  ).

Données spécifiques pour ce check

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

Propriétés de l'hôte

Résultat

Exemple

Interprétation

Statut

Il peut prendre deux valeurs  OK / 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 :

Les vérifications spécifiques

Résultat

Renvoi au format texte : 

• Si le module fonctionne correctement
• statistique du nombre d'événements géré dans la dernière minute

Résultat Long

Le Pas de résultat long donne le détail des informations traitées par le module.

La partie Global contient : 

• Le nombre d'éléments gérés par le module event manager 
• Un résumé sur la dernière minute de l'activité du module ( voir ci-dessus : Description du résultat )

Les parties Worker contient par worker :

• Le nombre d'éléments gérés par workers
• Un résumé de l'activité sur worker
• La charge du worker : C'est à dire le temps que le worker a effectivement travaillé sur la dernière minute
  • Exemple : si sur la dernière minute le module a reçu 5000 broks et qu'il a mis 10ms par broks cela fera ( 5000 * 0.01 ) / 60 = 0.83 soit 83% de charge.

La partie Database contient : 

• Le nombre de jours durant lequel sont gardés les événements. Au-delà de cette limite, les événements sont supprimés.
• Le nombre d'événements sauvegardés et la taille de la base.
• Date du dernier événement sauvegardé.

pour ce check.

Description Description des erreurs

Le Broker est en cours d'arrêt

Lorsque le Broker est en cours d'arrêt, le check le signale, et les informations relatives au module ne sont plus disponibles

Panel
Image Removed Image Added

Métriques

Cas supplémentaire

En plus de donner les statistiques de requêtes, le check affiche le nombre de requêtes en erreur sur la dernière heure avec dans la colonne résultat long, les retours d'erreur des dernières requêtes n'ayant pas réussi à s'effectuer. 

Cela permet à l'utilisateur de voir si toutes les requêtes sont correctement effectuées et de voir quel est la nature des dernières erreurs. L'affichage des retours d'erreur est paramétrable via la donnée LIVEDATA_DISPLAYED_ERROR_LIMIT ( voir ci-dessous ).

Ci-contre, il y a une requête en erreur, car il n'y a soit aucun token donné, soit que le token donné au moment de la requête n'est pas le bon.

Le check affiche aussi les informations liées à la configuration du module et les éventuelles erreurs de configuration. Comme dans l'exemple ci-contre où le token du module n'a pas été changer lors de la configuration du module et utilise toujours celui par défaut.

Le check informe sur quel type de connexion sont les requêtes sont effectuées HTTP ou HTTPS.

Métriques

worker_[X]_load_in_last_min

Charge du worker, entre 0 et 1.

worker_[X]_event_write_in_last_min

Nombre d'événements écrits sur la dernière minute par le worker.

worker_[X]_brok_handle_in_last_min

Nombre de broks traités sur la dernière minute par le worker.

global_event_write_in_last_min

livedata_

average_

response_time

livedata_

error_

percent

livedata_nb_error_last_hour

total_element

Nombre total d'éléments gérés

Comment interpréter les données des métriques

Taille de la base

Gestion du nombre d'événement écrits et du nombre de brok gérés

Le nombre d'événements doit être sensiblement inférieur au nombre de brok gérés, c'est pourquoi il faut surveiller les métriques  global_brok_handle_in_last_min et global_event_write_in_last_min, car si ces deux métriques sont proches cela signifie qu'à chaque vérification, vos éléments changent d'état et donc que tous les éléments supervisés ont un contexte "flapping".

Gestion des workers

Ajout d'un worker 

Pour ajouter un worker, il suffit de modifier la clé broker_module_nb_workers dans /etc/shinken/modules/event_manager_writer.cfg en augmentant ou diminuant le nombre de worker utilisé. 
  Chaque worker ajouté utilisera un CPU sur le serveur où se situe le démon Broker.  Ajouter ou diminuer le nombre de worker permet de mieux répartir la charge de travailler pour les autres worker.

Gestion de la charge des workers

Si les métriques total_event_number, global_event_write_in_last_min, global_brok_handle_in_last_min et worker_[X]_load_in_last_min croissent et que le temps de traitement des broks devient élevé

Il est alors conseillé d'augmenter le nombre de worker utilisés.

Surveiller la charge des workers et ajouter un si besoin.

Si la métrique global_brok_handle_in_last_min est stable, mais que la métrique global_event_write_in_last_min monte

Surveiller la charge des workers et la taille de la base. Si le problème est temporaire, la charge du worker va retrouver un niveau stable.