Page History

Contexte

Le check Broker - $KEY$ - Module Event Manager Writer permet de superviser la partie écriture du module SLA Event Manager ( voir la page Module event-manager-writer ) au niveau du démon  démon Broker (  voir la page   Le Broker  ).

Paramétrage

Le check utilise la ligne de commande suivante :

$PLUGINSDIR$/check_shinken_module_

event_manager_writer.py -H "$HOSTADDRESS$" -p "$ARG1$" --shinkenversion "$SHINKENVERSION$" 

-m "$_HOSTMINUTES_OF_STATS$

" --

timeout "$_HOSTCHECK_SHINKEN_TIMEOUT$"

Données utilisées provenant du modèle

Données communes pour les checks du modèle

Provenant du modèle shinken

Nom

Modifiable sur

Défaut

Valeur par défaut à l'installation de Shinken

Description

CHECK_SHINKEN_TIMEOUT

Provenant du modèle shinken-broker-module-event-manager-writer

Données spécifiques pour ce check

WORKER_WARNING

Modèle d'hôte

( Onglet Données )

Seuil d’avertissement pour la charge d’un Worker

WORKER_CRITICAL

Modèle d'hôte

( Onglet Données )

Seuil de critique pour la charge d’un Worker

STORAGE_WARNING

Modèle d'hôte

( Onglet Données )

Seuil d’avertissement pour la taille de stockage

STORAGE_CRITICAL

Modèle d'hôte

( Onglet Données )

Seuil de critique pour la taille de stockage

Les données DFE ( Duplicate Foreach )

Données utilisées provenant du check

Pas de données spécifiques provenant du check 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 :
  • WORKER_CRITICAL
  WORKER_WARNING
  • STORAGE_CRITICAL
  • STORAGE_WARNING
  • 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 résultat du check de supervision de l'écriture du module SLA se compose en 5 catégories d'informations :

• SLA - Writer  :  Ecriture des SLA,
• SLA - Archive: Archivage des SLA,
• SLA - Migration  : Migration des données SLA,
• SLA - Database cleanup  : Suppression des anciennes données SLA,
• Les métriques du check: Affiche les informations sur les métriques du check.

Écriture des SLA

Cette partie SLA - Writer du résultat du check indique dans la première puce le nombre d'éléments total dans le module.

Puis les autres puces indique pour chaque worker :

• Le nombre géré d'éléments dans le worker
• Les statistiques sur x minutes
  
  • Le temps d'écriture
  • Le nombre d’éléments écrit 
  • La charge sur la dernière minute

Archivage des SLA

La partie SLA - Archive indique les informations sur l'archivage des SLA.

La première puce présente les informations sur la dernière archive avec :

• La date de début de l'archive
• Le temps d’exécution de l'archive
• Le nombre de SLA archivés

Dans la deuxième puce indique la date de la plus ancienne archive de stocker. Cette date est la limite à partir de laquelle on ne peut pas générer un rapport SLA ou visualiser un SLA dans l'onglet Historique/SLA du volet détail de l'interface de visualisation plus ancienne que cette date. 

Migration des données

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

Rotation des données

La partie SLA - Database cleanup indique les informations sur la rotation des données.

Pour rappel, la rotation des données est un système de suppression des données afin d'éviter que la base de données ne grossisse trop. Cette rotation supprime les données à partir d'un certain nombre de jours. Exemple ci-contre seul les 300 derniers jours de SLA sont conservés.

Le nombre de jours a conservé et paramétrable dans le fichier de configuration du Module SLA sur le paramètre nb_stored_days. Si souhaiter ne pas mettre de jours maximaux de conservation, il faut mettre la valeur -1 au paramètre 

Lorsque la rotation est en cours, le résultat du check indique :

• La date limite de conservation des SLA
  • Avec le nombre de SLA à supprimer
• La progression de la rotation
  • Avec le pourcentage d'avancement
• La taille totale de la base de données SLA
  • Avec le nombre d'éléments supervisé qui correspond au total d'élément affiché dans la partie "écriture"

  • Le nombre d'éléments qui ne sont plus supervisés, mais toujours stocké ( calculé grâce au nombre total d'éléments dans la base archive par le module SLA que l'on peut suivre via le chapitre [ UNIQUE ELEMENTS IN ARCHIVE ] des logs du broker :   Broker - Les logs du module SLA 

    Panel
    title Rotation en cours
    Image Removed

Lorsque la rotation est désactivée, voici les informations affichées  :

• Affiche que les SLA sont conservés pour toujours
• La taille totale de la base de données SLA

  • Avec le nombre d'éléments supervisé qui correspond au total d'élément affiché dans la partie "écriture"

  • Le nombre d'éléments qui ne sont plus supervisés, mais toujours stocké

    Panel
    title Rotation désactivé
    Image Removed

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

Métriques

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

Taille de la base

Durant les 30 premiers jours d'activité du module, il est grandement recommandé de surveiller la taille de la base ( avec la métrique : total_base_size ), car la taille de la base ne fera que monter durant cette période. 
Si la taille de la base se rapproche trop vite de la limite du disque, il est recommandé de réduire le nombre de jours sauvegardés à l'aide de la clé : day_keep_data situé dans le fichier /etc/shinken/modules/ event_manager_writer.cfg ou augmenter la capacité du disque.

Passé cette période, Shinken ne gardera que le x dernier jour défini par la clé day_keep_data afin de limiter la 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, les é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