Page History

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.

Cas d'exemple

Application du principe de corrélation

Notifications

Les notifications appliquent ce principe en n'envoyant qu'une notification dans le cas d'un problème source.

Prenons par exemple, un service web présent sur un serveur est lui connecté via un switch.

• Si le switch tombe, le serveur et donc le service web ne sont plus disponibles.
• Au lieu d'envoyer une notification pour chaque partie de l'infrastructure ( serveur, service web et switch ), la corrélation permet de n'envoyer qu'une notification pour l'élément à l'origine du problème c'est-a-dire le switch.

Les checks deviennent INCONNU si leur parent est CRITIQUE ( Optionnel )

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 suivant où

• un check ( par exemple CPU ) retourne un OK,
• la vérification de l'hôte arrive en CRITIQUE, et l'hôte est certifié tombé ( on a atteint son nombre maximum de tentative de vérification )
• on a donc sur l'interface:
  • un hôte en CRITIQUE,
  • 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 INCONNU, 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:

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)

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:

Image Removed

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.

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 ?

Par contre dans un souci de cohérence, cette état / résultat sera également disponible dans les autres modules, genre SLA ou les Événements.

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 Il suffit juste d'activer le paramètre:

enable_problem_impacts_states_change=1

Visuellement, le check apparaitra de la manière suivante, indiquant que son état a été modifié par Shinken:

Priorité dynamique

Tous les parents d'un hôte sont tombés

Dans le cas où on a des dépendances réseaux ( entre 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 INCONNU :
  
  • 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.
  • pour les gestionnaires d'événements, Nagvis et le module livedata, cet état est nommé INJOINGNABLE ( UNREACHABLE ).
• s'il n'a pas de parents, ou qu'au moins un de ses parents est disponible, alors il sera affiché comme CRITIQUE,
  • car il y a bien un chemin réseau pour lui parler, et donc s'il ne répond 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 "server" ayant pour parents switch-1 et switch-2.

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:

Cette vue peut donc être très pratique quand les relations de dépendances sont configurées.

Impact métier dynamique

L'impact métier permet de déterminer si un problème source est plus ou moins important, en sachant s'il a cassé quelque chose d'important.

Si les liens de dépendances ( clusters, parents ) sont définis dans Shinken, alors ce dernier va être capable de propager les impact métier, des impacts vers leurs problèmes sources.

Dans notre exemple, nous avons un cluster ( mon-appli ) qui repose sur un simple serveur Http, dont l'hôte ( server ) dépend de deux swtichs ( switch-1 et switch-2 ).

Dans la configuration, seul le cluster a un impact métier important:

Les hôtes server, switch-1 et switch-2 ont quant à eu des impacts métiers normaux, par exemple notre hôte server:

Quand on regarde du côté de l'interface de visualisation, on remarque que Shinken a mis à jour l'ensemble des impacts métiers de la chaine, de proche en proche:

• Le check Http sur l'hôte server ayant cassé le cluster avec un haut impact métier, il gagne lui-même cette valeur
• L'hôte server ayant cassé son check, il gagnera lui-même une haute valeur
• Les switch-1 et switch-2 ont étés détectés comme ayant cassé l'hôte server, ils héritent également de la haute importance métier.

Ceci se traduit dans l'interface de visualisation par une colonne Priorité qui a sa valeur au maximum, comme celle du cluster mon-appli:

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