Introduction

Il existe au sein des systèmes d'information des indicateurs qui permettent d'anticiper les problèmes et dysfonctionnements en production afin d'éviter les coupures de service pour les utilisateurs : le log (message horodaté).

Lors de l'exploitation des solutions informatiques, le log est souvent négligé alors qu'il apporte une vraie valeur pour les exploitants (que nous appellerons ici OPS), les développeurs (que nous appellerons ici DEV) et les personnes du métier.

• Ne vous est-il jamais arrivé suite à un bug en production de vous lancer à la recherche de la ligne de log vous permettant d’expliquer ce problème dans les différents journaux sur les différentes machines constituant votre solution ?
• Ne vous est-il jamais arrivé de pester en réalisant que le problème aurait pu être évité car vous vous rendez compte que le souci se produit quotidiennement et que cette fois-ci à été celle de trop ?
• Ne vous êtes-vous jamais demandé où est passé l'information métier dans le système ?
• Avez-vous déjà eu la bonne surprise d'apprendre qu'une fonctionnalité est inopérante par un utilisateur / client ?

Si vous avez répondu oui à l’une de ces question ou si vous êtes curieux, vous êtes au bon endroit !

Pourquoi utiliser la centralisation des logs ?

Redonner de la visibilité aux logs

Imaginons l'infrastructure suivante :

Dans ce schéma, les applications App 15 et App 6 produisent des logs d'erreurs.

Malheureusement l'équipe d'exploitation ne remarque pas ces messages d'erreurs. En effet, n’ayant pas le temps de scruter tous les logs des serveurs un à un, l’équipe d’exploitation a pris la mauvaise habitude de regarder les logs qu’une fois qu’un événement survient en production.

Avec la centralisation des logs, l'équipe d'OPS aurait constaté que des erreurs se produisent périodiquement et de plus en plus fréquemment. Par conséquent, les OPS auraient donc pu mettre en place des solutions pour éviter une coupure de service en production.

https://www.elastic.co/guide/en/kibana/current/errors.html

Sur l'exemple ci-dessus, on constate qu'il se produit beaucoup d'erreurs “java.io.IOException: Connection reset by peer” ce qui révèle un service remote utilisé par une application inopérante (si l'application appelante n'a pas implémenté de circuit breaker, il y a une très forte probabilité qu'elle soit défaillante elle aussi).

Aussi, après cet incident, l'équipe de développement a exprimé le besoin d'accéder aux logs de la machine pour comprendre et corriger les dysfonctionnements applicatifs.

Malheureusement, l'incident s'étant produit en production, les DEV n'ont pas accès aux machines concernées par souci de sécurité et de “stabilité” .

