Ne pas devenir dingue avec sa supervision

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.

1.6 La production avant tout

Notre cher administrateur s'aperçoit cependant que son attention est attirée très souvent vers des alertes « critiques » qui ne concernent que des environnements de qualifications. En pleine action sur de la production, c'est du temps perdu et un risque de le déconcentrer de son vrai rôle. De plus, à force de recevoir trop d'alertes critiques, il va finir par ne plus y faire très attention ou penser à tort que ceci concerne des environnements « pas si importants que ça ».

C'est un tort. Les notifications sont très pratiques, mais elles doivent garder leur statut d'information importante, sinon elles sont contre-productives. C'est pour cela qu'il est intéressant de ne pas envoyer d'alertes pour les environnements autres que la production. C'est un choix important que doit faire Éric, car il devra suivre sur les consoles de supervision les alertes sur autres environnements moins critiques. Mais il est sûr que la production sera traitée en priorité. Et c'est bien là l'essentiel.

Pour cela, il lui suffit de mettre :

dans la configuration de ses hôtes de qualification et des services qui y sont accrochés.

1.7 Quand une perte réseau n'est pas « critique »

Les administrateurs ont l'habitude de configurer leurs outils pour lever une alerte critique dès qu'une perte de connexion se produit. Or ce phénomène n'est pas si rare, et suivant quelle information était demandée, l'erreur peut ne pas être si grave.

Il faut différencier deux cas :

- test d'un applicatif « réseau », comme une page web ou un service DNS ;

- récupération d'une valeur « système », comme la charge CPU.

Dans le premier cas, la perte de connexion est représentative d'un problème sur ce que l'on cherche à vérifier, il est donc normal de lever une alerte critique.

Mais dans le second, ne pas obtenir l'information sur le CPU n'est pas si critique que cela. Si l'administrateur lève une alerte sur ce seul motif, des notifications vont être lancées avec généralement comme titre « CPU CRITICAL », et ses collègues vont croire à un problème applicatif au lieu d'un problème réseau car une bonne partie d'entre eux ne lisent que le titre du mail d'alerte !

Il est plus sage de mettre l'état du service comme « UNKNOWN », car après tout, c'est vrai, on ne sait pas si le CPU va bien ou pas. Une telle alerte va demander par le jeu des dépendances un test de connectivité de l'hôte. Si le problème réseau était passager, le test ne lèvera pas de souci. L'état du service étant UNKNOWN, les administrateurs ne vont pas recevoir d'alertes, sauf s'ils l'ont demandé expressément, ce qui est déconseillé dans un tel cas. Si l'hôte avait vraiment un problème, ils recevraient une vraie erreur signalant que l'hôte a un souci, et non pas juste un hypothétique problème de CPU.

En limitant ces « fausses erreurs », on en augmente par la même occasion la pertinence et donc l'acceptation de ces données par les administrateurs.

1.8 La notion de criticité

Comme nous l'avons vu précédemment, il n'est pas très utile de lever une notification sur un environnement de qualification. Si ceci est simple à gérer du point de vue des « applications », ça l'est beaucoup moins lorsque l'on regarde comment filtrer les alertes sur les éléments d'infrastructures.

Il faut bien noter que ce qui est « important », ce sont les applications finales pour les utilisateurs. Nos chers serveurs et autre routeurs n'ont aucune importance (autre que sentimentale, bien entendu). Ils peuvent cependant être responsables de problèmes sur les applications. Mais comment gérer convenablement les notifications sur un routeur, par exemple ? Si ce dernier tombe et qu'il n'impacte qu'un environnement de qualification, est-ce utile de réveiller l'administrateur réseaux en plein milieu de la nuit pour cela ? Non, bien entendu. Mais si ce même routeur impacte de la production, là son sommeil a toutes les raisons d'être interrompu !

Autant le dire de suite : gérer cela avec Nagios n'est pas chose aisée. Si « l'impact » du routeur est très éloigné dans l'arbre de dépendances, il n'est pas facile de décider s'il doit lever des notifications ou pas. C'est pour cela que la plupart des administrateurs les laissent activées par peur de rater un jour une véritable alerte de production.

Shinken, quant à lui, ajoute un paramètre de « criticité » aux hôtes et aux services. C'est un simple entier entre 0 (équivaut à « n'a pas d'importance ») et 5 (« très très important »), et vaut 3 par défaut.

Lorsqu'un « problème source » va être identifié, il va prendre comme criticité la valeur maximale de ses « impacts » (ou la sienne si elle est supérieure). Ici, dans le cas d'un impact sur une application de développement qui a la criticité 0, il va garder son niveau 3. Dans le cas où il impacte une application de production, il va obtenir, temporairement, le temps du problème, le niveau de criticité maximal, soit 5.

