...
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 n'étaient pas notifiés si s'il y a avait un problème de dépendance (un hôte en DOWN place plaçait les notifications du check en "ne pas envoyer") Mais , mais dans ma la console, on a avait toujours des élemnst é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 .
...
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 .
...
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é 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 en 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é au serveur aux serveurs d'applicationapplications, la seule priorité qu'il récupère est celle des hôtes et checks qui lui sont connectés.
...
- 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 à 22, 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 mais cette fois l'impact est sur lml'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é réveillé.