Mise en place d'un serveur Sentry

Parce que les 500, c'est pas très très rigolo

L'auteur de ce sujet a trouvé une solution à son problème.
Staff
Auteur du sujet

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 :

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 ?

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.

Édité par gustavi

"I think that it’s extraordinarily important that we in computer science keep fun in computing." – Alan J. Perlis

+0 -0
Staff

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 !

Édité par SpaceFox

Staff

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)

Happiness is a warm puppy

+0 -0
Staff

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/

Édité par SpaceFox

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).

Édité par Javier

Happiness is a warm puppy

+0 -0
Staff

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 !

Édité par SpaceFox

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 ?

Happiness is a warm puppy

+0 -0
Staff
Auteur du sujet

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.

Édité par gustavi

"I think that it’s extraordinarily important that we in computer science keep fun in computing." – Alan J. Perlis

+0 -0

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.

Édité par Javier

Happiness is a warm puppy

+0 -0
Staff
Auteur du sujet

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) ?

"I think that it’s extraordinarily important that we in computer science keep fun in computing." – Alan J. Perlis

+0 -0

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.

Édité par Javier

Happiness is a warm puppy

+0 -0
Staff

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.

Staff
Auteur du sujet

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

"I think that it’s extraordinarily important that we in computer science keep fun in computing." – Alan J. Perlis

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte