1. Limiter le nombre d'alertes

Une solution de supervision est là pour aider les administrateurs dans leur tâche du maintien en production des applications. Basiquement, ceci se résume facilement : elle est là pour leur dire ce qui va et ce qui ne va pas. Mais parfois, elle fait tourner en bourrique ses (pauvres) utilisateurs.

1.1. La dure vie d'administrateur

Nous allons suivre un de ces courageux. Il se nomme Éric et est un fier administrateur réseaux. Il revient d'un week-end bien reposant, et va en avoir besoin : plus de 500 emails de son outil de supervision l'attendent ! Ses collègues en ont également reçu autant, et le support reçoit appel sur appel concernant les applications qui ne sont plus disponibles. Un lundi standard donc.

Éric sait que la solution à son problème doit se trouver parmi sa montagne d'emails. Il prend son courage à deux mains (il faut dire que son chef rôde déjà autour de son bureau), car c'est bien connu que le réseau est le premier accusé dans une telle situation. Après plus de 15 (longues) minutes de lecture, il abandonne et se lance dans des lancements éperdus de ping et de traceroute à tout va. Encore 15 minutes après, il arrive enfin à identifier le problème et le corrige aussitôt.

Éric a été la victime d'un outil de supervision trop verbeux. Bien trop verbeux même. Au lieu de lui faire gagner du temps, il a réussi à lui en faire perdre. Un comble.

1.2. Se concentrer sur les sources des problèmes

Regardons un peu ce que notre administrateur avait dans sa boîte mail :

• 1 email sur l'élément réseau défectueux ;
• 499 sur les éléments qui étaient impactés par ce dernier.

Là est le bas qui blesse. Éric avait mélangé dans sa boîte les notifications sur le problème source et ses impacts. Les notifications ne sont pas justes là pour prévenir qu'il y a un souci, mais également indiquer lequel et de la manière la plus précise possible. Les alertes sur les problèmes sources doivent être prioritaires. On peut même considérer que les notifications sur les impacts ne sont pas utiles dans la plupart des cas (les consoles de supervision, voire les utilisateurs, sont plus réactifs et adaptés ici).

1.3. Les dépendances réseau

Switchs et routeurs sont là pour relier les clients et les serveurs, mais lorsqu'ils tombent, ces derniers ont quelques légers soucis. Est-ce utile dès lors de notifier les administrateurs des dizaines d'impacts qu'une cause unique a provoqués ? Les notifications doivent servir à identifier au plus juste les sources, afin que les administrateurs sachent immédiatement quoi réparer.

Cette information de problème source et d'impacts n'est pas innée pour les outils de supervision. Ceux qui connaissent le mieux ces relations sont les administrateurs eux-mêmes. Nous allons prendre comme support la star de la supervision Nagios open source, et son petit frère Shinken.

Dans ces deux outils, il est possible de définir un ou plusieurs parents à un hôte (serveur, switch, routeur, ...). Cette définition est très simple. Prenons, par exemple, le serveur srv-web1, qui est connecté sur le switch sw-prod-1. La définition du serveur est alors :

En cas de souci sur le switch, le serveur ne sera plus disponible, et avant de lever une notification, nos deux outils vont remonter l'arbre de dépendances afin de trouver le vrai coupable. Un test va être lancé immédiatement sur le switch, qui ne répondra pas. La seule notification levée sera celle sur ce dernier, car il est le vrai problème source.

Éric ayant résolu son souci, il va pouvoir passer sa journée à retracer les dépendances dans son réseau et mettre à jour son outil. Cette journée de configuration lui sauvera des semaines de futur travail. Éric est un bon administrateur.

1.4. Les dépendances applicatives

Le bureau à côté de celui d'Éric est occupé par un administrateur système nommé Nicolas. Il doit gérer des éléments encore plus instables que les équipements réseau d'Éric : des applications. Ces dernières ont la fâcheuse manie d'en utiliser d'autres. Pire, si ces dernières tombent pour une quelconque raison, les impacts peuvent s'empiler en cascade.

C'est en effet le côté obscur des architectures N-tiers. Si une des couches n'est plus disponible, c'est toute l'application qui va céder. David n'a pas à être jaloux d'Éric, car lui aussi est capable de recevoir des alertes focalisées sur les sources de problèmes s'il a pris soin de déclarer des dépendances entre ses services.

Une dépendance entre deux services signifiera que si le service maître (B) tombe, alors celui qui en est dépendant (A) n'est pas responsable de son pauvre sort en cas de problème. Typiquement, B sera un service de base de données, et A le service web qui l'utilise.

Dans Nagios, cette définition passe obligatoirement par la création d'un objet servicedependency comme ci-dessous :

Ici, si le service Mysql est dans un état anormal (Warning, Unknown ou Critical), alors le service HTTP ne lèvera pas de notification (inutile).

Dans Shinken, il existe en plus de l'objet servicedependency de Nagios un moyen plus simple pour définir une telle relation qui s'inspire de la facilité de configuration des dépendances réseau.

Dans la configuration du service HTTP, il suffit d'ajouter le paramètre :

Notez le pluriel de service_dependencies : un service peut être dépendant de plusieurs autres. Là où en dépendance réseau, il faut que tous les pères soient indisponibles, ici un seul suffit à lever la faute de l'objet.

1.5. L'effet " yoyo "

Le lendemain, Éric s'attend à trouver une boîte mail quasiment vide. Malheureusement pour lui, ce n'est pas le cas. Elle est remplie d'alertes UP/DOWN pour un unique routeur qui a passé sa nuit à redémarrer toutes les minutes !

Heureusement pour notre cher administrateur, nos deux outils savent gérer ce cas avec un algorithme fort simple. Ils conservent un historique des états (de taille fixe à 21 pour Nagios, paramétrable pour Shinken) et comptent le nombre de changements qu'il y a eu. Si ce nombre est plus important qu'un certain seuil, l'élément est déclaré en état " flapping ", et une seule notification sera levée pour prévenir de cet état le temps que le taux de changement ne revienne à une valeur plus acceptable.

Dans la configuration globale, il suffit de déclarer :

Avec ceci, si la machine commence à alterner d'état, une fois le taux de changement dépassant 50 %, elle sera déclarée comme en " flapping ". Pour en sortir, le taux de changement devra redescendre sous les 25 %.

Ces paramètres sont également disponibles pour les services. Avec ceci, Éric est désormais serein sur la taille de sa boîte mail pour le lendemain et part s'occuper de son routeur défaillant.