| Scroll Ignore | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
|
Contexte
Le check Broker - $KEY$ - Module Visualisation UI va afficher l'état d'une WebUI ainsi que les dernières configurations qu'elle a reçuesSLA Writer permet de superviser la partie écriture du module SLA au niveau du démon Broker ( voir la page Le Broker ).
| Panel |
|---|
| Panel |
Paramétrage
Le check utilise la ligne de commande suivante :
| Code Block | ||||
|---|---|---|---|---|
| ||||
$PLUGINSDIR$/check_shinken_broker_module_visualisationsla_uiwriter.py -H "$HOSTADDRESS$" -p "$ARG1$" --shinkenversion "$SHINKENVERSION$" -m "$_HOSTMINUTES_OF_STATS$" -w "$ARG2$--workerwarning "$_HOSTWORKER_WARNING$" --workercritical "$_HOSTWORKER_CRITICAL$" --shinkenversionstoragewarning "$SHINKENVERSION$$_HOSTSTORAGE_WARNING$" --timeoutstoragecritical "$_HOSTCHECKHOSTSTORAGE_SHINKEN_TIMEOUT$CRITICAL$" -n-timeout "$_HOSTNBHOSTCHECK_LINESHINKEN_UNAVAILABILITY$TIMEOUT$" |
Données utilisées provenant du modèle
Données communes pour les checks du modèle
Nom | Modifiable sur | Défaut | Valeur par défaut à l'installation de Shinken | Description |
|---|---|---|---|---|
CHECK_SHINKEN_TIMEOUT | l'Hôte ( Onglet Données ) | 3 | 3 | Temps maximum durant lequel les checks peuvent s'exécuter ( en secondes ). |
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 ) | --- | 5 | 5 | Quantité de configurations présentent dans le résultat long |
Les données DFE ( Duplicate Foreach )
Excerpt Include Modèle shinken-broker-module-visualisation-ui Modèle shinken-broker-module-visualisation-ui nopanel true
Données utilisées provenant du check
Pas de données spécifiques pour ce check.
Paramètre du check
- Vu que le check est exécuté sur un Poller, il faut permettre à ce dernier d'accéder aux serveurs graphite en SSH .
- D’où la nécessité de paramétrer les données SSH_KEY, SSH_KEY_PASSPHRASE, SSH_PORT, SSH_USER.
- REMARQUE : il est obligatoire en l’état du check actuel que cette même clef soit autorisée sur tous les serveurs graphites surveillés.
- Si un autre check Shinken a déjà été paramétré avec une clé SSH pour accéder au serveur graphite, vous pouvez bien sûr reprendre cette même clé.
Données globales
| Excerpt Include | ||||||
|---|---|---|---|---|---|---|
|
Propriétés de l'hôte
| Excerpt Include | ||||||
|---|---|---|---|---|---|---|
|
Résultat
Exemple
| Panel |
|---|
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 Graphite backend d'un royaume utilise un port non valide | CRITIQUE |
Le Graphite backend d'un royaume utilise n'a pas d'adresse | CRITIQUE |
Un ou plusieurs royaumes n'ont pas de Graphite backend | CRITIQUE |
Le Graphite backend d'un royaume n'utilise pas un protocole valide | CRITIQUE |
Un ou plusieurs royaumes n'est pas géré par le Broker | ATTENTION |
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
Renvoi au format texte :
- Si le module fonctionne correctement
Résultat Long
Ce check va afficher l'état d'une WebUI ainsi que les dernières configurations qu'elle a reçues
Pour chaque configuration qu'elle a reçue, nous avons :
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.
| Panel | ||
|---|---|---|
| ||
Ecriture des SLA
Archivage des SLA
Migration des données
La partie SLA - Migration indique les informations sur le statut du processus de migration des données de SLA.
Pour rappel, la migration des données SLA permet de migrer toutes les données SLA d'un format de donnée vers un nouveau qui pourrait être mise en place lors d'une mise à jour de Shinken
Lorsque la migration des données est en cours le résultat du check indique :
- Si la base de donnée a été migré
- Avec le nombre de données utilisant l'ancien format de données
- Le statut de la migration
- La progression de la migration avec le pourcentage et le nombre de données migré et sur le nombre total de donnée.
Si la base de données est au bon format, le résultat du check indique la durée de la dernière migration effectuée
| Panel | ||
|---|---|---|
| ||
| Panel | ||
|---|---|---|
| ||
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 à conservé est 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é, 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 )
Lorsque la rotation est désactivée, voici les informations affichées :
- Affiche que les SLA sont conservé 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é, mais toujours stocké
| Panel | ||
|---|---|---|
| ||
| Panel | ||
|---|---|---|
| ||
Description des erreurs
Le Graphite backend d'un royaume utilise un port non valide
Si dans le graphite_backends d'une WebUI, une adresse utilise un port HTTP non valide, alors une erreur est remontée dans le check.
Par exemple, le graphite_backends suivant va remonter une erreur :
graphite_backends *:127.0.0.1:80, Italie:192.168.1.26:80, Japon:127.0.0.1:invalid_port
Les métriques ne seront alors pas disponibles pour ce royaume.
| Panel |
|---|
Le Graphite backend d'un royaume utilise n'a pas d'adresse
Si dans la définition d'un Graphite backend d'un royaume, l'adresse ( ou l'IP ) est manquante, alors une erreur est remontée.
Par exemple, le graphite_backends suivant va remonter une erreur :
graphite_backends *:127.0.0.1:80, Italie::80, Japon:127.0.0.1:80
Les métriques ne seront alors pas disponibles pour ce royaume.
| Panel |
|---|
Un ou plusieurs royaumes n'ont pas de Graphite backend
Si dans la définition d'un graphite_backends, un ou plusieurs royaumes n'ont pas d'adresse définie, mais qu'il sont quand même gérés par le Broker, alors une erreur sera remontée dans le check.
Par exemple, un Broker gère les royaumes suivants : All, France, Italie, Japon
Maintenant, une des WebUI du Broker a le graphite_backends suivant :
graphite_backends France:192.168.1.23:80
Alors, les royaumes "All, Italie et Japon" n'ont pas de Graphite backend défini par la WebUI, ce qui aura pour conséquence que les éléments de ces royaumes n'auront pas accès à leurs métriques.
| Panel |
|---|
Le Graphite backend d'un royaume n'utilise pas un protocole valide
Si la définition d'un Graphite backend utilise un protocole qui n'est pas valide, le check remonte une erreur pour le backend concerné.
Par exemple, le graphite_backends suivant va remonter une erreur :
graphite_backends *:192.168.1.23:80, France:htt://192.168.1.23:80
Les métriques ne seront alors pas disponibles pour ce royaume.
| Panel |
|---|
Un ou plusieurs royaumes n'est pas géré par le Broker
Le check nous averti lorsqu'un royaume est présent dans la définition des graphite_backends de la WebUI et que celui-ci n'est pas géré par le Broker.
Par exemple, un Broker gère les royaumes : All, France, Italie, Japon
Mais la définition d'une de ses WebUI est la suivante :
graphite_backends *:127.0.0.1:80, Canada:192.168.1.44
Dans ce cas, le royaume Canada n'est pas géré par le Broker et sera donc ignoré.
Ce problème ne bloque pas le fonctionnement du module, il suffit juste d'enlever ou de corriger l'adresse de ce royaume dans la configuration de la WebUI pour enlever cet avertissement.
| Panel |
|---|
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 |
|---|
Métriques
| Nom | Unité | Description | |||||||
|---|---|---|---|---|---|---|---|---|---|
| --- | Nombre de checks géré par la WebUI | |||||||
| --- | Nombre de clusters géré par la WebUI | |||||||
| --- | Nombre de contacts géré par la WebUI | |||||||
| --- | Nombre d'hôtes géré par la WebUI | |||||||
| minute | Le temps d'indisponibilités de la WebUI par minutes |