Il est alors intelligent de ne changer que la criticité des extrémités des branches de dépendances, soit les applications finales, celles qui nous intéressent. Ce qui tombe bien, car ces éléments sont en général bien moins nombreux que l'armée d'équipements d'infrastructures qui les sous-tendent.

Ce niveau peut servir comme filtre pour les notifications. Et c'est à ce titre qu'il va être utile ici. Dans la configuration de notre contact pour l'alerte SMS de nuit, il suffit de placer le niveau minimum de criticité à 5 pour que l'administrateur puisse continuer à dormir tranquillement en cas d'impact sur un simple serveur de développement.

Ceci donne la configuration suivante pour Éric :

2. Ne pas se perdre dans sa console

Nous avons vu qu'Éric devait suivre ses consoles de supervision : ses alertes par mail sont en général succinctes pour ne pas alourdir la lecture, mais il peut avoir besoin d'informations complémentaires qu'il trouvera dans son interface favorite.

Si ces applications, basées sur du Web pour la plupart, sont sympathiques et jolies, elle ne sont cependant pas si simples que cela à gérer convenablement pour être efficaces.

Notre administrateur est ravi, sa boîte mail n'est plus remplie d'alertes inutiles, mais ce n'est pas le cas de sa console de supervision : elle est remplie de pages et de pages d'alertes, et il ne sait pas comment faire le tri dedans.

Il note également un effet « tout en rouge ». Ce dernier est classique en supervision : quand un administrateur s'est habitué à voir du rouge dans une interface, il ne fait plus attention aux nouvelles alertes. Regardons un peu comment tout ceci peut se produire, et surtout comment l'éviter.

2.1 Thruk, une console faite pour la corrélation

Pour la suite de l'article, nous supposerons que le moteur de supervision utilisé est Shinken. En effet, Nagios ne supporte pas les fonctionnalités présentées par la suite.

Notre cher administrateur était resté depuis des années avec son ancienne interface Nagios compilée mais horriblement lente et désuète. Il va donc en installer une nouvelle faite en Perl, qui se nomme Thruk, mais qui garde un style proche de ce qu'il avait l'habitude de voir.

Son installation est fort simple, ici sur une machine Ubuntu 10.10.

Pour le lier à son moteur Shinken, il suffit de décommenter dans le fichier thruk_local.conf les lignes :

Du côté de Shinken, si l'administrateur a gardé sa configuration standard, il n'a rien à faire. Dans le cas contraire, il doit juste vérifier qu'il a bien activé le module nommé LiveStatus.

Le lancement de Thruk est ensuite fort simple :

L'accès à son interface se fait sur http://localhost:3000.

2.2 Les problèmes/impacts associés à la criticité

Nous avons vu que la notion de problème source et d'impacts était gérée pour les notifications. Il est intéressant de voir que Shinken est également capable d'exporter ces informations aux consoles pour une visualisation en temps réel. Thruk les utilise afin de présenter sur la page d'un élément impacté un lien vers le ou les problèmes sources qui en sont à l'origine. De même, sur la page d'un problème source, il est possible d'avoir la liste des impacts qu'il produit.

Une vue permet de ne lister que les problèmes, n'affichant pas tous les impacts. Ceci est très pratique pour que les administrateurs sachent directement « quoi » régler et ne passent pas le plus clair de leur temps dans la console à trouver les problèmes sources.

Cette page de présentation est en même temps triée sur la criticité. Nous avons vu que cette valeur est représentative de celle des impacts. Ainsi, les administrateurs ont également l'information sur « dans quel ordre » régler les problèmes.

Leur outil de supervision a donc identifié pour eux les problèmes, les sources et l'ordre dans lequel les régler. De là à ce que l'outil de supervision résolve également les problèmes à leur place, il n'y a qu'un pas...

2.3 Le lancement des event handlers

Un pas que nous allons franchir maintenant. Nagios et Shinken gèrent ce que l'on nomme les « event handlers », qui sont des commandes qui peuvent être lancées pour corriger un problème. Le souci avec ce mécanisme alléchant réside dans son automaticité. Par exemple, une telle commande peut relancer un service Apache en cas de problème. Mais que se passe-t-il si cet arrêt était souhaité, comme l'installation d'une nouvelle version, par exemple ?

Bien entendu, il est possible de prévenir ces outils d'une maintenance sur ce service pour une certaine période. Mais il arrivera un jour où l'administrateur oubliera cette précaution et verra son service relancé en pleine migration. À ce moment-là, les impacts peuvent être très sévères...

