Habituellement, les applicatifs écrivent les logs dans des fichiers textes : auth.log, boot.log, apache2.log, graylog2.log, … Pour pouvoir consulter ces logs et vérifier par exemple qu’une mise à jour n’a pas eu d’effet indésirable, il faut parfois se battre avec des outils comme cat, grep, awk, sort, et bien d’autres.
Une fois que vous avez le combo ultime « cat | grep | awk » qui vous retourne les informations pertinente, … vous devrez répéter l’opération sur chaque serveur hébergeant votre application. Pas très efficace comme méthode et cela peut s’avérer dangereux si la puissance nécessaire à l’exécution de votre combo ultime fait monter le load average du serveur !
Les fichiers de logs peuvent très vite devenir lourd et atteindre plusieurs Gigas. Vous devez pensez à mettre en place une rotation des logs et une épuration lorsque le volume de donnée devient trop important.
Une solution ?
Aussi, plutôt que de devoir allez chercher les logs sur chaque serveur, vous devez les centralisez ! En mettant en place une solution de centralisation des logs, vous pourrez depuis un endroit unique effectuer des recherches, analysez vos logs et mettre en place des alertes en cas d’erreurs importantes. Chacun des intervenants, exploitant, développeur, chef de projets, … pourra ainsi avoir accès à des données importantes mais trop souvent inutilisées. Voici quelques exemples d’utilisations :
- Détection d’intrusions ou de compromissions de vos serveurs : vous pourrez surveiller efficacement toute tentative d’intrusions sur votre plateforme. Si le piratage est avéré, vous aurez accès à tous les logs de la machine infectée même si le pirate supprime les fichiers de logs pour cacher ses méfaits.
- Debug des applications : dès la première erreur sur une application critique, les développeurs pourront analyser les logs afin d’étudier ce qui n’a pas fonctionné et proposer un patch très rapidement sans attendre que le client se manifeste.
- Archivage des journaux web : heure de connexion, ip, pages demandées, … les logs apache, nginx et autres renseignent sur de nombreuses informations qui peuvent être utilisées par les exploitants pour ajouter des serveurs si besoin, par le marketing pour analyser le trafic, …
- Gestion des alertes : configurer des règles pour être prévenu par exemple dès qu’un applicatif génère une erreur critique ou dès qu’un site génère plus de 10 erreurs 500 sur les 5 dernières minutes.
- Historisation des actions : sur des applicatifs sensibles, il peut être intéressant d’historiser les actions utilisateurs et les modifications de configuration.
- Affichage de tableau de bord : les logs au format brut ne sont pas toujours facile à analyser, mais en générant des graphiques, il devient plus facile de suivre l’évolution du trafic d’un site web sur plusieurs semaines.
- …
Les outils pour centraliser les logs ne manquent pas : certains sont payants, d’autres ne proposent pas toutes les fonctionnalités ou bien sont difficile à prendre en main. Voici quelques exemples : Splunk, Logstash + Kibana, Flume, … et bien sur Graylog2.
Simple à installer, Graylog2 permet de recevoir des logs au format Syslog, Plaintext, GELF (format propre à Graylog2 qui permet notamment l’envoi de logs multi-lignes), … Il est également possible de mettre en amont un outil comme Logstash si vous souhaitez retravailler les logs avant de les sauvegarder.
Pour en savoir plus sur la mise en place de Graylog2, je vous invite à lire le tutoriel décrivant son installation.
Source de l’image du datacenter