Qu'est ce que la corrélation?
L'objectif de la corrélation est de proposer des aides à l'utilisateur afin qu'il arrive facilement à faire la distinction entre:
- les problèmes sources, qui sont des éléments qui sont en erreur, de leur propre fait, par exemple
- une application qui est tombée
- un serveur qui est arrêté
- les impacts: ce sont des éléments qui sont en erreurs mais du fait d'un ou plusieurs problèmes sources, par exemple:
- une application sur un serveur qui s'est arrêté
- un serveur démarré mais derrière des switchs réseaux qui sont tombés
Le principe est que pour revenir à une situation saine, il faut régler les problèmes sources, car redémarrer les impacts n'aura aucun effet tant que l'on n'aura pas réglé son/ses problème(s) sources.
Application dans le domaine des notifications
Les notifications appliquent ce principe, et n'envoient une notification que dans le cas d'un problème source: si par exemple un service web n'est plus disponible, car son serveur ne réponds plus, car ce dernier était sur un switch qui est tombé, alors seule la notification du switch sera générée, ni celle de l'hôte, ni celle du service http.
Changement préventif de l'état des checks quand son hôte est certifié être tombé
Principe et affichage
Les vérifications des checks et des hôtes n'étant pas fait en même temps afin de ne pas surcharger l'hôte, on peux avoir le cas où
- un check (par exemple CPU) retourne un OK
- la vérification de l'hôte arrive en CRITICAL, et l'hôte est certifié tombé (on a atteint son nombre maximum de retry)
- on a donc sur l'interface:
- un hôte en CRITICAL
- un check qui est OK
- ceci est très incohérent visuellement
Pour corriger cette incohérence qui va durer jusqu'à la prochaine vérification du check, le démon Scheduler est capable de changer temporairement l'état des checks de l'hôte:
- il les mets en UNKNOWN, car vu ce qu'il a détecté sur l'hôte, il y a un doute raisonnable concernant les états des checks
- mets un texte explicatif au début du résultat du check concernant cette modification
Visuellement, le check apparaitra de la manière suivante, indiquant que son état a été modifié par Shinken:
| Panel |
|---|
|
Dès la prochaine vérification du check, ce dernier prendra son état et résultat définitif (qui peux être en erreur ou pas)
Il est important de savoir que cette approche ne remet pas en cause la logique de gestion HARD/SOFT : il n'est pas pris en compte dans la gestion des tentatives de checks . Par contre dans un souci de cohérence, cette état/résultat sera également disponible dans les autres modules, genre SLA ou les events.
Comment activer/désactiver ce mécanisme
Par défaut ce mécanisme est activé. On peux le désactiver dans le fichier /etc/shinken-user/configuration/daemons/arbiters/arbiter_cfg_overload.cfg (qui surcharge le fichier /etc/shinken.shinken.cfg) en mettant le paramètre:
| Code Block |
|---|
enable_problem_impacts_states_change=0 |
Tous les parents d'un hôte sont tombés
Dans le cas où on a des dépendances réseaux (entres les hôtes donc), la règle d'assignation des problèmes sources/impacts est la suivante:
- si un hôte a au moins un parent, et que tous ses parents sont en erreur, alors il sera affiché comme UNKNOWN
- car en fait il n'y a aucun chemin réseau pour le contacter, donc on ne sait pas dans quel état il est réellement
- s'il n'a pas de parents, ou qu'au moins un de ses parent est disponible, alors il sera affiché comme CRITIQUE
- car il y a bien un chemin réseaux pour lui parler, et donc s'il ne réponds pas c'est que c'est bien sa faute
Dans le premier cas, on aura l'affichage suivant dans la liste complète, l'hôte myself ayant pour parents papa1 et papa2:
| Panel |
|---|
|
Si on passe par la liste qui préfiltre les problèmes sources, on aura alors que les deux hôtes qui sont les problèmes sources:
| Panel |
|---|
|
Cette vue peux donc être très pratique quand les relations de dépendances sont configurées.
Priorité dynamique
L'un des bons côtés de ne pas identifier le niveau de priorité d'un parent, c'est que le problème va automatiquement hériter du niveau maximum de priorité de l'enfant qui est tombé.
Prenons un exemple: vous avez un switch avec différents enfants, l'un est un environnement de développement avec une faible priorité (0 ou 1) et un de production avec une priorité élevée (4 or 5). L'administrateur d'astreinte a paramétré un SMS de nuit mais seulement pour les priorités de niveau très élevé (Niveau 4 minimum dans la définition du contact par exemple).
Il est important de préciser que le switch en lui-même n'a pas son propre niveau de priorité défini ! Le switch est juste lié aux serveurs d'applications, la seule priorité qu'il récupère est celle des hôtes et checks qui lui sont connectés.
Il y a 2 scenario pour 2 nuits différentes :
- la première, le switch a un problème mais seul l'environnement de développement est impacté. Le switch va hériter de la valeur d'impact la plus élevée entre sa propre valeur et celle héritée (par défaut, sa propre valeur est à 2). Ici, l'impact sur le développement est à 0, le switch par défaut est à 2, donc l'impact reste à 2 (sous le seuil déclenchant une alerte) : l'administrateur peut dormir
- la deuxième nuit, le switch a un problème, mais cette fois l'impact est sur l'environnement de production! Cette fois l'impact calculé est à 5, au dessus de la valeur par défaut donc une notification sera envoyée et administrateur sera réveillé.