C'est pour cela qu'il est plus sage de désactiver cette fonctionnalité de lancement automatique. C'est exactement ce qu'avait fait Éric avec son ancien Nagios.

Heureusement, Shinken possède un mécanisme de lancement à la demande uniquement de ces commandes. Thruk offre une interface à cela.

Par exemple, nous allons lancer à distance un redémarrage de service Apache. La définition de la commande est fort simple si nous avons déjà placé nos clés SSH :

Et dans la configuration de notre service HTTP qui surveille son fonctionnement :

Le paramètre event_handler_enabled est utile pour savoir si le lancement est automatique ou non. Ici, il ne pourra être lancé qu'à la demande d'un administrateur.

Sur l'interface Thruk, quand l'administrateur remarque que le service Apache ne répond plus, il peut décider de cliquer sur le bouton « launch event handler », qui fera lancer le redémarrage du daemon sur le serveur distant. L'administrateur n'a même plus besoin de se connecter sur la machine pour régler le problème, c'est le summum de la feign... de l'efficacité pour notre cher Éric.

3. Le chef s'en mêle

Tout allait bien pour notre cher administrateur, qui avait une boîte mail à taille humaine, une interface de visualisation des alertes qui lui mâchait la majeure partie du travail, quand son chef vint lui demander d'avoir accès à ces mêmes informations. Enfin pas tout à fait les mêmes pour être exact. Là où Éric est intéressé par les sources de problèmes pour les régler au plus vite, et où la criticité des impacts est synonyme de simple ordre de résolution, son chef désire l'exact opposé : ne voir que les applications métiers les plus critiques, et s'il clique dessus, voir (simplement) ce qui ne va pas (comprendre : quel administrateur aller « motiver »).

3.1 Les règles métiers, ou agrégation de services

Là encore, Shinken et Thruk vont être utiles pour notre administrateur. Le premier permet de définir des règles métiers complexes pour que l'état d'un service ou d'un hôte soit en fait régi par une expression complexe sur l'état d'autres.

En effet, de nos jours, il n'est pas rare d'avoir des architectures en mille-feuilles pour une unique application. C'est généralement le prix à payer pour de la haute disponibilité et de la souplesse d'évolution. Mais ceci complexifie grandement la récolte d'une information simple : l'application fonctionne-t-elle bien ?

Or cette question est la seule qui intéresse les utilisateurs, et donc la seule au final qu'il faut se poser. Avec les règles métiers de Shinken, la réponse apportée est fort simple. Lorsque tous les éléments constituants d'une architecture sont surveillés, il suffit d'un service supplémentaire pour « agréger » le tout.

Prenons le cas d'un ERP web standard. Il a besoin pour fonctionner de :

- au moins une base de données MySQL sur les deux à sa disposition ;

- au moins 2 serveurs d'applications sur les 3 à sa disposition pour des questions de charges ;

- au moins un répartiteur de charge sur les deux disponibles.

Sa définition est alors :

Bien entendu, il est possible de déplacer des parties de la règle dans un autre service (comme h1,Mysql|h2,Mysql sous un service ERP-Database qui sera appelé par ERP) dans un souci de lisibilité.

La commande bp_rule n'a pas à être définie, elle est un mot-clé dans Shinken. De plus, un tel service est tout à fait standard, il ne diffère des autres que par la manière dont il obtient son état, mais son ordonnancement ne change pas de ce qu'Éric a l'habitude de connaître.

3.2 Thruk et les règles métiers

Thruk est capable, avec un module prochainement inclus dans la version officielle, de lister ces règles et d'afficher ses composantes. Il est pour l'instant disponible avec la version de Thruk fournie dans la machine virtuelle de démo de Shinken. Pour chacune des règles, il va également lister ses dépendances. Si, par exemple, le service HTTP est dépendant d'un service NFS, il sera présent sur ce qui va ressembler à l'arbre de dépendances de ERP.

Voici un exemple de ce que cela donne :

Il est intéressant de voir que si un problème se pose dans cet arbre et qu'il impacte ERP, alors le fonctionnement des problèmes sources/impacts est opérationnel pour suivre cela.

L'administrateur n'a pas besoin de définir des relations de dépendances de type service_dependencies pour lier ERP et ses pères. Ceci est fait automatiquement par le cœur de supervision. Ceci inclut également la gestion de la criticité. ERP est, par exemple, un parfait candidat pour le niveau de criticité maximal. Il apparaîtra en priorité dans les pages de Thruk et dans les notifications que vont recevoir les administrateurs.