Exploitez vos logs sans douleur – Partie 1

Si vous avez déjà eu à développer et déployer une application, vous vous êtes forcement heurté au cycle suivant :

  1. Un utilisateur subit un bug
  2. L’utilisateur le remonte (dans le meilleur des cas)
  3. Vous essayer de reproduire le bug pour avoir des informations précises / Vous recherchez dans les milliers de lignes de logs des serveurs de production
  4. Vous corrigez le bug.
  5. Répéter

C’est un cycle assez long et fastidieux, encore plus quand, comme chez Alinto, vous n’êtes pas tout le temps directement en lien avec les utilisateurs finaux.

L’idéal serait de pouvoir récupérer les erreurs quand elle surviennent et regrouper toutes les erreurs du même type pour ne pas être débordé par un trop plein d’informations.

C’est exactement ce que fait Sentry, une plateforme de logging en temps réel et d’aggregation de logs avec une interface user-friendly.

L’application est développée en Django/Python, peut utiliser une base de données PostgreSQL ou MySQL, un buffer Redis (via Celery), un cache Memcached, ce qui lui permet d’encaisser la charge dans le cas de grosses applications.

Des clients sont disponibles pour les technologies suivantes:

  • Python
  • Django
  • Java
  • Ruby
  • Objective-C
  • PHP
  • Go
  • JavaScript
  • NodeJS
  • Swift
  • Chef
  • C#
  • R
  • ActionScript 3
  • Android
  • CFML
  • Erlang
  • Grails
  • Server-Side ActionScript

Ils sont extrêmement facile à intégrer à un projet déjà existant.

Voici à quoi ressemble l’écran principal :

 

sentry_logs

Et la page détaillant un évènement :

sentry_event

La vue principale de Sentry (appelée « Flux ») va s’occuper de regrouper toutes les erreurs identiques, et le nombre de fois qu’elle à été rencontrée par les utilisateurs (indiqué sur des pastilles de couleurs bleues, oranges et rouges afin de rapidement voir l’importance de l’erreur), tout en permettant de les filtrer via différents critères comme le serveur, l’OS, le navigateur, l’importance, …

Le détail de chaque erreur nous indique quand l’erreur à été vue pour la première fois, ainsi que la stacktrace associée ainsi que des info complémentaires sur le client qui l’a déclenchée. On nous offre également la possibilité de rejouer la requête, ce qui est très utile pour développer un correctif et tester celui-ci.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *