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 n'étaient pas notifiés s'il y avait un problème de dépendance (un hôte en DOWN plaçait les notifications du check en "ne pas envoyer"), mais dans la console, on avait toujours des éléments 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, avant ce prochain check, la console indiquera du vert pour eux, alors qu'ils ne sont pas vraiment accessibles. 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 directement qu'il y a un problème et quels sont les é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é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é.