Pour y avoir accès, ils ont dû écrire un ticket à l'équipe d'exploitation pour que ceux-ci leurs envoient le log dont ils ont besoin (“c'est la procédure…”).

Par manque de "chance", l'OPS n'a pas envoyé la liste de logs contenant l'information permettant de corriger l'incident. On ne peut pas lui en vouloir puisqu’il ne connaît pas vraiment l'application et ne sait pas quoi rechercher exactement.

Encore une demande par ticket et hop ! le DEV a enfin son message d'erreur complet.

Bilan de l'opération : 2 jours pour avoir l'information permettant de corriger l'incident et donc autant de jours de décalage pour corriger l'incident de production. Bref, un processus d'investigation compartimenté et lourd ne permettant pas un TTR (Time To Repair) optimal.

Les outils permettant de faire de la centralisation de logs donnent tous un moyen d'accéder aux logs sans avoir à se connecter à la machine (j'expliquerai cela dans la suite de l'article) contenant le log source. Donner l'accès à ce moyen de visualisation aux développeurs  permet de faire gagner du temps aux deux équipes (DEV et OPS) :

• Le DEV n'a plus à demander à l'OPS de lui fournir les logs. Il a donc ce qu'il veut directement sans passer par la rédaction d'un ticket et sans attendre le retour de l'OPS.
• L'OPS n'est pas dérangé sur les tâches apportant une vraie valeur ajoutée au SI.

Diagnostiquer plus simplement les dysfonctionnements applicatifs

Établir un diagnostic sur un problème qui survient sur une application distribuée utilisant un lot important de services peut s'avérer compliqué.

La plupart du temps, on investigue en regardant les logs de l'application en erreur. Si l'erreur vient d'un service qui est utilisé par l'application alors on se connecte sur le service en question pour voir ses logs et ainsi de suite. Pour peu que l'architecture soit très distribuée, trouver la root cause peut s'avérer peu trivial. Pour peu que l’on se soit aperçu de l'erreur trop tard et qu'il y ait une rotation des logs un peu trop agressive, le message de log serait perdu et il faudrait attendre une nouvelle erreur pour pouvoir investiguer en détail.

Avec la centralisation des logs, il est possible de diagnostiquer plus simplement les erreurs : les logs de toutes les applications sont centralisés au même endroit, découplés des vrais logs (la recherche ne se fait pas sur les logs de l’application mais sur une copie) et visibles sur une seule et même interface.

Ces interfaces de visualisation ont pour la plupart des moteurs de recherche qui permettent de rechercher un log en fonction d'une date, d'un pattern ou d’un mot clé.

Il est donc possible de ressortir les logs répondant aux questions suivantes :

• Donne-moi les logs à telle date.
• Donne-moi les logs dont la sévérité est ‘ERROR’ à telle date.
• Donne-moi les logs entre telle date et telle date.
• Donne-moi les logs entre telle date et telle date de l'application X et Y.
• Donne-moi les logs contenant le mot clé ‘NullPointerException’ à telle date pour l'application Y.
• etc.

En utilisant un tel moteur de recherche, il est assez simple de naviguer à travers les logs de son SI et de déterminer la root cause d'un problème applicatif.

NB: Le format des logs ainsi que la manière de faire cela techniquement sera abordé dans un article ultérieur.

Mettre en place des indicateurs

Rendre les erreurs visibles

En complément des outils classiques permettant d'avoir une surveillance de son système (tels que Nagios ou Zabbix), la centralisation des logs permet d'avoir une vue sur l'état de santé de son système et de mettre en place des indicateurs sur l'utilisation de ses services ou interfaces web.

Sans entrer dans le détail des dashboards, le fait de centraliser les logs permet par la suite de mettre en place tout un ensemble de graphes permettant de voir à un instant t ce qu'il se passe au sein de son SI.

Ainsi un OPS pourrait avoir un écran contenant un graphe des applications down avec un tableau contenant par exemple :

• le top 10 des erreurs de production de la journée.
• le top 10 des erreurs les plus fréquentes depuis 10 jours.
• le niveau de mémoire utilisée au sein des JVM sur une semaine.

Cet ensemble d'indicateurs permet d'anticiper les futurs problèmes de production. Grâce à l'aide de ces écrans, il est beaucoup plus facile de détecter les futurs problèmes tels que les fuites mémoire par exemple (l'indicateur de mémoire étant tracé au sein de l'outil et visible via les dashboards associés).

Piloter l'évolution des applications

Maintenant imaginons que nous avons une API REST dans notre système mais comme cette API est noyée dans les diverses autres API, nous n'avons pas de visibilité sur la volumétrie d'appels sur les différentes ressources.

A l'aide de la centralisation de logs, il suffit d'écrire un message de log dès qu'un appel est fait sur une ressource en incluant également les paramètres entrants (saufs données sensibles comme les mots de passe bien sur ;-) ), les données sortantes et le code http de retour.

Avec ces informations, nous pouvons donc :

• Établir un classement sur nombre d'appels sur les ressources REST,
• Établir également un top des codes HTTP.
• Identifier les paramètres qui sont le plus utilisés sur les requêtes HTTP.

Cela permet par la suite de piloter l'évolution de l'API (refactoring, décommissionnement, nouvelle ressource, etc.).

J'ai pris l'exemple d'une API REST mais il est tout à fait possible de faire la même chose sur toutes les applications à partir du moment où vous avez la main sur le développement de celle-ci.

Ce qui est intéressant avec la centralisation des logs, c'est qu'il n’y a rien à ajouter techniquement au sein de l'application en elle même car les logs sont la plupart du temps déjà intégrés au sein des solutions logicielles (si vous n'avez pas de logs dans vos applications alors vous savez par où commencer). Pour piloter vos applications, il suffit d’ajouter les bons messages aux bons endroits.

"Ok mais quel est le bon endroit ?" vous allez me dire.

Et je vous répondrais que cela dépend de vos applications. En règle générale, logger les entrées sorties des applications est déjà révélateur de nombreuses informations et suffit à avoir une vue de l'utilisation des applications. Cependant à vous de voir au sein de votre application quelles informations vous voulez voir remonter.

Suivre les données métier et aider au support applicatif

Comme je l'ai écrit précédemment, ajouter des logs au sein d'une application est peu coûteux en terme de développement pur.

La centralisation des logs ayant les messages de toutes les applications du SI, qu'est ce qui empêcherait d'effectuer un suivi des informations métier ?

Par exemple prenons le cas d'une application de gestion de commande qui aurait l'architecture suivante :

Monsieur Jean Dupont n'a pas de compte sur l'application et souhaite effectuer une commande. L'interface de l'application permet d'effectuer une commande sans avoir de compte. Les informations sur les produits sont récupérées d'un référentiel externe et pour finir tout passe un MOM (Message Oriented Middleware).

NDLR : oui je sais cette architecture n'est pas vraiment optimale pour ce type de besoin mais c'est pour l'exemple :-)

Lors de la commande, il y a donc deux informations mémorisées dans les référentiels :

• Le client
• La commande

Une fois que Monsieur Dupont a validé sa commande, il reçoit un beau message d'erreur lui indiquant que sa commande n'a pas pu être traitée.

Monsieur Dupont frustré, annule sa commande et se tourne vers un autre site marchand.

Après investigation, l'équipe d'exploitation se rend compte que les informations sur le client sont présentes dans le référentiel clients mais qu’il n'y a pas de commande dans le référentiel commandes (rien ne persiste dans le référentiel produits car ce n'est que de la lecture) :

En regardant les logs applicatifs, on s’aperçoit que :

• l'information sur la commande a bien été transmise jusqu'au MOM mais qu'elle n'est pas parvenue jusqu’à l'application de gestion des commandes métier.
• la file client a bien été alimentée mais que la file commande n'a pas reçu l'information.

Il y a donc un problème du côté du MOM :

Ceci est un exemple très simple. Cependant au sein d'un SI complexe, diagnostiquer et déterminer là où l'information se perd peut s’avérer beaucoup plus difficile et chronophage.

Avec la centralisation de logs, il est possible de mettre en place des indicateurs permettant de compter le nombre d’occurrences données d'un élément. Si on reprend l'exemple de la commande, on pourrait mettre en place des KPI en se basant sur les logs comme le temps qu'un client met entre la connexion et la commande, le nombre de commandes par jours, combien de nouveaux clients par jour, etc.

Le schéma ci-après représente l'architecture avec la solution de logs intégrée au système :

Être notifié d'un évènement inhabituel

Avoir une vue centralisée de ses logs c'est bien. Cependant, on ne peut pas être en permanence connecté sur l'outil pour visualiser l'état ou les métriques de son système d'information.

Pour pallier à cela, il existe des solutions de notification qui permettent d'être informé. Par exemple en cas de gros volumes entrants, ou alors quand il y a beaucoup d'erreurs 503 sur une ressource ou encore quand un utilisateur se connecte de plusieurs endroits.

Les notifications se déclenchant en fonction de seuils, il est très facile d'être informé de beaucoup d'événements au sein du système (attention à ne pas vous noyer sous les notifications, ce qui aura pour effet que plus personne ne traite ces notifications (syndrome de la boîte mail avec les 1000 messages non lus).

Il n'y a pas de “bonne pratique”, chaque système étant différent c'est à vous de déterminer avec vos équipes quels sont les indicateurs qui nécessitent la mise en place de notifications.

Les canaux d'informations peuvent être différents selon les solutions. Sur certaines, les notifications ne se font que par email, pour d'autres c’est peut être par chat (slack par exemple) ou webhook…

Conclusion

Se doter d'un outil de centralisation de logs peut sembler être dans un premier temps un outil superflu et non prioritaire à mettre en place dans un système complexe. Néanmoins, il s'avère incroyablement efficace dans une utilisation quotidienne.

De plus, avec des pratiques de développement homogénéisées au sein des équipes, le coût de mise en place d'indicateurs et de monitoring des applications devient très faible.

Avant de vous lancer dans la mise en place d'un tel outil, posez-vous ces questions :

• Est-ce que j'ai de la visibilité sur tous les événements de mon SI ?
• Est-ce que le coût de mise en place d'indicateurs sur une application est faible ?
• Est-ce que mon Time To Detect (TTD) et mon Time To Repair (TTR) sont faibles ?
• Suis-je sûr que mes fonctionnalités sont bien utilisées ?
• La communication / collaboration entre les DEV et OPS est elle fluide et efficace ?

Si vous avez répondu oui à l'ensemble de ces questions alors vous n'avez pas forcément besoin d'une telle solution.

Dans le cas contraire, vous avez une idée de piste de progrès ;-)