| Scroll Ignore | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
|
Contexte
Le modèle shinken-scheduler vous permet de superviser un hôte hébergeant le démon Schedulerdémon Scheduler ( voir la page Le Scheduler ).
Description du modèle
Le modèle shinken-scheduler hérite des modèles suivants :
- Modèle shinken qui fournira des données globales de fonctionnement des checks de shinken ( voir la page Modèle shinken )
- Modèle shinken-daemon qui fournira des données globales de fonctionnement des checks de démon de shinken ( voir la page Modèle shinken-daemon
- )
Afin de superviser le démon Scheduler, le modèle shinken-scheduler appliqué à votre l'hôte , attachera plusieurs deux checks qui vérifieront la santé et la performance de ce démon.
Sommaire des checks
Nom | Description |
|---|
Vérifie que le démon Scheduler peut être correctement contacté sur le réseau et |
Affiche également le nombre d'éléments qu'il gère dans un tableau, en distinguant les hôtes, les Clusters et les Checks et le Total des éléments. ( Résultat court )
Présente la liste les démons auxquels le Scheduler doit se connecter, et l'état des connexions ( Résultat long ).
Donne un état des modules chargés ( Résultat long ).
| Panel |
|---|
|
| Panel |
|---|
|
Affiche l'utilisation CPU ainsi que les statistiques des Pollers et des Reactionners qu'il gère. Si des limites de CPU ou de RAM sont atteintes sur vos Pollers, alors ces limites seront affichées.
Si certains de vos Pollers sont en spare, ils seront également affichés, avec le texte ( SPARE ) après leurs noms.
Le retour du check Scheduler - Performance contient également un tableau de classification des checks ordonnancés par le Scheduler.
Si jamais le démon Arbiter est en exécution sur une machine virtuelle supervisée par VMware, alors le pourcentage de temps de vol de CPU ( CPU Ready ) sera affiché.
| Panel |
|---|
|
| Panel |
|---|
|
Données du modèle ( paramétrage des checks )
Les checks du Scheduler peuvent être configurés via des données fournies par le modèle. Les paramètres SSH sont décrits sur la page Rétention Mongodb
Les données suivantes sont disponibles pour le Scheduler :
Protocole utilisé pour établir la connexion avec le Scheduler
Port utilisé pour établir la connexion avec le scheduler
Liste de Scheduler (Multi-démon)
Latence de connexion (en secondes) au-delà de laquelle le check sort en erreur
Métriques enregistrées
Les checks du modèle shinken-scheduler enregistrent des données de performance, qui peuvent ensuite être affichées dans l'interface de Visualisation sur l'Onglet Graphes ou bien le Widget Graphique.
Scheduler - $KEY$ - Running Well
Scheduler - $KEY$ - Running Well
Scheduler - $KEY$ - Running Well
Scheduler - $KEY$ - Running Well
Scheduler - $KEY$ - Running Well
nb_late_checks
Scheduler - $KEY$ - Running Well
nb_late_notifications
Scheduler - $KEY$ - Running Well
nb_late_event_handlers
Scheduler - $KEY$ - Performance
Estimation de la surcharge du Scheduler.
- Si cette métrique est à zéro alors le Scheduler n'est pas en surcharge.
- Si cette métrique est trop souvent supérieure à 0, c'est l'indication qu'il y a besoin d'un Scheduler supplémentaire.
Scheduler - $KEY$ - Performance
Durée d'un cycle de traitement du Scheduler.
- Le maximum est à 100.
- Plus cette valeur est haute plus cela indique une charge sur le Scheduler.
Scheduler - $KEY$ - Performance
Scheduler - $KEY$ - Performance
Scheduler - $KEY$ - Performance
Scheduler - $KEY$ - Performance
event_handlers_todo_by_sec
Scheduler - $KEY$ - Performance
notifications_and_event_handlers_done_by_sec
Scheduler - $KEY$ - Performance
Scheduler - $KEY$ - Performance
Scheduler - $KEY$ - Performance
Scheduler - $KEY$ - Performance
Commandes
Nom du check
Commande du check
Ligne de commande
Les modes dépréciés ("-m") :
Interprétation du check Scheduler - $KEY$ - Running Well
Statistiques de l'état de santé du Scheduler
Si votre Scheduler est en bon état de fonctionnement, c'est-à-dire qu'il permet d'ordonnancer correctement tous les checks et de recevoir les résultats de ces checks en temps et en heure, alors le statut du retour du check "Scheduler - Running Well" est OK.
Résultat court :
Suite à ce retour, les informations suivantes sont disponibles dans le résultat court :
- Si le Scheduler est connecté à des Pollers passifs, la latence de la connexion vers chacun d'eux est affichée.
- Un tableau contenant le nombre d'éléments que gère le Scheduler.
- Le royaume géré par le Scheduler.
- Le numéro de version du logiciel.
- Le temps consommé pour récupérer les informations générales
- Le temps utilisé pour récupérer l'état des connexions vers les Schedulers, les Pollers passifs et les Reactionners passifs
| Panel |
|---|
|
Résultat long :
Les informations suivantes sont également disponibles dans le résultat long :
- Une liste des démons ( Schedulers, Pollers passifs, Reactionners passifs ) auxquels le Schedulers doit se connecter, avec pour chacun des démons :
- Son nom ( suivi des tags gérés pour les Pollers passifs ou pour les Reactionners passifs )
- Son type
- La valeur du paramètre timeout renseigné dans le fichier de configuration de ce démon ( qui correspond au délai potentiel maximal requis pour le contacter )
- L'état de la connexion
- La liste des modules chargés ainsi que leur état
| Panel |
|---|
|
Description des erreurs de Scheduler - $KEY$ - Running Well
En attente de la configuration
| Panel |
|---|
|
Le Scheduler contacté est d'une version incompatible
Lorsque le Scheduler supervisé n'est pas de la même version, le check renvoie une information le signalant, et toute autre information n'est pas disponible dans le résultat court ou dans le résultat long .
| Panel |
|---|
|
Problème de surcharge des disques de logs
En cas de disques trop lent sur le volume des logs, le check sera mis en WARNING avec l'erreur suivante.
| Panel |
|---|
|
Problèmes réseau
Latence réseau importante vers des Pollers passif
Quand la connexion vers un ou plusieurs Pollers passifs souffre d'une latence réseau trop importante, cette information est remontée dans le résultat court
| Panel |
|---|
|
La récupération des données de connectivité prend trop de temps
| Panel |
|---|
|
Le timeout du check est trop court
Quand le timeout associé à ce check est inférieur au paramètre timeout renseigné dans la configuration d'un des démons que doit contacter le Scheduler, il se peut que la connexion vers ce démon échoue lors du test de connectivité.
Résultat court :
Un message d'avertissement signale que certains démons nécessitent un timeout plus élevé pour être contacté, et une valeur conseillée est affichée.
| Panel |
|---|
|
Résultat long :
Dans ce cas, le Status dans le résultat long précise que l'erreur peut être liée au délai trop court accordé pour tester la connexion. Il est alors conseillé d'augmenter le timeout du check pour que le test soit pertinent.
| Panel |
|---|
|
Démons passifs injoignables
Résultat court :
Quand la connexion vers certains Pollers passifs ou certains Reactionners passifs est impossible, le résultat court du check liste les démons injoignables, en précisant pour chacun :- Le nom
- L'adresse et le port de connexion
- Les tags gérés
Ceux-ci sont regroupés par type ( Poller ou Reactionner ), un compteur indique le nombre de passifs injoignables et le nombre total de démons du même type disponible ( passifs et actifs )
| Panel |
|---|
|
Résultat long :
Le tableau du résultat long , indique les problèmes de connectivité dans la colonne Status, avec un message précisant leur nature.
| Panel |
|---|
|
Schedulers injoignables
Résultat court :
Quand le Scheduler ne parvient pas à communiquer avec un ou plusieurs Schedulers du royaume, ceux-ci sont listés avec :
- Leur nom
- Leur adresse
- Leur port de connexion
Un compteur indiquant le nombre de Schedulers injoignables et le nombre total de Schedulers disponibles est également affiché.
L'indisponibilité d'un ou plusieurs Scheduler pouvant perturber le calcul des états de clusters, un message d'avertissement le précisant est également ajouté.
| Panel |
|---|
|
Résultat long :
Le tableau listant les connexions du Scheduler, indique les problèmes de connectivité vers les autres Schedulers dans la colonne Status, avec un message précisant la nature du problème.
| Panel |
|---|
|
Etat de santé dégradé du Scheduler
Il peut arriver que vos Pollers ne permettent pas d'absorber tous les checks ordonnancés par le Scheduler, et dans ce cas, certains seront en retard ! Les checks sont considérés en retard s'ils dépassent 10 secondes à partir du moment où ils sont mis à disposition des Pollers par les Schedulers.
L'état de retour du check "Scheduler - $KEY$ - Running Well" est alors WARNING . Le nombre de checks en retard et le pourcentage des checks en retard par rapport au volume géré par le Scheduler sont affichés.
Le volume géré par le Scheduler est calculé à partir de ces données :
- Le nombre de checks
- Le nombre d'hôtes ( un check est fait pour chaque commande de vérification )
- Le nombre de clusters ( un check est fait pour chaque définition du cluster )
Le nombre de checks en retard est ensuite affiché par Poller Tag.
Pour les checks qui ont été exécutés durant les cinq dernières minutes, le temps d'attente moyen sur le Scheduler et sur le Poller est également affiché. Si ce chiffre s'approche des 10 secondes :
- Vos Pollers n'arrivent pas à absorber toute la charge : il peut être nécessaire d'ajouter un nouveau Poller.
- Il peut également s'agir d'un problème de latence réseau ou que l'un des Pollers ne soit plus disponible.
Ces informations sont également disponibles pour les notifications et les événements. Dans ce cas, le démon concerné est le Reactionner
Enfin, le check rappelle à quel royaume appartient le Scheduler.
| Panel |
|---|
|
Problème de conflits d'Arbiters
Si le démon est contacté par des Arbiters qui ne sont pas sur la même architecture ( par exemple un Arbiter de Production et un autre de l'environnement de Testing ), le check sera mis en CRITICAL .
| Panel |
|---|
|
Comme dans le cas précédent, le démon est contacté par des Arbiters d'architectures différentes, mais qui ont le même nom. Le check passe aussi en CRITICAL mais en avertissant que les noms sont identiques, et en indiquant l'uuid des serveurs concernés. Cet uuid est situé dans le fichier /var/lib/shinken/server.uuid.
| Panel |
|---|
|
Les serveurs ne sont pas à la même heure
- Si le serveur n'est pas à la même heure que le serveur Arbiter ( qui fait office de référence ), une erreur CRITICAL sera levée, car des temps différents sur des serveurs distincts va avoir des effets désastreux sur la cohérence des données de supervision.
| Panel |
|---|
|
La dernière connexion de l'Arbiter remonte à trop longtemps
- Si la dernière connexion de l'Arbiter remonte à trop de temps, le démon va lever un WARNING . Ceci peut être dû à :
- Les Arbiters MASTER et SPARE sont réellement éteints.
- Les Arbiter MASTER et SPARE sont en train d'envoyer des configurations à d'autres démons, et ne peuvent donc pas contacter ce démon pour l'instant.
| Panel |
|---|
|
| Info |
|---|
Le temps pris en compte comme limite de dernière connexion est de check_interval * max_check_attempts du démon ( définis dans sa configuration ). Les valeurs par défauts sont de 60s * 3 ( soit 3 minutes ) |
Exemple d'un état de santé dégradé du Scheduler
Il peut arriver que vos Pollers ne permettent pas d'absorber tous les checks ordonnancés par le Scheduler, et dans ce cas, certains seront en retard ! Les checks sont considérés en retard s'ils dépassent 10 secondes à partir du moment ou le Scheduler les a mis à disposition des Pollers.
L'état de retour du check "Scheduler - $KEY$ - Running Well" est alors WARNING et le nombre de checks en retard avec le pourcentage des checks en retard par rapport au volume géré par le Scheduler sont affichés.
Le volume géré par le Scheduler est calculé à partir :
- Du nombre de checks
- Du nombre d'hôtes ( un check est fait pour chaque commande de vérification )
- Du nombre de clusters ( un check est fait pour chaque définition du cluster )
Le nombre de checks en retard est ensuite affiché, groupé par Poller Tag.
Pour les checks qui ont été exécutés durant les cinq dernières minutes, le temps d'attente moyen sur le Scheduler et sur le Poller avant d'être traité est également affiché. Si ce chiffre s'approche des 10 secondes :
- Vos Pollers n'arrivent pas à absorber toute la charge : il peut être nécessaire d'ajouter un nouveau Poller.
- Il peut également s'agir d'un problème de latence réseau ou que l'un des Pollers ne soit plus disponible.
Ces informations sont également disponibles pour les notifications et les événements. Dans ce cas, le démon concerné est le Reactionner.
Enfin, le check en WARNING rappelle à quel royaume appartient le Scheduler.
| Panel |
|---|
|
Interprétation du check Scheduler - $KEY$ - Performance
La supervision d'un démon Scheduler présente un grand nombre de statistiques de performances qui permettent de visualiser le travail d'ordonnancement effectué par le Scheduler, ainsi que les statistiques des Poller qui viennent se connecter à celui-ci.
Le démon Scheduler va effectuer tout le travail d'ordonnancement, et c'est à lui que vont s'adresser ( en autres ) les démons Poller et Reactionner pour récupérer les checks et les notifications à effectuer. Son bon fonctionnement est donc vital au bon fonctionnement de votre architecture Shinken. Aussi, pour dimensionner correctement une installation Shinken Entreprise, il est important de pouvoir visualiser combien de checks ses Poller satellites peuvent traiter, ainsi que leurs utilisations CPU et RAM.
Les checks du Scheduler fournis dans le pack Shinken proposent donc un grand nombre de données sur les performances du Scheduler et de ses Pollers.
L'ensemble des informations se retrouve dans le résultat court du check.
Statistiques générales
- La première statistique remontée par le check est le pourcentage CPU moyen utilisé par le démon Scheduler sur le serveur supervisé.
- La deuxième statistique remontée est le temps d'attente moyen d'un check sur le Scheduler avant d'être récupéré par un Poller pour traitement.
- La date et la durée de la dernière sauvegarde réussie de rétention
- La date et la durée du dernier chargement de rétention
- Si votre machine virtuelle est hébergée sur un système VWMare, alors une dernière statistique sera remontée.
- Elle affiche le taux de CPU %ready ( vol de temps de calcul du CPU votre machine par les autres machines virtuelles de l'hyperviseur ).
| Panel |
|---|
|
Vol de CPU
Seulement si votre machine virtuelle est hébergé sur un hyperviseur VMWare
- Votre machine à du vol de CPU :
- Si la VM se fait voler trop de temps de calcul (CPU Stolen), le check sera mis en WARNING ou en CRITIQUE ( en fonction du taux de vol fixé par défaut ou indiqué par l'utilisateur ).
- Vous pouvez avoir plus d'information sur cet indicateur et comment réduire la parte de temps de la VM sur la page Machine VMWare avec un fort taux de CPU Stolen (%ready + %costop)
| Panel |
|---|
|
| Panel |
|---|
|
Suivi des chargements/sauvegardes des données de rétention
Les données de rétention sont chargées/sauvegardées par les démons Schedulers. Un affichage permet de voir :
- La date et la durée du dernier chargement de rétention ( lors d'une nouvelle configuration )
- La date et la durée de la dernière sauvegarde de rétention ( lors d'une nouvelle configuration, ou alors toutes les retention_interval disponibles dans le fichier shinken.cfg )
| Panel |
|---|
|
| Panel |
|---|
|
Si la dernière sauvegarde de rétention est trop vieille, c’est-à-dire plus que retention_interval + SCHEDULER__RETENTION__RENTENTION-IS-TOO-OLD-AFTER_X_MINUTES, alors un WARNING sera remonté.
| Panel |
|---|
Si le dernier essai en date de sauvegarde de rétention est en ERROR , alors un message sera disponible avec le dernier message du module en question.
| Panel |
|---|
|
Suivie des Pollers Satellites
Informations générales
Suite aux statistiques générales, un premier tableau rassemble les données de performance des satellites du Scheduler de type Poller.
La première partie du tableau ( les trois premières colonnes ) permet d'identifier les Pollers en affichant leurs noms, leurs appartenances à un Royaume, et enfin leurs tags ( None si aucun tag n'est associé au Poller ).
| Panel |
|---|
|
Statistiques des checks
Les deux colonnes suivantes affichent les performances de traitement des checks des Pollers :
- checks todo : Moyenne du nombre de checks à traiter par le Poller (en checks par seconde)
- checks done : Moyenne du nombre de checks traités par le Poller (en checks par seconde)
Vous pourrez donc avoir l'information du nombre de checks récupérés et traités par vos différents Pollers rattachés à ce Scheduler et ainsi pouvoir comparer les performances de vos Pollers suivant leur positionnement dans votre architecture réseau, ou suivant leur puissance matérielle.
que les modules sont opérationnels ( Résultat long ). La version du démon est également affichée ( Résultat court ) . | |
| Vérifie un grand nombre de données sur les performances du Scheduler et de ses Pollers. |
Les données
Les données communes pour tous les checks
Provenant du modèle shinken
| Excerpt Include | ||||||
|---|---|---|---|---|---|---|
|
Provenant du modèle shinken-daemon
| Excerpt Include | ||||||
|---|---|---|---|---|---|---|
|
Provenant du modèle shinken-scheduler
| Excerpt Include | ||||||
|---|---|---|---|---|---|---|
|
Les données spécifiques
Pas de données spécifiques.
Les données DFE ( Duplicate Foreach )
| Excerpt | |||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Comment appliquer un modèle d'hôte à un hôte
| Excerpt Include | ||||||
|---|---|---|---|---|---|---|
|
| Panel |
|---|
|
Utilisation du CPU
CPU Available
La colonne "CPU available" concerne les performances CPU des Pollers.
Cette information représente la charge du Poller. Il s'agit d'un indicateur général indiquant si le Poller peut encore supporter des checks supplémentaires, ou s’il est chargé au maximum. Cet indicateur n'est pas lié aux autres indicateurs de performances de la machine ( File d'attente CPU, mémoire )
Une pastille orange précédant la mention "Poller load" signifie que le Poller ne peut plus prendre de checks supplémentaires.
C'est donc un signe indiquant qu'il faudrait ajouter un Poller supplémentaire dans l'architecture Shinken.
Si tous vos Pollers sont en surcharge, alors les checks ne pourront plus être récupérés, et vous aurez des retards visibles dans le retour de votre check "Scheduler - Running Well".
Il vous faudra de toute urgence rajouter des Pollers dans votre royaume.
| Panel |
|---|
|
Voici par exemple une surcharge d'un Poller.
| Panel |
|---|
|
CPU used by the poller
La colonne "CPU used by the poller" permet d'afficher la consommation CPU utilisée par le Poller. Comme son nom l'indique, un graphique est associé à ce check et permet d'afficher cette métrique.
Lorsque le Poller utilise le maximum de CPU possible sur le serveur, une information apparaît.
Cette valeur de CPU utilisée par le Poller ne sera jamais à 100%, car le système Linux hébergeant le démon utilise une partie du CPU, comme les applications additionnelles que ce serveur peut utiliser.
Plus il y a d'application sur votre serveur Poller consommant du CPU, moins votre démon pourra utiliser de CPU à ses fins et atteindra rapidement sa charge maximale utilisable ( bien en deçà de 100% ).
| Panel |
|---|
|
Lorsque la limite est atteinte, voici l'affichage dans le tableau.
| Panel |
|---|
|
Utilisation de la RAM
% used RAM on the server
La dernière colonne du tableau représente le pourcentage de RAM utilisé sur le serveur.
Si la valeur détectée est inférieure à la limite définie, alors la consommation est considérée comme normale et la pastille "normal" est affichée.
La limite paramétrée dans le Poller est affichée entre parenthèses.
| Panel |
|---|
|
Si l'utilisation de la mémoire (RAM) sur le serveur dépasse le seuil défini dans la configuration de ce Poller, une pastille rouge de dépassement est affichée, indiquant l'utilisation excessive de la mémoire. Lorsque cet avertissement est affiché, le Poller n'exécute plus de checks supplémentaires tant que l'utilisation de la mémoire est supérieure au seuil défini.
| Panel |
|---|
|
Load
Si par exemple le CPU n'est pas utilisé au maximum de ses performances, mais que sa "running queue" ( file d'attente ) est importante, la limitation de CPU ne peut prévenir ce cas.
Pour s'assurer que le Poller ne tente d'exécuter des checks sur une machine surchargée le Poller se limitera en fonction de l'état de la file d'attente processeur ( représentant la valeur source du load average ).
Dans ce cas, le Poller n'exécutera plus de checks supplémentaires tant que le nombre de processus dans la file d'attente du processeur sera supérieur au seuil choisi. La limite paramétrée dans le Poller est affichée entre parenthèses.
| Panel |
|---|
|
Lorsque la limite est atteinte pour ce Poller, alors le check "Scheduler - Performance" ajoute une pastille rouge vous informant du dépassement de la limite.
| Panel |
|---|
|
Suivie des Reactionners Satellites
Suite aux statistiques des Satellites de type "Poller", un deuxième tableau rassemble les données de performance des satellites du Scheduler de type Reactionner.
Les trois premières colonnes représentent, comme pour le tableau précédent, les données d'identification des Reactionners venant récupérer les notifications auprès du Scheduler.
Les deux colonnes suivantes permettent d'obtenir les statistiques des notifications à traiter par les Reactionner ainsi que les notifications déjà réalisées ( en nombre de notifications par seconde ).Enfin les deux dernières colonnes affichent les informations CPU des Reactionners, de la même manière que pour les Pollers.
| Panel |
|---|
|
Type de checks fait par seconde
Le Scheduler est un ordonnanceur de checks.
Cet ordonnancement peut être fait pour différentes raisons qui sont énumérées dans la colonne "Causes" de ce tableau ci-contre :
- Dependency : Les checks qui sont demandés, car liés à une dépendance ( checks liés à son hôte ou hôte fils lié à son hôte parent )
- Retry : Les checks qui sont revérifiés pour la confirmation des états, via la propriété "Intervalle de nouvelles tentatives de confirmations d'état" des checks et des hôtes
- Force : Les checks qui sont demandés par les utilisateurs depuis l'interface de visualisation ( bouton "Forcer la vérification" )
- Schedule : Les checks qui sont ordonnancés de manière régulière via la propriété "intervalle entre les vérifications" des checks et des hôtes ( normalement le plus actif des 4 raisons )
Pour chaque raison, le nombre de checks par seconde est affiché dans la deuxième colonne.
| Panel |
|---|
|
Consommation de temps CPU des checks
Le check "Scheduler - Performance" peut également détecter si la commande d'un check prend trop de temps CPU lors de son exécution.
Si le seuil est atteint ( et dans ce cas seulement ), le check passe en état WARNING et le tableau ci-contre apparaît dans le résultat du check.
Ce tableau contient le nom des commandes, leurs temps CPU consommés, le seuil fixé pour cette commande et la date de l'exécution.
| Panel |
|---|
|
Par défaut, le seuil est fixé à 5 secondes. Cette propriété nommée "Seuil d'alerte de l'utilisation CPU (sec)" est modifiable via l'UI de configuration dans les onglets "Supervision" des objets "hôte" et "check" et dans l'onglet "Général" des commandes. La clé d'import est warning_threshold_cpu_usage.
Ce paramètre est aussi modifiable globalement dans le fichier /etc/shinken/shinken.cfg.
| Code Block |
|---|
# How many seconds a command check (for hosts, clusters and checks) is allowed to consume cpu
# before raising a warning in check scheduler performance
# by default: 5
#warning_threshold_cpu_usage=5 |
Après modification, un redémarrage de l'Arbiter sera ici requis.
Cas Particuliers d'erreur
Si un Poller est détecté comme injoignable ( par exemple s'il y a un problème réseau avec ce démon ou alors qu'il vient juste d'être désactivé depuis l'Arbiter ) alors un message est affiché.
