Comment gérez-vous les logs de vos applications ?

Hello,

J’ai récemment publié un article sur la façon dont nous avions recodé notre système de logs chez Aircall : https://medium.com/unexpected-token/how-we-refactored-our-logging-system-355d92e53c2d

Suite à cet article, j’aurais souhaité vous demander comment vous gériez les logs de vos applications et quelles sont les choses importantes, selon votre expérience, dans ce domaine ?

Merci d’avance pour vos retours !
Pierre-Baptiste.

Personne n’utilise de logs :) ?

Bon je m’y colle :)

On a une API Ruby avec un traffic modéré : 20-50 req/sec ; 1GB logs / jours
Hébergé sur Heroku.

Concernant les logs de cette API ce qui est important pour nous c’est :

  • Aggréger les logs des différentes dyno (comme le fait Heroku)
  • Une interface pour rapidement faire une recherche dans les logs
  • Nous proposer un historique de quelques jours pour la recherche + un backup longue durée sur S3 pour le reste
    Je précise qu’on se sert uniquement de nos logs pour faire du debug, on a pas encore de sujet analytics lié à nos logs.

Pour tout ça on utilise Papertrail (< 200$/mois) . Ca répond à nos 3 besoins on en est content.

P.S: Ton article est dans ma reading list, pas encore eu le temps de le regarder ;)

2 « J'aime »

Merci pour ton retour !

Est-ce que c’est un add-on heroku ? Si oui, ça fait directement une recopie de ton fichier .log vers Papertrail ?
Comment est-ce que vous retrouvez les lignes qui vous intéressent pour le debug ?

Oui ils ont un add-on Heroku. Mais on évite d’utiliser les add-ons, c’est très chiant d’en sortir. On préfère prendre un compte sur le site et l’ajouter sur Heroku ça prend 2’30 max et le pricing peut être plus avantageux (ca vaut pour New relic, Sendgrid, etc)

Pour aggéger les logs ils utilisent un Syslog drain sur Heroku.

Pour le debug on peut rechercher toutes les occurences d’un ID utilisateur entre telle heure et telle heure par exemple.

Je vous propose également mon retour d’expérience.
De notre côté, on centralise les logs avec Graylog hébergé en interne.

Chaque application doit obligatoirement envoyer dans les metadatas de chaque message 3 informations :

  • l’équipe
  • l’environnement (prod / préprod / dev)
  • le nom de l’application

Cela nous permet ensuite de créer des filtres dédiés en fonction des besoins et de créer les règles d’alertes permettant de prévenir les bonnes personnes au bon moment.

Enfin, on ajoute en fonction des applicatifs/services diverses autres données :

  • l’endpoint et le temps de réponse pour un appel de WS par exemple
  • l’ip de destination lors de l’appel d’un WS
  • le temps passé dans une fonction

Enfin, à noter que pour les applications en production, on centralise l’ensemble des logs de niveau INFO et supérieur.

1 « J'aime »

J’utilise https://papertrailapp.com pour chercher dans les logs “brutes”, on peut également mettre des alertes.

Mais le plus utile pour moi sont les outils de monitoring d’exceptions, me concernant j’utilise https://appsignal.com pour une app Ruby On Rails et j’en suis très satisfait ! On reçoit un mail dès qu’une exception est levée dans l’app, avec la stack-trace complète, tout le “state” de l’app au moment du crash, avec les paramètres, l’url, les données dans la session, IP, user-agent etc
Comme ça plus besoin de fouiller dans les logs pour retrouver la stack-trace: on sait quelle ligne exactement dans le code a fait planter l’app. Au final je me sert jamais des logs directement sauf au moment du déploiement de l’app, si celui-ci a planté.

On a aussi des graphiques pour mesurer les perfs par contrôleurs, ou la durée des requêtes SQL…
Si on relie notre compte Github, on peut voir les stats par deploy/commit pour ainsi voir quel commit à introduit le bug.

Il existe plusieurs outils de ce genre mais jamais eu de problème avec celui-ci.

1 « J'aime »
Human Coders - Le centre de formation recommandé par les développeur·se·s pour les développeur·se·s