Mise en place d'un serveur Sentry

Comme vous l'avez surement tous remarqué, on se bouffe des tonnes d'erreurs 500 sur le site. Pour cela je pense qu'il faudrait une solution de « monitoring d'erreurs ».

J'ai naturellement pensé à Sentry, solution que je suis en train de déployer à titre personnel mais également pour un projet plus pro/important.

Sentry kesako ?

« Sentry is a realtime, platform-agnostic error logging and aggregation platform ». Oui mais encore ? C'est une solution qui permet de capturer, trier et analyser des logs mais également de centraliser plusieurs projets (preprod et prod par exemple).

L'architecture repose sur du Python (ouf !) et du Django ! On la le choix du SQDB (merci Django) bien que « We highly recommend using PostgreSQL for your database, or MySQL if you have no other choice » (cc SpaceFox).

De plus, on a le droit à des plugins, notamment celui-ci qui peut vraiment nous intéresser.

Qu'est ce que le projet y gagne ?

Une trace des erreurs qui permet de comprendre et d'analyser facilement ce qui ce passe, avec des informations détaillés. Quoi de plus frustrant d'avoir tout le monde qui hurlent « Je prends des 500 » et d'être là avec un tail -f à essayer de comprendre ce qui se passe, et en définitive redémarrer le serveur web en priant. De plus, je doute que tous les utilisateurs du site reportent les 500.

Comment on met ça en place ?

Il existe 2 solutions :

• https://getsentry.com/welcome/, une solution hébergé. Un petit tour sur https://www.getsentry.com/pricing/ vous fera rapidement passer à la solution numéro 2.
• La seconde solution c'est d'héberger nous même notre serveur Sentry. Un petit tour sur https://pypi.python.org/pypi/sentry pour voir qu'il suffit d'un pip install sentry pour installer tout ça (bon OK faut le configurer après mais on a des sys-admin géniaux).

Et pour Django ?

Ça fonctionne très bien avec le client Python qui s'appelle Raven (http://raven.readthedocs.org/en/latest/config/django.html).

Et les alternatives ça donne quoi ?

• Airbrake avec https://github.com/airbrake/airbrake-django. Ça semble assez bien foutu. C'est en Ruby.
• Exceptional avec https://github.com/zacharyvoase/django-exceptional. C'est encore du Ruby.

Voilà, j'espère que ce topic pourra être utile et permettre la mise en place d'une de ces solutions.

Note : Quand je dis qu'il faut configurer Sentry, c'est relativement simple.

Je vais essayer d'installer ça sur mon serveur pour voir. Par contre, ce sera sur du MySQL

J'avoue : c'est complètement bidon à installer et configurer.

Comme ça marche en préprod, je profite du fait que ce soit la nuit pour l'installer aussi en prod.

Par contre, comme il y a 0 sécurité et contrôle d'accès dessus, et que c'est une version de test sur un serveur à moi, je ne donnerai pas l'adresse en public. Si ça vous intéresse, demandez-moi en MP

Edit : Et voilà ! Y'a plus qu'à espérer que ça marche et qu'on voie apparaître tous nos problèmes dedans demain matin !

SpaceFox : il y a un système de Team et d'auth non ?

En fait, je pensais qu'il était HS, mais c'est juste qu'il y a une subtilité :

Vous pouvez aller voir ici http://sentry.kisai.info/zeste-de-savoir/zds-prod/ et vous créer un compte. Ensuite, vous devez m'envoyer l'adresse mail du compte par MP pour que je puisse l'ajouter au projet (elle n'apparaît pas dans les listes et je ne suis pas mis au courant de la création du compte…)

J'en avais déjà entendu parler.

Mais est-ce-que ça n'agrège que les erreurs ? Ou est-ce-que ça peut "manger" des fichiers de logs http aussi ? Parcequ'il faudra inévitablement un jour faire la corrélation entre les deux :\

(style elasticsearch / Kibana)

On a l'URL qui a provoqué l'erreur dans les données, tout comme les informations de navigateur :

site = zestedesavoir.com level = error browser = Chrome 36.0.1985.125 os = Windows url = http://zdsappserver/tutoriels/recherche/79/

ou

site = zestedesavoir.com level = error browser = Chrome 34.0.1847.116 os = Linux url = http://zdsappserver/tutoriels/recherche/317/

Je ne nous le souhaite pas mais c'est pas impossible que ça ne suffise pas (je pense aux APIs notamment).

Y'a moyen de voir les headers de la requête HTTP, ce genre de choses ?

NB pour Sandhose et Alex-D : de mémoire Sentry propose une API pour logger des erreurs JS. A confirmer mais dans ce cas un :

1
2
3

window.onError = function(err){
  sendLogToSentry(err);
};

pourrait être une bonne idée (le jour où y'a du JS un peu avancé / sensible sur le site ça sera sans doute fort utile). Et de mémoire également, ça se comporte plutôt bien même dans le cas où le code est minifié (alors que souvent dans ce cas l'erreur est inexploitable).

J'ai vérifié, et on a toutes les données de la requête un peu plus bas dans la page (URL / Méthode / Paramètres / Cookies / En-têtes / Environnement serveur).

PS : et même des données de l'utilisateur Django s'il est connecté, dont l'adresse mail. Vous comprendrez que je donnerai pas les accès à n'importe qui !

OK c'est donc la solution idéale pour la gestion des erreurs.

Pour des stats "http pures" (pas les erreurs) par ex : combien d'appels au total sur quels URL ? combien de chargement de page depuis tel client API (agrégation sur User-Agent = 'application Android de ZdS' par exemple), on pourra s'en sortir avec Sentry ou faudra aller voir ailleurs ?

Javier : Sentry gère les erreurs de Python, pas du serveur web. On a des infos très détaillées sur les bugs et comment les reproduire.

J'ai vu des gens s'en servir pour du reporting d'erreurs tout autre que Python (je parlais de JS notamment), c'est pour ça que je me demandais s'il n'était pas capable d'avaler un peu n'importe quel type de fichiers de log si tant est que tu lui décrives comment le lire et ce qu'il doit en faire (à la manière du couple elasticsearch/Kibana).

Je critique pas du tout l'outil hein, mais c'est juste qu'un jour ou l'autre on aura nécessairement besoin d'analyser des logs http de manière avancée. Soit Sentry le permet d'une façon détournée (en lui faisant avaler des fichiers, en appelant des APIs, …) mais tu sembles penser que non, soit il va falloir se tourner vers un autre système de reporting pour les logs http pour les mêmes raisons qu'évoquées ici : tail -f ça fonctionne bien pendant un temps pour quelques personnes, puis quand les besoins évoluent il faut passer à autre chose.

J'attire juste l'attention là-dessus tant qu'on est au coeur des problématiques de logging.

EDIT : après ton edit. Je ne doute absolument pas que vous ayez toutes les infos en votre possession pour reproduire ou résoudre des bugs et je ne remets pas ça en cause du tout, (cf. "c'est l'outil idéal pour le reporting d'erreurs), je dis juste que le reporting de logs HTTP ça va servir un jour ou l'autre c'est absolument inévitable. Autant se poser la question aujourd'hui tant qu'on a la tête dedans et voir si Sentry est le mouton à 5 pattes, si oui : tant mieux, si non c'est pas grave il existe d'autres outils pour le faire.

Un simple tout sur https://getsentry.com/ et tu vas vite voir que Sentry supporte de très nombreux langages et frameworks. Tant qu'il y a un client qui balance des infos au serveur, pas de souci.

Pour quelles raisons on devrait analyser des logs http de manière avancée (vraie question) ?

J'en ai parlé plus haut : les clients API sont pour moi l'exemple le plus frappant.

par ex : un client complètement buggé qui te demande la liste de tous les messages du forum toutes les 200ms. Tu filtres sur le user-agent t'as vite trouvé le coupable.

Y'a les stats d'utilisation d'une API aussi, où tu vas filtrer sur le user-agent pour te rendre compte de la part d'utilisateur qui utilisent des versions dépréciées (de l'API ou du client). Y'a le fait d'essayer de tracer un parcours utilisateur type à l'aide du token API ça m'est arrivé. Bref, pas du debug, des stats.

Ensuite se donner des billes pour détecter des trucs louches comme l'utilisation suspecte du site ou obtenir rapidement des stats du style "combien de téléchargement de tutos de plus 500ko ?" etc.

J'ai parlé des logs http, mais c'est bien entendu pas les seuls (tu peux corréler avec des logs système, les logs de ton SGBD, … c'est d'autant plus efficace si tu as plusieurs machines).

PS : j'ai pas envie de verser dans le procès d'intention donc je me vexe pas pour l'instant mais molo hein "un simple tour sur". Doucement, j'ai jamais dit que Sentry était une mauvaise solution loin de là, je connais très mal cet outil et s'il permet de faire tout ce dont j'ai parlé c'est tant mieux. Et sinon c'est pas un drame, on en reparlera quand la question se posera.

J'ai rapporté les erreurs reproduites plusieurs fois dans Github. Le truc chiant c'est que 2 d'entre elles concernent l'interface avec Solr… pas facile à reproduire / déboguer.

On en a une qui n'est apparue qu'une seule fois, mais elle semble concerner un cas pathologique. A voir.

Hey SpaceFox, j'ai reçu un message de Sentry vers minuit concernant une erreur détectée par Sentry. C'est normal ?

Je sais pas, par contre je sais que j'ai paramétré correctement le serveur mail avant-hier. Il y a peut-être un lien

Coincidence… je ne pense pas !

Si d'ailleurs tu peux nous installer le plugin sentry-github ce serait génial