Contexte
Le check Broker - $KEY$ - Module Visualisation UI - Event Manager Reader permet de superviser la lecture des données par le module Event Manager au niveau du module WebUI du démon broker
|
Paramétrage
Le check utilise la ligne de commande suivante :
$PLUGINSDIR$/check_shinken_broker_module_visualisation_ui_event_manager_reader.py -H "$HOSTADDRESS$" -p "$ARG1$" -w "$ARG2$" --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
Données spécifiques pour ce check
| Nom | Modifiable sur | Unités | Défaut | Valeur par défaut à l'installation de Shinken | Description | |
|---|---|---|---|---|---|---|
| Modèle d'hôte ( Onglet Données ) | --- | 1 | 1 | Nombre des X dernières minutes utilisées pour calculer les statistiques |
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 / 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
- CHECK_SHINKEN_TIMEOUT
Voici un tableau récapitulatif du statut attendu suivant le retour de sonde :
Les vérifications spécifiques
Situation | Statut |
|---|---|
Le module WebUI n'a pas de sous module | CRITIQUE |
Le Broker est en cours d'arrêt | ATTENTION |
Si la sonde n'a pas eu de réponse avant le temps maximum
| INCONNU |
Résultat
Le résultat du check donne le statut de l'accès aux données de l'Event manager.
Le résumé sur la dernière minute contient:
- Le nombre d'appel à la page de l’Event manager.
- Le temps de traitement par la WebUI pour répondre aux appels.
- Le temps moyen par appel.
Résultat Long
Le résultat long donne le détail des informations des appels traités par la WebUI.
La partie In the last 1 minute donne les informations suivantes :
- Le nombre d'appels traités.
- Le temps passé pour traiter ces demandes.
- Le nombre d'événements lu dans la base.
La partie Event info donne les informations suivantes :
- La date de l'événement le plus vieux en base.
- La date de l'événement le plus vieux lu sur les dernières 24h.
La partie Top requests donne la liste des 5 appels les plus longs sur les dernières 24h
La liste contient l'appel avec ces paramètres et son filtre.
- Request type :
Les types sont :- History,
- Widget,
- Report.
- Endpoint : contient les paramètres de l'appel, ce qui peut permettre de comprendre pourquoi un appel est long : Par exemple, un rapport sur une année entière et 200 éléments peut être long à générer.
- Time taken : temps par requête en millisecondes.
Les informations sur les dernières 24h ne sont pas sauvegardées par le daemon donc si il redémarre ces informations sont remises à zéro. |
|
Description des erreurs
Le module WebUI n'a pas de sous modules
|
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
Nom | Unité | Description |
|---|---|---|
event_read_in_last_min | --- | Nombre d'événements lu dans la dernière minute |
request_time_in_last_min | seconde | Temps de traitement des appels de la dernière minute |
oldest_event_read_from_now | --- | Nombre de jours entre aujourd'hui et la date de l'événement le plus vieux lu dans les dernières 24h |
request_number_in_last_min | --- | Nombre d'appels dans la dernière minute |
Comment interpréter les données des métriques
Configuration de day_keep_data
La métrique oldest_event_read_from_now permet de mesurer la pertinence de la valeur day_keep_data.
En effet si par exemple vous avez mis day_keep_data à 30 jours et que sur l'année dernière vous n'avez pas fait d'appel pour lire une donnée plus vielle que 5 jours vous pouvez réduire le nombre de jour sauvegardés et ainsi limiter la taille de la base sereinement.