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 :
|
Données utilisées provenant du modèle
Données communes pour les checks du modèle
Provenant du modèle shinken
Provenant du modèle shinken-broker-module-visualisation-ui-event-manager-reader
|
Données spécifiques pour ce check
Pas de données spécifiques.
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
|
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.
Si day_keep_data est configuré sur 30 jours et que l'année dernière personne n'a fait d'appel pour lire une donnée plus vieille que cinq jours, envisagez de réduire le nombre de jours sauvegardés et ainsi limiter la taille de la base.