Bonjour à tous, bienvenue sur ce nouvel épisode de WSLash.
Bienvenue, nous sommes sur un épisode spécial où on va parler de logger les data, logger
tout ce qui se passe au niveau de votre application sur le SERV, etc.
Comme d'habitude, nous sommes avec Alex.
Salut Alex.
Salut Patrick, salut tout le monde.
Et oui, l'art de logger c'est venir enregistrer tout ce qui se passe sur nos applicatifs et
on se rend compte qu'on peut très vite enregistrer beaucoup de data.
Et juste avant de commencer avec l'épisode, on s'est exprimé sur le sujet et avec Patrick,
on a peut-être deux points de vue un peu divergents.
Mais je pense qu'on est d'accord pour dire qu'en termes de log, il ne faut pas faire
n'importe quoi.
Alors pour mon point de vue au niveau des logs, évidemment c'est très utile.
Il faut logger des choses.
De toute façon, on a des logs quand tu utilises des services, tout ça.
Automatiquement des logs, même sur Apache, n'importe quoi.
PHP, tout ça, tu as toujours des logs.
Il y a un mot où je suis allergique, c'est observabilité qui est utilisée à Outrance
en fait et c'est marketing, data.dog et tout ça.
On l'utilise à bloc.
On ne parle que d'observabilité.
Pour moi ce que ça représente, c'est beaucoup de data.
C'est un peu comme Google Analytics.
Les gens prennent plein de data mais ils n'en font quasiment rien.
C'est juste pour voir le nombre de visites.
Là on est dans le même truc.
Tu as trouvé énormément de data.
En plus ça fait beaucoup de data suivant ce que tu logues.
Tu vas stocker beaucoup.
Si derrière, tu n'en fais rien, c'est un peu dommage de mettre tout ça, de loger
tout ce que tu veux et finalement ça ne sert à rien.
D'autant que plus que oui, il faut loguer, etc.
Pour voir s'il y a des problèmes, des erreurs, tout ça.
Sur des gros applications avec du trafic, avec beaucoup de trafic,
ça peut être utile aussi pour déceler des problèmes des économies de serveurs
qu'on peut faire, des choses comme ça.
Je suis un peu sceptique sur le log à Outrance.
Ce que je te propose justement, c'est...
Tu vas me faire changer d'avis.
Non, pas du tout.
Le but, c'est pas de te faire changer d'avis.
L'idée, c'est de bien comprendre toutes les catégories de log qu'il y a
et de bien comprendre qu'est-ce qu'on va loguer, à quel moment, dans quel contexte
et quelle est la valeur qui amène de l'information.
Parce que, comme tu dis, si on enregistre tout, c'est super bien,
mais qu'est-ce qu'on va en faire ?
Autant, aller récupérer de l'information qui amène de la valeur.
Donc, déjà, on pourrait déjà commencer par logger.
En fait, on pourrait expliquer.
Le concept, c'est de tout enregistrer des informations.
C'est comme si on avait un énorme registre de toutes les informations
qui rentrent dans notre application, serveurs, on va le voir, et on enregistre tout.
Donc, évidemment, toutes ces informations, en fait, elles vont être plutôt côté serveurs.
Même si, je ne sais pas si tu te rappelles, t'as connu à l'époque
ou sur le front, en fait, l'hébergement des applications frontes,
type Netlify ou chez Versailles, à l'époque où ça s'appelait Now,
on n'avait pas accès au log. T'as connu ça ?
J'ai connu, sûrement, mais je me souviens plus.
En fait, le gros sujet à l'époque, c'était que tu ne pouvais pas...
T'avais pas accès au log, donc tu pouvais pas avoir ce qui se passait sur ton appli.
Et donc, c'était un peu la merde. Et quand ils ont commencé à faire du SSR,
tout de suite, ces grosses plateformes, on m'a dit que ça serait peut-être pas mal de faire du log.
Donc, ce qui est sûr, c'est plutôt côté serveurs, côté backend.
Après, sur des apps frontes, on est beaucoup à utiliser CNTRI,
qui va logger tout ce qui sort dans la console du browser.
Exactement. Et ce que je te propose, c'est de commencer par
à quel moment on va logger, à quel niveau d'abstraction on va pouvoir commencer à logger.
On peut avoir différents niveaux de log, et ça va intervenir à différents moments.
On peut, comme tu l'as dit, le faire directement sur l'applicatif.
Donc, ça veut dire que c'est dans notre codebase, là on va pouvoir injecter le fameux console log
ou print ou c'est quoi, c'est Vardum par en PHP.
Ouais, c'est ça.
Donc, tu vas avoir des librairies de logger, sauf que là, en fait, on est au sein de l'application.
Donc, soit on va utiliser un middleware ou quelque chose comme ça, mais au sein de notre application.
Ce qui fait que la requête, l'information a déjà traversé, en fait,
tout le côté machine.
Donc, ce qu'on peut faire, c'est aussi logger côté machine.
Et par exemple, je pense, au reverse proxy maintenant, en fait, ils peuvent aussi logger.
Je pense à Trifik par exemple, ou NGNX, KD, tout ça.
On peut avoir des logs.
Ou, en fait, on peut avoir, si on utilise un pass, donc un plateforme as a service,
genre hero-coup, render ou tout ça, en fait, ils peuvent avoir un log directement
où là, on va pouvoir écouter toutes les requêtes qui rentrent.
Et l'avantage, c'est qu'elles vont être en amont, en fait, de notre applicatif.
Donc, on va avoir plus d'information sur ce qui s'est passé.
Et on peut aussi remonter d'un niveau d'abstraction et on peut même se brancher directement
sur la machine si on a un VPS.
En fait, on peut mettre une surcouche pour enregistrer tout ce qui rentre là-dedans.
Et en fait, on va pouvoir écouter.
Donc, il faut bien comprendre les trois niveaux de logs qu'on peut avoir, soit l'applicatif,
soit au niveau instance, soit au niveau plateforme, soit au point de vue vraiment hardware,
où là, en fait, on va avoir les trois niveaux.
La plupart du temps, Kady, NGNX, tout ça, ils ont déjà des fichiers de logs qui enregistrent automatiquement.
Et c'est vrai que si tu commences à enregistrer tout ce qui est trafic,
réponse tout ça, ça va vite.
Tu vas défiler si tu regardes en live.
Oui, ça va.
Et non, parce que le moindre truc, en fait, même le faficon, il passe dedans.
Exactement.
Exactement.
Et c'est pour ça, en fait, que des systèmes comme Qulify, qu'on a parlé,
en fait, qu'il y a un plateforme As-de-Service qu'on va pouvoir self-hoster sur notre propre machine,
en fait, à des systèmes où tu peux venir écouter tout ce qui rentre dans ton applicatif.
Donc ça, c'est plutôt sympa.
Pareil chez Versel, ils vont avoir une solution pour pouvoir, ce qu'ils appellent des log drain.
Et ça, en fait, on va pouvoir écouter.
Par contre, comme tu le dis, en fait, qu'est-ce qu'il faut écouter ?
Et c'est là, en fait, on rentre en bascule dans la partie un peu « quoi », qu'est-ce qu'on va écouter ?
Et effectivement, est-ce que le faficon est intéressant ?
Le premier niveau, en fait, ce qu'on pourrait dire, c'est, en fait, tout simplement,
l'accès à la machine.
Quel IP est venu sur notre serveur ?
Donc on va souvent voir, en fait, la méthode qui est utilisée, si c'est un guide, si c'est un poste,
toutes les informations de la requête, c'est souvent ce qu'on va utiliser pour les analytics.
On va voir la route aussi qui a été utilisée.
Ça, on pourrait dire que c'est les logs, en fait, d'accès.
Et c'est ce qui est utilisé par les analytics pour, justement, nous donner des informations.
Donc là, en fait, plus on est remonté au côté machine, plus c'est intéressant.
Et c'est pour ça, en fait, que, par exemple, Versel, ils ont mis en place un système d'analytics
parce que quantise host, en fait, l'application, pour eux, c'est beaucoup plus facile de venir enregistrer toutes ces requêtes-là.
Même si on a un petit fichier à mettre sur notre applicatif à nous, en fait, il est branché sur leur infrastructure.
Et donc beaucoup plus facile parce qu'ils écoutent les requêtes en amont, en fait.
Ouais, c'est ça.
Enfin, exemple aussi, Scalingo, là, les bergers français.
On a aussi une interface où tu as les logs en live, ça te peut vérifier.
Et après, tu peux remonter dans l'historique tout ça.
Et Persos, ce qui nous intéresse beaucoup, tu vois, par exemple, c'est les erreurs 500 qu'on peut avoir au côté serveur,
surtout sur du Next, où tu peux avoir une erreur 500 au niveau de la génération de page.
Et en fait, finalement, si tu ne vas pas vérifier les logs, tu ne sauras jamais qu'il y a une erreur 500,
parce que c'est le client qu'il a eu et toi, tu ne sais pas, en fait.
Exactement.
Exactement.
Et donc là, comment tu fais pour lever, en fait, ton exception, pour être notifié de ton exception ?
Ça, c'est hyper important d'avoir ce genre d'information.
Et c'est là, en fait, où potentiellement, on va avoir des solutions qui sont plutôt sympas type sentry,
je ne sais pas si t'as déjà mis ça en place ou pas.
Ah oui, bien sûr.
Ah oui, c'est le truc à mettre en place.
Quand tu fais du front, tu es...
Et pour le coup, mais même sur du back, même sur du Next, ça peut être super sympa,
parce qu'en fait, on va avoir une remontée d'informations.
Ok, j'ai eu une erreur sur telle root et on verra même par la suite qu'il y a beaucoup, beaucoup, beaucoup plus d'utilité que ça.
Sentry, pour l'exemple, toi, pour les applications frontes, alors après, il y a d'autres services que sentry,
je ne sais pas si t'en avais trouvé, enfin je ne les connais pas tous, mais sentry c'est le plus connu
et c'est vrai que sur une application fronte, des erreurs qui remontent dans le navigateur,
si tu n'utilises pas sentry, tu ne pourras jamais les voir, en fait, tu n'auras jamais connaissance
et c'est un super outil.
Du coup, après, tu peux t'amuser à essayer de les...
Alors, ça va vite, t'as beaucoup d'erreurs.
Et des fois, c'est des duplicates, donc tu peux les dépliquer tout ça,
mais après, tu peux t'amuser à essayer de trouver les erreurs et de les corriger dans ton app,
mais waouh, c'est presque sans fin en fait, surtout sur les grosses app.
C'est complètement ça, mais tu vois, écouter les erreurs, c'est hyper intéressant.
Leurer des erreurs, les stocker et si tu n'as pas ça, en fait, si tu n'écoutes pas,
tu ne peux pas entendre sur quoi tu ne prêtes pas attention.
Donc, c'est hyper, hyper important.
Pour le coup, sentry, il y a une offre free, pour ceux qui écoutent l'épisode ou qui regardent la vidéo.
Sentry, il y a une offre free, donc l'accès est quand même facile.
Après, c'est limité dans le nombre de requêtes par jour,
mais sur une petite app, tu peux l'installer sans rien payer et ça marche.
Pour le coup, la majorité des solutions qu'on va présenter aujourd'hui ont des fritières assez généreux
et on peut largement les utiliser sans pour autant craquer le budget,
ce qui nous permet aussi de pouvoir tester sans pouvoir casser sa tire lien.
Autre point, on va pouvoir aussi loguer tout ce qui est authentification
et voir si on a des 401, c'est intéressant de loguer ça.
Pour voir aussi si on n'est pas en train de se faire brute-forcer,
je pense à la mise en place d'un rate limite,
si on ne écoute pas ce qui se passe, ça va être difficile à optimiser.
Évidemment, c'est quelque chose qu'on n'a pas dit,
mais le but d'enregistrer et de loguer,
ça va être d'affiner son efficience, de réparer les bugs,
de voir ce qu'on ne sait pas.
C'est toujours dans un souci d'amélioration.
Il y a un autre truc aussi, je ne sais pas si toi tu utilises ça,
c'est dans la catégorie un peu monitoring,
où on vient écouter ce qui se passe dans l'application
pour voir si elle répond et si elle est tout le temps up.
C'est un ping, on va voir si elle est tombée ou pas.
Oui, ça j'utilise.
Et ça, c'est des choses qui marchent plutôt bien.
On va avoir plein de solutions, je pense à Uptime Robot,
mais il y a Better Stack,
mais plein de solutions open source qui marchent plutôt bien.
L'idée, c'est d'aller enregistrer et de faire un ping sur ton application
ou sur une page spécifique ou sur un endpoint,
et de vérifier que la réponse correspond bien.
On va monitorer l'application pour être sûr qu'elle est up,
et si elle est down, potentiellement on va avoir une notification
soit sur mon téléphone, soit sur un email ou que sais-je.
C'est pour générer, pour vérifier que tout fonctionne correctement.
C'est dans la grande famille du monitoring.
Mais ça, ça va être du log.
Pour moi, on enregistre des données,
donc il faut aller directement sur ce type de service-là.
Ça, c'est quasiment indispensable.
C'est pour éviter que ton client t'appelle pour dire que le site ne marche plus,
que tu le vois avant lui.
Exactement.
Et commercialement, quand tu le notifies qu'il y a un problème sur son site,
que son site est down,
et tu le notifies comme quoi tu as réparé et c'est en place,
souvent, lui, il n'a pas eu le temps de répondre,
donc il voit le mail comme quoi c'est par terre,
le mail comme quoi c'est réparé,
commercialement, c'est super intéressant
et c'est plutôt très appréciable
et apprécié pour le client
d'avoir mis ça en place,
parce que tu vois que t'es proactif
et donc quand tu vends de l'hébergement,
ou du support, ou de la maintenance,
et où ça peut amener une grande, grande, grande valeur.
Et tu vois, moi j'utilise en self-hostage,
je sais plus, t'as mis le robot, je sais plus.
Donc j'ai plein de sites branchés et tout ça
et c'est là où je me suis rendu compte que les ébergements
et multi-provider infomagniaques, OVH, n'importe quoi,
et en fait, ils ont tendance à souvent ne pas répondre.
Il y a des trous dans la journée,
pendant cinq minutes, le site ne va plus répondre
et ça revient et ça repart et c'est hyper variable.
Et là tu te rends compte qu'en fait,
le serveur ne répond pas 100% du temps
ou même 99% du temps,
il y a beaucoup de moments où il ne répond pas.
Oui, et si tu mets pas ça, t'en as pas conscience en fait.
Tu crois que le site marche toujours et en fait non.
À des moments dans la journée, pendant deux, trois minutes,
il marche plus pas.
Alors c'est pas peut-être qu'ils sont en train de changer
le serveur ou de, je sais pas,
mais c'est assez fou en fait,
de voir que les ébergements, en fait,
il n'y a des moments où il raconte plus.
Et c'est là où ça fait peur.
Un autre point aussi sur lequel ça peut être intéressant,
en fait, c'est d'enregistrer les informations de mises-ajour.
Je m'explique, par exemple,
quand on envoie en fait un client sur son site internet,
il envoie une information,
potentiellement j'ai prendre une requête assez simple,
HTTP en poste, il vient envoyer un payload.
Ce payload là, en fait,
avant d'être traité, potentiellement,
il y a des personnes qui, et j'ai vu ça,
qui enregistrent le payload et qui logent le payload
pour être sûr en fait de pouvoir le rejouer
et de récupérer le payload.
Ça fait exploser les logs.
Après, on verra comment on stock
et comment on peut optimiser ces logs-là.
Mais sur tout ce qui est création, suppression, mises-ajour,
il y a des personnes qui sont complètement parano.
Par contre, le seul bémol à ça,
c'est que si la requête n'arrive pas à l'applicatif,
c'est trop tard.
Donc tu l'as perdu.
Donc ça, c'est davantage et c'est inconvénient.
Après, peut-être, il faut réfléchir
à un autre système d'architecture.
Je pense à des solutions type Stream, Broker, Kafka,
ou des choses comme ça,
où en fait, le front aimait un événement
et cet événement est enregistré
et traité par le bac quand il a le temps.
Si, par exemple, pour éviter une saturation,
si le serveur est down, parce qu'il est saturé de travail,
la nouvelle requête ne va pas être pris en compte.
Et dans ce cas-là, tout le payload qui a été envoyé
sur cette requête ne sera pas digéré.
Pour pas lier à ça, il faut revoir l'architecture
et passer sur des events, des développements,
ou des choses comme ça,
où on envoie un événement et on vient enregistrer cet événement.
Néanmoins, une solution, ça peut être d'enregistrer un payload.
Pour le coup, j'ai fait ça pendant une période donnée
sur un environnement de staging
pour voir ce qui arrivait.
Pour le coup, je contrôlais la rentrée,
parce qu'il y avait qu'une seule personne
et un seul service qui m'envoyait la donnée.
On m'affirmait que la donnée était juste.
Moi, je recevais la donnée qui était fausse
et je me suis mis à logger tout ce qui rentrait
pour prouver qu'A plus B, ça ne marchait pas.
Ça a été compliqué,
mais ça peut être une bonne solution pour mettre fin au débat.
Oui, on pense aux sites de réservation de billets
ou des choses comme ça,
qui peuvent être très vite saturées,
où les gens refraîchent, refraîchent, refraîchent.
Et puis, des trucs qui ne arrivent pas au serveur.
Après, je pense que sur des systèmes comme ça,
ils sont sur une archi event-driven.
C'est sûr.
L'inscription à l'ITMB, par exemple.
Il devait être là-dessus.
On est complètement d'accord.
Un autre point sur lequel on peut logger,
c'est directement sur l'ADB.
Je ne sais pas si tu es au courant
que tu peux faire l'équivalent de ton Vardump dans ta DB.
Je ne sais pas.
Tu m'apprends essentiellement sur Postgres
ou sur les services d'Ottawa.
Oui, tu peux afficher des informations.
Par contre, ça va être compliqué.
Une autre possibilité,
c'est de récupérer les fichiers YAL.
Je ne sais pas si tu te rappelles.
Les fichiers YAL,
j'ai pu le terme exact de la signification de YAL.
Mais en fait, c'est toutes les transactions
qui sont écrées dans une sorte de registre.
C'est ce que c'est Write I'd Log.
Les fichiers YAL.
Ces fichiers YAL écrivent toutes les informations
qui sont envoyées à la DB.
C'est comme ça que les nouveaux services,
type PlanetScale ou NeonDB,
font pour créer du data branching.
On en avait parlé dans un épisode, je ne sais pas si tu te rappelles.
Sur les DB, comme dans Git,
on va faire des branches avec notre code.
Ces services-là vont faire exactement la même chose avec les DB.
Et c'est grâce à ce fichier Log, les YAL,
les Write I'd Log,
qui vont pouvoir reconstruire ces branches
et pouvoir faire du retour en arrière,
naviguer dans le temps.
C'est une version des Log qui est utilisée
pour concevoir ce type de feature-là.
Ça stocke toutes les requêtes,
tout ça qui a été joué, en gros.
Exactement.
Et après, tu peux faire la reverse avec tout ce que tu as.
Après, je ne connais pas.
En fait, je ne suis pas très bon.
Moi non plus, je ne suis pas bon.
Mais c'est une DB...
Je pense que tu es de l'argement meilleur que moi.
Je l'ai vraiment poncé le truc.
Je suis de plus en plus fan de Postgre,
parce que tu peux faire beaucoup de choses.
C'est très puissant.
Carrément.
Un autre truc quand tu parles de puissance,
c'est le terme que tu n'aimes pas,
qui est l'observabilité.
Vas-y.
On est obligés d'en parler.
Neurilic.
Et donc là, on va avoir plein de services.
Je pense à Datadog.
Ils ne font pas que ça, mais Neurilic.
Et tous ces plateformes qui font un petit peu tout ce qu'on vient de dire
sur le Log.
Mais en fait, eux, ils vont juste regarder,
en tout cas, ils vont te donner les outils
pour te donner et calculer un temps de réponse.
Ils vont parfois regarder et monitorer ta machine.
Donc ils vont calculer ta charge de CPU
ou de ton GPU, parce que maintenant, on fait d'ILA,
donc à combien ils tournent,
combien ils croquent de mémoire vive.
C'est tout l'écosystème d'observabilité.
On va avoir souvent aussi des outils
qui s'appellent Grafana.
On va utiliser Grafana pour afficher les informations.
Donc il y a des couplages entre Prometheus et Grafana pour afficher.
Tout simplement, la plupart du temps,
c'est des bases de données optimisées avec des time series
qui vont vraiment pouvoir afficher des informations
à la nanosecondes.
Je crois que c'est le plus petit élément.
Si je ne dis pas de connerie, je demande à me faire fact checker.
Mais pour le coup, tout cet écosystème va nous permettre
de pouvoir monitorer la consommation d'une machine
ou d'un service, ou d'un pod, d'un docker,
d'une instance de manière générale.
Ça peut être intéressant pour voir la consommation
de la machine ou du service.
Il faut provisionner plus de mémoire vive ou de CPU
parce qu'il croque plus que nécessaire
quand on héberge soi-même ces machines.
Avoir ces informations-là, ça amène beaucoup de valeur.
Évidemment, quand on est sur des passes,
on clique sur autoscale et ça monte tout seul.
C'est le provider Eroku ou quelqu'un d'autre,
ou Scalingo, qui va nous provisionner la machine pour nous.
Ça va nous enlever beaucoup de problèmes.
Néanmoins, si on commence à avoir des applications
un petit peu plus solides avec une équipe,
on va très vite passer sur d'autres systèmes d'hébergement.
On vous invite à écouter l'épisode
sur les différents types d'hébergement.
Mais dès qu'on va hoster et héberger nous-mêmes nos applications,
mesurer ce type de performance va devenir indispensable
pour calibrer la bonne machine
ou en tout cas l'allocation de la puissance
sur telle ou telle instance.
C'est un service qui tourne fort,
qui a plusieurs machines.
C'est aussi des potentiels économiques que tu pourrais faire
en réglant certains problèmes
pour peut-être ta trop de consommation de machines
par rapport au nombre de trafics.
Il y a plein de trucs que tu peux déceler,
parce que ça va vite après quand tu as des machines chez AWS.
Des grosses boîtes peuvent te témoigner.
Oui, c'est clairement un problème.
Quand tu parles de AWS,
ça m'amène sur le fait de réfléchir
sur le fait que où tu vas logger
et où est-ce que tu vas enregistrer tes informations ?
Oui, on va logger où alors ?
Où est-ce que je vais logger ?
En fait, tu es d'accord que tu peux logger directement sur ta machine.
Ça, ça passe si tu héberges toi-même.
Tu vas la remplir un peu, non ?
Par contre, potentiellement, si ta machine crache,
tu as perdu tes logs.
Aussi.
Et donc, est-ce que tes logs sont persistants ?
C'est-à-dire, est-ce que tu les écris en mode fichier
et donc, ils sont écrit sur le disque ?
Est-ce qu'ils sont sur la même machine
ou ils sont sur une autre machine ?
Et donc, dans ce cas-là, il faut les transporter.
Et donc, ça amène aussi
tout ce layer un peu de sécurité
où quand tu vas te transporter d'une machine à l'autre,
il faut que la connexion entre ces deux machines soit propre,
soit sécurisée et un autre point aussi,
c'est à qui tu vas donner accès à cette machine
pour lire les logs.
Parce que si tu as une machine qui tombe,
c'est super pratique d'aller voir
l'endroit où tu les as logués,
potentiellement sur une autre machine
pour voir l'historique et qu'est-ce qui s'est passé
pour aller en fait récupérer ces informations-là.
Donc, se pose aussi la question, évidemment,
est-ce que tu les logues aux US, en Europe,
à savoir que si tu passes par des services tiers,
la législation est différente,
l'Europe nous impose de la rétention d'information
pendant un certain nombre de jours minimum.
Les US, c'est différent,
tu n'as pas le droit de loguer la même chose,
hashtag RGPD, HP, je ne sais pas quoi,
l'équivalent aux États-Unis en tout cas.
Tout ça, en fait, c'est vraiment spécifique.
Il y a aussi des données qui sont propres à l'industrie.
Par exemple, je pense que si vous êtes dans un corps médical,
vous n'allez pas pouvoir loguer des informations
médicales spécifiques à la personne
ou dans le milieu bancaire.
Vous avez un niveau de législation
qui est un peu plus différent
sur le coeur de business.
Là, pour le coup, c'est à vous de vous renseigner
sur qu'est-ce que vous avez le droit de faire,
qu'est-ce que vous n'avez pas le droit de faire.
Après, si vous le faites, ok,
est-ce que vous êtes pénalement responsable ?
Ça après, c'est un peu autre chose.
Si, en cas de suite de données,
vous êtes complètement responsable.
C'est vrai que c'est bien de soulever ce point,
parce que entre les US,
vous avez les données de santé,
vous avez de l'anonymiser, etc.
C'est là où je commence à loguer
toutes les informations qui sont rentrées,
et que ça passe par les US.
T'es un petit peu mal si jamais il y a une fuite de données.
Security, security, security.
Mais un important...
Oui, un important.
Après, j'imagine que les gros services
Datadoc, tout ça,
ont déjà certainement des serveurs en Europe
et ils doivent prendre en compte ce truc.
Après, ces services sont quand même assez onéreux.
Oui.
Et pour le coup, dans la majorité des cas,
quand on arrive sur ces types de services,
si on veut les utiliser en mode SaaS,
il a demandé très clair
dès l'inscription,
on nous demande si notre organisation
ou notre projet va être hébergée
aux États-Unis ou en France,
ou en Europe, pardon.
Et comme ça, il y a déjà une distinction,
parce que je pense, je ne sais pas ce qui se passe derrière,
mais en tout cas,
la distinction se fait immédiatement à l'inscription.
Comme quoi, c'est important.
Super important.
Autre point,
il y a différents types de fichiers
sur les logs.
Je pense le plus connu, c'est le format Gison.
Gison, qu'on va trouver partout,
qui est le plus facilement
admis partout.
Néanmoins, si on est sur des machines,
on va des machines Linux
ou Linux, on va avoir
des fichiers Syslog.
Et après,
il y a d'autres formats que je ne connaissais pas.
Je ne sais pas si toi, tu connaissais
les Common Event Formats, les CIF
et les CLF, les Common Log Format.
CLF, j'ai déjà vu, je crois.
Format classique des services.
Oui, c'est ça.
CELF, ça va être sur tout ce qui est à page, tout ça.
Mais après, CELF, non, je ne connais pas le nom.
Pour le coup,
on est d'accord que la plupart du temps,
ça va être soit du Syslog,
soit du format Gison,
et ça va être plus intéressant
pour aller le requetter.
Après, on arrive
sur la phase où, ok,
on a enregistré,
on a enregistré des informations
sur notre potentiel
applicatif,
serveur,
service, whatever.
Par contre,
potentiellement, on l'a enregistré
et maintenant, comment on va faire
pour le parcourir,
pour aller remonter l'histoire.
Parce que le but d'enregistrer, c'est bien,
mais si c'est enregistré pour enregistrer,
il faut en extraire la donnée.
Et là, en fait,
se pose toute la question
de comment on requête
de la donner
sur des énormes fichiers
ou sur des énormes database.
Et c'est là, en fait,
où le type de format
sur lequel on est venu enregistrer
et sur quel type
de service,
la plupart du temps,
on va enregistrer ces informations-là
dans des DB qui sont vraiment
optimisées.
Et maintenant, on va pouvoir faire
du SQL
directement sur ces données-là,
parce que c'est du format Json
et donc on va pouvoir parcourir
cette DB-là.
Néanmoins, si on veut faire
du log que sur
des syslogs, moi, j'ai vu des gars
faire du grep,
tu vois,
directement,
au sein du serveur
il se connecte, il parcourt tous les fichiers
et
avec un niveau
de vitesse et d'efficience
impressionnant. Et que avec du grep
avec les commandes
qui vont bien, il maîtrise ça
parfaitement.
Et au final, c'est là où tu te dis
« Waouh, les nouveaux services,
c'est cool ! »
Mais là, c'est
juste une commande dans le terminal
et tu peux faire beaucoup,
beaucoup, beaucoup.
Et donc,
tu reviens et tu prends un petit peu d'humidité
et tu dis « Ouais, au final,
le grep, il est un peu pété,
mais il fait le boulot, quoi. Il fait le boulot.
Ouais, un bon petit barbu
qui maîtrise la console, ça marche.
Le bon...
Ouais, Patrick, le bon vieux cliché du DevOps.
Mais ouais, bien sûr,
souvent, en fait, c'est
les DevOps qui vont aller
se mettre le nez là-dedans
et qui vont en fait, avoir
cette faculté d'aller parcourir des logs
très rapidement, très volumineux
avec les bonnes commandes, ils vont trouver
l'erreur assez facilement
ou les informations qu'on leur demande,
quoi. Donc ça,
c'est plutôt intéressant.
Néanmoins, je suis obligé
de parler d'un service,
parce que moi, perso, je suis complètement fan
qui s'appelle Axiom
qui en fait, a pour but
d'enregistrer
toutes les données
et on va pouvoir
en fait, brancher
directement son applicatif
et derrière, en fait, on va avoir
un SQL like
et on va pouvoir
en fait, faire des queries
et ça va aller
en fait, directement
parcer tous les champs
et on peut aller
comme ça, en fait, monitorer
et donc on peut créer des dashboards
et donc on va s'en servir à la fois pour
identifier les erreurs
mais aussi pour donner de l'intelligence
métier, par exemple
si on veut envoyer de l'information
de dire ok
combien j'ai fait de chiffres d'affaires
ce mois-ci, en fait
si on a logué le montant de la transaction
on va pouvoir en fait, venir
agglomérer toutes ces données
et pouvoir faire des dashboards
avec lesquels on va pouvoir
envoyer des droits en lecture
aux personnes concernées
et c'est là en fait, où on bascule
non plus dans du logging un peu
basique machine
on va dire technique
mais on bascule en fait, dans du
du traitement d'événement
ou du log
d'information métier
pour le marketing
pour le commerce
en tout cas pour le
le domaine de métier spécifique
et ces types de services
maintenant en fait nous permettent
d'envoyer des événements spécifiques
avec un pélode spécifique
et ça amène
beaucoup beaucoup de valeur
parce qu'en fait on va pouvoir traiter
ces informations-là, faire des
dashboards qui vont bien
pour une somme
complètement dérisoire
et pour nous développeurs
on va pouvoir requêter ces informations
avec un SQL like
parce que c'est enregistré dans une DB
qui est optimisée
souvent en fait ces
click house ou duck DB
ou des choses comme ça
c'est des DB
qui sont orientés colonne
et donc en fait on va parcourir le champ
par exemple
dans une transaction
d'une commande on va avoir un champ
qui s'appelle amount et on va pouvoir
traverser
en fait tous les champs amount
très très très rapidement
et donc c'est pour ça que pour faire de l'agrégation
de donner sur des terra
on va avoir
des latences en fait très très faibles
parce que c'est du
A à la DB qui est vraiment vraiment
vraiment spécifique et donc ça en fait
c'est hyper intéressant
parce que ça va
en tout cas moi de mon
expérience je vais pouvoir
enregistrer à la fois les données techniques
c'est à dire est ce qu'il y a eu des craches
est ce qu'il y a eu des requêtes qui n'ont pas abouti
donc toutes ces informations
techniques mais je vais pouvoir
mettre aussi une surcouche
métier où je vais pouvoir enregistrer
de la données qui amène
de la valeur pour mon client final
et lui donner en fait un dashboard
propre designé au sein
du même outil ce qui m'évite d'avoir 2 outils
et ça en fait je trouve ça
vachement vachement bien
ça permet aussi de donner peut-être accès au log
à des personnes pas forcément techniques
tu vois sur un outil après
faire des requêtes SQL ça mais après je sais pas
si peut-être ça garde dans les mémoires les requêtes
ou juste comme ça pour en expliquant
oui oui en fait ça va
là pour ceux qui nous voient
la vidéo en fait on voit
typiquement la
la démonstration en fait
tu vas soit avoir
leur propre query mais tu vas pouvoir
en fait voir la donnée brut
que t'as envoyé
et tu vas après
pouvoir la transformer comme tu veux
l'idée en fait souvent c'est
d'enregistrer la donnée brut
et comme ça après tu la traites
et tu la filtres
et comme on disait
plus tu viens capter
de la donnée le plus haut possible
au niveau d'abstraction
le plus haut
le plus proche machine
et bah en fait on aura
une donnée beaucoup plus précise
et beaucoup plus juste
et potentiellement
après on pourra la finir
pour justement traiter et donner
plus de valeur au métier
et comment ça fonctionne
comme tu branches par exemple
sur une application
par exemple sur une application NUXT
tu vas rajouter
un module et puis après
tu vas pouvoir logger
c'est automatique ou c'est à toi de logger
avec une commande
ça va dépendre
tu vas pouvoir
ils ont développé beaucoup de
de fonctionnalité
ou en fait tu vas pouvoir brancher
directement sur ton opérateur
par exemple Axiom
tu vas pouvoir le brancher directement sur Netlify
sur Vercel
donc en fait
tu as plein de modules
qui sont déjà prêts à l'emploi
et sur lesquels tu vas pouvoir te brancher directement
autre point aussi
sur par exemple Coolify
ton log drain de ton instance
tu vas pouvoir l'envoyer
directement sur Axiom
ce qui fait que
toutes les requêtes
qui rentrent dans ton trafic
tu les log directement
et tu les envoies à Axiom
ce qui fait que dans Axiom
en fait t'es venu créer un data set
qui correspond à ton instance
et donc dans ce cas là
après tu vas pouvoir enregistrer
ok tu me filtres toutes
les données qui sont
en 200
en 500 en 401
tu peux faire ça comme dashboard
après tu peux donc ça c'est pour
les requêtes
ça c'est au niveau machine
par contre si tu veux loguer
des informations dans ton applicatif
moi ce que je fais
est ce que c'est la bonne pratique
je n'en sais rien du tout mais mon retour d'expérience
c'est tout ce qui est
donner analytics
machine je le fais depuis
trafic et tout ce qui est
métier je le fais depuis mon applicatif
en clair dans mon applicatif
je fais un envoi
spécifique
à Axiom de la transaction
qui a échoué
la
la transaction
a réussi
il y a eu un événement
de clic au panier
et là je suis en train de réfléchir
sur un système d'analytics
pour voir
qu'est ce qui est recherché
et sur
de faire la corrélation
entre le mot qui a été recherché
dans le moteur de recherche
et le clic
et donc l'article sur lequel ils ont cliqué
suite à leur recherche
pour comprendre en fait que la personne a tapé
yogurt
mais en fait elle a cliqué sur yogurt
et donc pour voir en fait toutes ces associations
là
et je suis en train de réfléchir à ça
et je vais utiliser Axiom
pour justement capter toutes ces informations
ça c'est du métier pur
et donc ça je le fais du côté applicatif
est ce qu'il y a
est ce que par exemple tu peux
mettre imaginant
tu as une erreur de paiement
enfin je sais pas au niveau du panier
ou n'importe quoi par exemple sur les commerces
tu peux à un moment sur Axiom dire
je sais pas si tu as des notifications
je sais pas si tu as des notifications
c'est possible
je me ferai
pour le coup ça
non ça moi je n'ai pas utilisé ça
c'est juste une question comme ça
pour le coup je sais pas
peut-être
sur des notifs
par contre l'avantage
c'est que si tu as logué
dans ton dashboard
en fait tu vas le voir que tu as une erreur
sur telle page
ça c'est plutôt
intéressant par contre
ça n'empêche pas
que je vais quand même utiliser
soit c'entri
soit
pas inconcurrent mais enfin oui
quelqu'un qui fait à peu près la même chose
qui s'appelle post hug
ou pour le coup
il y a un truc qui est juste
complètement ouf
qui s'appelle les session replay
ou en fait on va enregistrer
la navigation
de la personne
et en fait tu vas pouvoir
voir dans quel contexte elle était
et sur quel bouton elle a cliqué
avant l'erreur
et donc ça te donne vachement d'informations
de dire ok elle était ici
elle a cliqué sur ce bouton là
et c'est en cliquant sur ce bouton là
qui s'est déclenché
et ça a levé l'erreur
et donc ça en fait c'est du log
qui amène beaucoup beaucoup beaucoup de valeur
sur la résolution du problème
surtout côté front
parce que côté front
on le sait tous beaucoup de choses se passent
dans le navigateur et donc c'est
complètement mystique pour nous et donc
si on n'a pas quelque chose qui écoute
côté front
clairement on n'a pas
d'informations là-dessus
c'est chaud quand même
d'enregistrer
alors je t'arrête tout de suite
toutes les données en fait sont anonymisées
oui j'imagine mais bon
donc en fait tu ne vois pas par exemple
sur
sur un e-commerce tu ne vois même pas
le nom du produit
c'est des petites
étoiles
en fait tu ne vois pas
les informations tu vois juste
qu'elle est sur cette page
elle a cliqué sur tel bouton
et donc ça en fait
c'est totalement
anonymisé parce que tu ne sais pas qui
a cliqué sur ce bouton là
tu peux faire du rapprochement de données
l'outil te permet
de dire ok je fais
le rapprochement entre
tel user
et telle session
ça tu peux le faire
après
de voir si vous voulez faire ça
ou pas
il y a un outil marketing
qui enregistrait aussi pareil
pour suivre ce que les gens faisaient
mix panel tu veux dire
je me souviens plus mais pareil
ça faisait des records
de sessions
donc là je suis un peu mitigé
mais c'est vrai que c'est pratique par contre
quand tu as un bug et ça sent la personne
n'est jamais capable de t'expliquer
j'ai cliqué sur le bouton
ça marche pas
même pour les clients
quand tu envoies les premières versions
pour faire tester au client
il n'y a pas de texte qui décone
en fait
et pour le coup sur post-hug
il va avoir
de l'analytique classique
qu'on connait tous
il va avoir du session replay
pour voir en fait
où est-ce que ça a craché
ils vont aussi pouvoir gérer les feature flag
ils ont plein de choses
ils ont vraiment plein plein plein
plein plein d'informations
c'est un super outil
qui est
qui est vraiment hyper hyper intéressant
pour justement le tracking
d'erreur
et tout ça va pouvoir être envoyé
en fait dans
ce qu'ils appellent un
un data
un data warhouse
c'est un data lake
je sais pas comment ils appellent ça
en tout cas c'est tous ces événements
en fait
qui sont traités derrière
peuvent être analysés
par d'autres services
et donc ils vont enregistrer
toutes ces informations là
et donc on va avoir un mix
entre ce qu'on disait tout à l'heure
de la donnée technique, de la donnée métier
et donc c'est là où tous ces outils
peuvent nous aider énormément
à mieux loguer
pour amener de la valeur
à l'application finale
celui là tu l'as testé
je suis en test celui là
je suis en test
est-ce que c'est lourd
au niveau de la libre franque
ouais est-ce que c'est un peu lourd
alors j'ai pas testé ça
pour l'un de coup je teste ça
sur une application en interne
chez mon client
donc il n'y a que
c'est une application interne
ce qui me permet d'écouter
de voir un peu ce qui se passe
où j'ai beaucoup plus de liberté
sur la législation
je peux enregistrer plus de données
c'est moins...
après la perte elle n'est pas mordiale
exactement et surtout
je contrôle mon scope
de personnes qui utilisent ça
c'est pas gélant
clairement pour moi c'est pas...
ce qui me permet de tester
en condition réelle
quand même sur une application
qui tourne en prod
mais en minimisant l'impact
des downsides s'il y en a un
voilà je suis pas
sur le client
l'utilisateur final grand public
qui potentiellement
va me faire exploser
tous mes quotas
et tout ça et ce qui me permet d'appréhender
l'outil de manière un petit peu plus soft
et un peu plus
léger sans grosse pression
quoi
ok, après c'est vrai que c'est une bonne idée aussi
on y pense pas beaucoup
mais voilà pour des intranets
ou des choses un peu plus
ou des beta test d'applications
ça te rapporte des données
vachement intéressantes quand tu en fasses
de développement aussi donc c'est vrai que c'est pas mal
et puis là tu peux taper sur le fritière
tu n'as pas besoin de mettre la carte
donc c'est pas un gros trafic
et surtout moi l'autre avantage
que je vois c'est ça me permet d'apprivoiser
aussi l'outil
de voir
qu'est ce que c'est
cet outil m'amène, est ce que c'est intéressant
est ce que c'est bullshit, est ce que c'est super compliqué
à mettre en place
parce que
quelqu'un je pense qui a mis en place
un
promettatus
grafana
ou
un système genre
elastic search, loquie,
kibana ou des choses comme ça
c'est des stacks qui
vont permettre
d'enregistrer aussi
sur la stack elastic
on va pouvoir enregistrer
ils ont tout un écosystème
on peut regarder
c'est elastic
elastic search
elastic stack
il y a tout un outil
exactement
et elastic stack
qui va
vraiment
prendre du temps
à mettre en place
le ratio de la migration
d'un outil, elle peut être
hyper compliqué
parce qu'on a tout l'historique de donner
donc là on revient sur les fondamentaux
de notre métier
c'est quand on choisit un outil
quand on choisit une technique
pour le coup on signe un contrat
souvent sur plusieurs mois, sur plusieurs années
d'autant plus si c'est utilisé
en production
c'est compliqué de faire une migration
d'où l'intérêt de bien choisir
son outil
et de bien comprendre les tenants, les aboutissants
qu'est-ce qu'on va enregistrer
qu'est-ce qu'on va enregistrer
si c'est que de la donnée métier
je pense
à mixpanel
qui est aussi
plus orienté
métier
on va avoir
des segments
des amplitudes
qui sont vraiment plus
tournées métier
et nous
en tant que dev on va avoir plus
une approche plutôt technique
et donc il y a deux approches
sur ce type
de log
et donc
c'est à nous de bien faire
notre choix
pour bien répondre
à notre demande
voilà pourquoi il faut comprendre
l'art de logger
voilà
c'est super
on a fait un peu le tour
mais c'est vrai que c'est bien de
si aujourd'hui on le fait pas
c'est bien de commencer
par le commencement du century
comme ça
commencer à prendre l'habitude de logger des choses
d'analyser, de lire pour comprendre un peu ce qui se passe
et puis après
ça dépend aussi la taille de l'application
du site etc c'est vrai que
sur un tout petit truc ça rien de brancher
des graphenards et compagnie
faut pas s'en valer non plus
on est complètement d'accord
mais par contre sur des applications
qui sont importantes
tu travailles pour un client, le client a quand même besoin
d'avoir des data et surtout quand
le jour où ça va tomber
ou tu as des problèmes ou des erreurs
il faut savoir lui dire qu'est-ce qui s'est passé
si tu lui dis en fait je sais pas
c'est pas très sérieux
tu passes un peu pour un guignol
d'où l'intérêt
parfait
écoute patrick je te propose qu'on en reste là
pour cet épisode sur
l'art de logger
dites nous dans les commentaires si
ce type d'épisode vous intéresse
nous en tout cas
on a pris plaisir
on remercie toutes les personnes
qui sont restées jusqu'au bout de l'épisode
comme d'habitude un petit commentaire
un petit pouce ça nous fait toujours plaisir
et on remercie les sponsors
qui nous soutiennent
financièrement tous les mois
un grand merci à eux et on vous dit à bientôt
pour un nouvel épisode
ciao ciao