Qu'est ce que la corrélation?
L'objectif de cette fonctionnalité est de proposer à l'utilisateur d'avoir la même vue dans la console que le résultat des notifications. .
Jusque là; les utilisateurs ne sont pas notifiés si il y a problème de dépendance (un hôte en DOWN place les notifications du check en "ne pas envoyer" ) Mais dans ma console, on a toujours des élemnst en vert ou en rouge : le scheduler attendait les résultats de checks pour mettre l'élément en état UNKNOWN ou UNREACHABLE .
Maintenant, le système est assez intelligent pour placer ces états sur les éléments sachant que le check va échouer. Un exemple?
Prenons ce type de relation entre éléments:
 | Si gw est DOWN, tous les checks des autres éléments seront en état UNREACHABLE . Mais si fw et servers sont vérifiés 5 minutes plus tard, pendant cette période, la console indiquera du vert pour eux, alors qu'ils ne sont pas vraiment et seront en erreur au prochain check. Voici ce que fait la fonctionnalité de gestion des impacts : quand la passerelle est sur HARD/DOWN, il applique un état UNREACHABLE (et UNKNOWN pour les checks) pour les éléments dessous. Cela permet à l'administrateur de voir diretement qu'il y a un problème et quels sont lés éléments impactés . |
Il est important de savoir que cette approche ne remet pas en cause la logique de gestion HARD/SOFT : il s'agit juste d'un changement d'état pour la visualisation, mais ce n'est pas pris en compte dans la gestion des tentatives de checks .
Dans ce cas, la passerelle est déjà en DOWN/HARD. Aucun des serveurs n'a de valeur en sortie, ils ne sont pas encore vérifiés, mais sont déjà en état UNREACHABLE . Quand ils seront vérifiés, il y aura alors une valeur retour et ils prendront l'état correspondant.
Comment l'activer ?
Il suffit juste d'activer le paramètre:
enable_problem_impacts_states_change=1
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érité 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 en environnement de développement avec une faible priorité (0 ou 1) et un 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é au serveur d'application, 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,même cette fois l'impact est sur lm'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é
Add Comment