Bonjour à toutes et tous, vous écoutez Dans la Tech, le podcast où on partage ce qui nous fait vibrer ou pas dans le Dev, le Cloud et le DevOps.
Et on est du coup très heureux de vous retrouver pour une saison 2 du podcast Dans la Tech.
Et pour ça et pour commencer cette nouvelle saison, je vais accueillir l'équipe originale de Dans la Tech, c'est-à-dire Mathieu.
Mathieu, comment tu vas et es-tu prêt pour cette nouvelle saison ?
Je reviens de deux semaines de vacances, donc je suis au bouillon là. Et toi, comment ça va Damien ?
Écoute, moi ça vient très bien. Je reviens d'une semaine de vacances, une semaine et un jour pour être précis.
Donc ça va très bien aussi, même si je suis un tout petit peu fatigué, mais on va dire que c'est le temps qui veut ça.
Et puis bien sûr, Maxence que j'accueille aussi. Maxence, toi, est-ce que tu es prêt pour cette nouvelle saison et en pleine forme ?
Toujours. Moi, je n'étais pas en vacances comme vous deux, mais présent, prêt.
En plus, on n'a presque pas raté notre rentrée. L'année dernière, on avait commencé en novembre.
Donc là, c'est bon. On est presque pas mal. On devrait arriver début octobre. C'est cool.
Oui, ne vous inquiétez pas. La saison 5, bien sûr, le podcast commencera presque en septembre.
Mais l'intention est là, en tout cas. Et ça, c'est l'essentiel. Et en plus, Maxence n'a pas besoin de vacances pour être en forme, ce qui est quand même super.
J'espère que de votre côté, les auditeurs, vous avez autant de facilité à rester en forme.
Et pour attaquer cette rentrée, on va choisir un sujet qui nous concerne toutes et tous et qui, pour le coup, est une question qu'on peut se poser souvent.
Et pour le coup, je ne vois pas tant cette question sur les réseaux sociaux, mais il y a un vrai sujet là-dessus.
C'est pourquoi le monitoring, soit il est trop cher, soit il est inefficace.
Pourquoi on n'arrive pas à trouver un équilibre là-dessus ?
Aujourd'hui, on a un tas de solutions out of the box. On a de plus en plus de choses qui existent.
Mais on a vraiment l'impression que ce monitoring, je vais caricaturer, soit vous donnez votre carte de crédit à Datalog et vous espérez que votre banquier ne vous croise pas dans la rue.
Soit vous allez le mettre en interne avec des statuts.
On va dire traditionnel du Victor Ametrix, du Prometheus, des choses comme ça.
Auquel cas, ça va s'avérer soit inefficace, soit ultra chronophage à configurer, à setup.
Est-ce que déjà, vous êtes tous les deux dans ce constat-là ? Je pense qu'on a déjà un peu discuté.
Toi, Mathieu, qu'est-ce que tu en penses de ça ?
Bien sûr, le monitoring et même l'ossabilité en général, les solutions vont dépendre de la taille de l'entreprise.
On va dire la petite PME ou la petite startup qui a juste un site web.
Avec une application, une base de données, ça va pas être pareil qu'une grosse scale-up, une très grosse boîte, on va dire, avec un dégoût ici.
Je suis plutôt dans le cas avec une infrastructure assez conséquente.
Et même dans le passé, je travaillais un peu dans ce genre de contexte.
Et c'est vrai qu'aujourd'hui, moi, je vois un gros problème dans l'industrie.
C'est que soit, c'est ce que tu as dit en fait, Damien, je ne sais pas qui peut se payer des services cloud d'Observability.
Aujourd'hui, je ne vois pas qui a l'argent de faire ça.
Je veux dire, je suis quand même dans une scale-up qui a levé des centaines de millions d'euros.
On ne peut pas se payer les clouds d'Observability.
C'est trop cher.
C'est trop cher, vraiment.
Un truc de fou.
Donc, on refait en interne, mais il y a aussi beaucoup de limitations qu'on pourra discuter.
Donc, ouais, on a tous un peu, j'ai l'impression, dans le domaine, le cul entre deux chaises.
Entre devoir faire de l'on-prem, mais ça a aussi un coût, un coût différent que les SaaS.
Mais les SaaS sont juste hors de prix.
C'est limite, enfin, c'est même pas limite, c'est du vol.
Clairement, je veux dire, moi, c'est mon avis du moins.
Je ne sais pas ce que vous en pensez, vous.
Mais je ne sais pas qui veut rebondir.
En fait, j'ai un poil plus mitigé.
Parce que, alors, est-ce que c'est cher ?
Ça, je pense qu'il suffit d'aller voir une page pricing d'un Datadog, New Relic, Grafana Cloud ou autre,
et vous aurez votre réponse tout seul.
Après, quand on voit la qualité de ce qu'ils sont capables de ressortir,
enfin, j'étais utilisateur de Datadog il y a encore quelques années.
Globalement, out of the box, en fait, ils arrivent directement avec des dashboards.
Tu leur dis que tu fais du cube, bam, il y a les dashboards.
Il t'indique.
Il t'indique comment récupérer tes logs, tes métriques par défaut.
Tu as les alertes qui sont là directement.
En fait, c'est très plug and play.
Donc, tu payes ce côté très plug and play aussi.
Et c'est ce qu'ils te font payer.
Et c'est, pour moi, un des problèmes aussi de la partie open source.
C'est que la partie open source, en fait, déjà, avant même de pouvoir envoyer le moindre log, métrique,
je ne parle même pas encore des traces pour en parler.
En fait, déjà, tu dois installer un nombre d'outils qui est juste ultra conséquent.
Et alors, c'est sûr qu'une fois que ça tourne, ça tourne et tu l'oublies un peu.
Mais il y a énormément de configs à faire, de petites modifications, etc.
à faire en permanence qui reviennent aussi chères à la fin.
Mais moins chères qu'un Datadog quand même.
Après, oui, Datadog, perso, moi, je l'ai utilisé deux, trois fois.
D'un point de vue, on va dire efficacité, je n'ai rien à redire.
Je pense qu'aujourd'hui, si on veut du monitoring rapidement,
après, il y a d'autres solutions, il y a du Dynatrace, des choses comme ça.
Ce sont des solutions qui sont extrêmement rapides pour être, on va dire, utilisables.
Entre le temps où vous le setup et globalement, vous rentrez,
votre numéro de carte de crédit et le moment où vous avez des dashboards
qui sont compréhensibles par vos équipes, le temps est relativement court.
Donc là-dessus, il n'y a pas de souci.
Mais c'est vrai que le scaling du prix est violent.
Moi, Datadog, c'est vraiment, moi, j'ai eu deux, trois expériences.
Ouais, dans l'autre, c'était qu'un POC, mais j'ai eu deux expériences complètes.
On a fait une migration vers Datadog, dont une fois de solution un peu ancienne type Centrion.
Le prix était tellement une horreur qu'au bout d'un an, la boîte a décidé de quitter Datadog.
Parce qu'à part pour des besoins très spécifiques, ils n'étaient plus sur Datadog.
Parce que c'était trop cher, en fait, et les BU ne pouvaient pas assumer, les clients ne pouvaient pas assumer.
Donc du coup, on s'est retrouvé à un peu revenir faire marche arrière
et faire notre solution un peu custom pour le coup.
Et pour ça, je pense que c'est efficace, mais c'est clairement pas abordable pour la plupart des entreprises.
Après, il y a aussi un autre truc que moi, je vois et c'est une impression que j'ai.
J'ai l'impression que autant...
Pour faire un parallèle avec le cloud, je trouve que nos exigences en matière de qualité ont vachement augmenté comparé à avant le cloud.
Donc, c'est-à-dire tout ce qui est appellisation, tout ce qui est infrastructure, tout ce qui est réactivité.
On est beaucoup plus exigeant aujourd'hui qu'avant.
Et j'ai l'impression que le monitoring, c'est un peu le même cas, en fait.
Là où, et je ne parle pas d'il y a...
C'est quand même bientôt il y a 10 ans, mais je parle même d'il y a 5, 6 ans, et même dans beaucoup d'entreprises.
Il y a encore des simples systèmes avec des super sondes.
C'est SNM.
Je crois le protocole et du centréon et tout ce qui s'ensuit derrière.
Avec des alertes binaires en mode tel host, tel truc dessus et down ou up, etc.
Et ça, il y en a encore beaucoup.
Et pour moi, le gap, autant en termes de prix, est énorme entre ça et un Datadog ou une solution, on va dire, maison on-prem, open source, bien foutu.
Le gap est énorme.
Mais le gap en termes de qualité, il est énorme aussi.
Il est conséquent.
Je ne sais pas si vous êtes d'accord avec ça.
Oui, il y a une grosse marche.
C'est sûr par rapport à avant.
Moi, j'ai fait aussi du Nagio, ces choses comme ça, il y a très, très, très longtemps.
Et là, on est dans un mode complètement différent.
On parle souvent de Blackbox versus Whitebox Monitoring, des choses comme ça.
Après, comme disait Maxence, c'est vrai que les services SaaS, enfin les SaaS, tout arrive built-in.
C'est très, très puissant.
Quand je disais que c'est du vol tout à l'heure, je troll.
Ce n'est pas du vol.
C'est vrai qu'on sait pourquoi on paye.
Ça marche très bien.
On pourra parler du lock-in aussi.
Parce que les agents magiques proprios, ça marche bien.
Puisque vous, on veut changer de SaaS.
Et là, ah !
En fait, ce n'est pas le même protocole.
Il y a des solutions aujourd'hui, mais il faut faire attention à ça.
Et comme tu l'as dit, David, les besoins, ce n'est plus du tout les mêmes.
Aujourd'hui, par exemple, on s'attend à ce qu'une application web classique, une API, expose des métriques sur ses IOs.
Par exemple, les requêtes HTTP.
Souvent, on parle des méthodes RAID ou des choses comme ça.
Donc, en fait, les requests, le rate de requêtes par seconde avec des labels par pass, par méthode, par statut code.
Pour pouvoir en situer.
Faire des requêtes là-dessus.
La latence également.
Donc, sur les performances.
Donc, en entrée et en sortie.
On s'attend à avoir des métriques internes.
Par exemple, sur la JVM.
Je ne sais pas, sur le garbage collector.
Même en Go, des choses comme ça.
Ou sur des thread pools.
On s'attend à avoir même des métriques métiers aujourd'hui.
Pas seulement des métriques techniques, mais des métriques métiers.
Qui vont aider le business à comprendre comment l'application est utilisée.
Donc, des métriques custom.
Donc, ça va très très loin.
Et c'est vrai que c'est pour ça aussi que ça coûte cher.
Parce que là, je parle des métriques.
Mais on pourrait parler des traces aussi.
Et des logs.
Et bien, en fait, ça fait énormément de signaux qui sont générés.
Qui doivent être stockés, analysés.
Et de manière efficace.
Parce qu'en plus, quand on stocke des teras de métriques.
Des teras de traces.
Moi, c'est mon cas.
Ben, forcément, les traiter, ça a un coût.
Même les faire passer sur le réseau.
Si vous êtes sur le cloud.
Par exemple, sur Amazon.
Rien que le coût réseau du transit.
Ça coûte très cher.
Donc, ouais.
C'est des contraintes qu'on n'avait pas forcément avant.
Ou bien, beaucoup moins.
Parce qu'il y avait une tolérance un peu.
Enfin, on monitorait pour moi beaucoup moins bien.
Après, je trouve que...
Enfin, si on continue à comparer un peu Datadog versus...
Enfin, Datadog et Consor, on parle beaucoup de Datadog.
Mais ils ont tous à peu près les mêmes idées de pricing.
Versus un truc maison.
Il y a aussi pour moi un point intéressant.
C'est que quand tu es à la maison.
Un teras de plus sur ton S3.
Parce que globalement, tes logs et tes métriques ont souvent tendance à finir sur ton S3.
Un teras de plus, un teras de moins.
Ça te coûte 5 euros par mois.
Tu t'en fiches en fait.
Donc, tu vas accepter de tout loguer.
Et de tout récupérer.
De tout récupérer dans tes logs.
Alors que chez Datadog, tu vas très vite avoir une logique de...
Oula, tout coûte tellement cher.
Que tu vas dire...
Oula, non, mes logs, en fait, je ne les envoie plus.
Et je n'envoie que les erreurs.
Mais je n'envoie que 10% des erreurs que j'ai dans mes logs.
Les traces, c'est pareil.
Les traces, pendant très longtemps...
Je ne sais pas si vous avez connu l'époque.
Un peu avant, au plan de télémétrie et compagnie.
Où ces Datadog avaient leur agent.
Et ils utilisaient vraiment des méthodes Datadog.
Etc.
Il y avait écrit partout qu'il fallait absolument sampler tes requêtes.
Etc.
Et on voyait qu'il y a un petit pourcentage de tes requêtes.
Et la logique, je trouve, est toujours la même.
Sur tes métriques, tu n'envoies pas les métriques si elles ne sont pas utilisées dans un dashboard ou quoi.
Parce qu'en fait, sinon, à l'échelle...
Par exemple, Mathieu, chez toi, si tu essaies de calquer ce que tu as en monitoring chez toi,
en termes de volume, chez un Datadog, en effet, la facture, c'est impossible.
Par contre, si tu commences à te dire, en fait, je vais filtrer...
Peut-être que dans tes métriques, tu as 80% des métriques qui ne sont pas utilisées.
Je dis ça, j'en sais rien, je ne connais pas.
Mais souvent, on a tendance à tout récupérer, à utiliser quelques trucs.
Mais en fait, on ne fait jamais le...
Dans les collecteurs, on ne fait jamais le tri.
On peut dire, non, en fait, tous ces trucs-là, je les vire, tu vois.
Je ne les utilise pas.
Par exemple, tout ce qui est en Go, toutes les métriques Go, je n'utilise pas.
Je les vire et je ne récupère que celles qui m'intéressent très spécifiquement.
On est plutôt dans le mode inverse.
Et pour le coup, ça, chez Datadog, tu vas le payer vite, très cher.
Moi, j'ai fait du Datadog, j'ai fait du Graphana Cloud après.
Les deux me disaient la même chose, globalement.
En fait, il faut inverser ta logique et juste, tu envoies ce que tu as besoin.
Mais ce qui me pose moins un problème sur ça, c'est que le jour où j'ai un problème,
en fait, des fois, je n'ai pas pensé à envoyer la bonne métrique ou le bon log.
Donc, tu te retrouves à ne pas avoir l'information.
Et c'est là où je trouve que la logique est mauvaise.
C'est que pour moi, j'attends en tout cas, dans mon système de log, de métrique et de trace,
d'avoir 100% de la data.
Je lui envoie tout, je lui brune sa tronche parce que justement, je vais avoir, en cas de problème,
je vais pouvoir réutiliser.
Je vais pouvoir récupérer tous mes logs, je vais pouvoir récupérer toutes mes traces,
je vais pouvoir récupérer tout pour essayer de comprendre au maximum
quel est le problème que j'ai rencontré et pourquoi je l'ai rencontré
et essayer de mettre un peu en corrélation tout ça.
Et dès que tu samples, en fait, c'est mort.
Je ne fais plus de ça.
Je suis d'accord avec toi sur le fait que moi, je ne suis pas fan de cette approche
de ne pas tout envoyer pour deux raisons.
La première, c'est celle que tu évoquais.
Forcément, le jour où tu as une merde, la métrique dont tu auras besoin,
tu ne l'as pas mise dans celle que tu récupères.
Ça, c'est la même chose.
C'est la loi des séries.
On le connaît tous.
On l'a tous déjà eu.
Et la deuxième raison, qui est une raison, on va dire, peut-être un peu plus spécifique,
peut-être que clairement, on ne sera pas d'accord avec moi,
mais quand on fige, on va dire, on shortlist les métriques qu'on va récupérer, etc.
pour du coup éviter de surfacturer ou autre,
j'ai l'impression que ça fige aussi beaucoup la création de dashboard,
la création d'indicateurs, etc. de l'autre côté,
dans le sens où les gens auront moins…
Il faut qu'ils aient la main sur l'ajout de métriques dans les choses qui sont remontées, etc.
C'est beaucoup plus contraignant.
On ne peut pas faire de test rapidement, etc.
Donc là-dessus, je trouve que c'est très, très vite aussi un frein.
On va à l'innovation, mais en tout cas, à la création,
à l'amélioration de dashboard avec des métriques autres.
Parce qu'il y a énormément de métriques.
Généralement, quand on rajoute du monitoring,
je vais prendre l'exemple côté Waze de globalement comment ça se passe.
En général, quand on a un nouveau produit qu'on monite,
je prends un exemple, même s'il est déjà monitoré,
mais imaginons demain, on veut rajouter du monitoring sur Achat Proxy.
On va rajouter un exporteur.
Et cet exporteur, on va récupérer toutes les métriques.
Et à partir de là, on va construire un dashboard
avec les métriques qui nous semblent pertinentes
par rapport à notre expérience qu'on a dessus.
Et typiquement, ce qui arrive régulièrement,
c'est qu'on fait de l'amélioration continue, même tout le temps du coup.
Ce qui arrive,
c'est que la plupart du temps, le dashboard,
on va le créer, on va l'initialiser avec une vision minimale
qu'on avait avant les métriques.
Et au bout d'un mois, à force d'avoir potentiellement
des bugs d'incidents, des bugs de perfs, etc.,
on va savoir quelle métrique n'est pas complète,
quelle il faut potentiellement corréler avec d'autres.
Et on va se rendre compte qu'entre les métriques qu'on avait au moment X
et ce qu'on en a eu comme expérience Y,
on va pouvoir l'améliorer en ajoutant justement ces nouvelles métriques.
Et là-dessus, j'en reviens aux deux points.
C'est que le premier point, c'est comme tu dis, Maxence,
en général, les métriques que tu veux ajouter, tu ne les aurais pas mis de base.
Donc du coup, là, on ne pourra pas savoir si elles sont pertinentes,
alors que là, on peut de suite faire une corrélation et se dire
quand on avait cet incident-là, on ne l'avait pas vu sur le dashboard.
Par contre, la métrique l'a montré.
Et d'un autre côté, là où c'est intéressant,
c'est que c'est très rapide à ajouter dans le dashboard.
Globalement, on l'ajoute dans le Grafana,
on commit dans notre Git l'export JSON et c'est déployé.
Donc du coup, on a tous nos dashboards qui ont,
du coup, cette mise à jour.
Et pour moi, si on ne remonte pas tous les métriques,
ce cycle, on va dire, d'amélioration continue,
il est beaucoup plus lourd et beaucoup plus contraignant.
Je ne sais pas, toi, quelle expérience tu as avec tout ça, Mathieu ?
Est-ce que tu en penses ?
Maxence a déjà raison que parfois, il y a de l'abus.
Les métriques, nous, pour le coup, moi, j'ai beaucoup travaillé sur le sujet.
Je monitore la cardinalité des services.
Je fais très attention à ce qu'il y a en label.
J'ai même des alertes qui remontent
si des services ont des cardinalités de métriques élevées.
Donc si généralement...
Il y a beaucoup de métriques.
Par contre, sur les logs, en effet,
les logs et l'optimisation à faire, ça, c'est sûr.
Il y a beaucoup de boîtes, même, j'en ai connu dans le passé,
qui logent n'importe quoi.
Mais par contre, aujourd'hui,
même des métriques de base, ça coûte très cher.
Je vais faire le calcul en live.
Vous mettez du Prometheus sur un serveur HTTP
et vous mettez juste les métriques de base HTTP,
c'est-à-dire un bucket pour la latency de vos requêtes HTTP
et un counter pour l'error rate,
le request rate.
Un bucket Prometheus, c'est 12 séries.
Pour 4 verbes HTTP,
vous faites x4.
Pour 5 status codes,
parce que généralement, c'est par status code,
donc 200, 201, 400, 401, 500,
en réalité, il y en aurait plus.
Pour 100 passes,
je fais 12 x 4 x 5 x 100, un truc comme ça.
Je suis déjà à 24 000 séries.
Et là, sur le cloud, je suis déjà à des milliers d'euros par mois.
Je ne compte même pas l'infra,
je ne compte pas les coûts réseaux,
je ne compte pas...
Voilà, et donc, vous multipliez ça par...
En fait, là, en plus, c'est des petits chiffres.
En réalité, il y a beaucoup plus de status codes,
donc vous faites x10.
Et très rapidement, vous avez des services avec, voilà,
20 000, 30 000, 40 000, 100 000 séries,
multipliées par le nombre de services,
plus les métriques infra, etc.
Eh bien, la facture cloud, elle est déjà à 100 000, 200 000,
300 000, 400 000 par an.
En fait, ça monte extrêmement vite aujourd'hui.
Et c'est ça, le gros problème des services cloud.
C'est pour ça que je disais au début,
j'ai du mal à voir qui peut se payer ça,
parce que même en faisant gaffe,
gaffe, notamment sur la partie métrique,
ça coûte une fortune.
Et sur les traces, moi, ça m'embête de drop des traces.
On est, comme disait Maxence,
les traces, c'est un outil très utile pour débuguer.
D'ailleurs, on pourra en parler,
mais je pense que les traces vont remplacer les logs.
En fait, je préfère avoir aucun log et des traces.
Ça me coûtera aussi moins cher.
Les traces, c'est vraiment quelque chose,
pour moi, une brique de base.
Et donc, j'essaye de les garder.
Mais voilà, moi, je reste un peu sur ma position
qu'aujourd'hui, le cloud, c'est trop cher.
Et moi, j'ai des expériences aussi dans le passé
de migrer de cloud vers l'on-prem
et diviser.
Par deux, trois, quatre, la facture.
On parle de facture à six chiffres, parfois.
Ou même de faire des devis pour repartir dans le cloud
parce que personne n'aime maintenir sa stack de monitoring.
Moi, ce n'est pas un intérêt personnel à faire ça.
Mais quand on vous dit que ça va coûter,
vous avez des devis,
c'est un tiers de votre facture cloud
qui est déjà très élevé,
juste pour envoyer des traces.
Mais c'est impossible.
Et ça, c'est après les réductions,
après les négociations, etc.
C'est un truc de fou.
Après, quand tu héberges ta stack,
ce n'est pas magique non plus.
Enfin, moi, je vois le temps que j'ai pu passer
à configurer Loki,
à après virer Loki pour mettre QuickWit à la place.
Pareil pour mes traces.
Je ne sais plus c'est quoi le soft de Graphana Labs
pour les traces,
mais c'était la même logique.
J'ai fini par le dégager pour QuickWit.
Après, j'ai eu les métriques.
Enfin, j'ai commencé par les métriques.
Sinon, tu commences toujours par là.
Au début, j'ai fait du Prometheus.
Après, j'ai commencé à faire du Thanos.
Puis, j'ai fini sur Victoria Metrics.
Et en fait, on arrive vite à toujours la même chose.
Typiquement, je me rappelle mon Loki
avec le stockage sur S3.
C'est vachement bien.
Ça ne te coûte pas cher.
Il ne faut juste pas vouloir le requêter.
Oui, je suis d'accord.
En fait, moi, le problème que j'ai
avec les stacks open source,
c'est que globalement,
elles veulent toutes se baser sur S3.
Sauf qu'elles sont toutes lentes,
inefficaces, voire impossibles.
Quand je vois dans Loki,
des fois, tu fais une requête,
le truc, il mouline,
et tu n'as jamais ta réponse.
Je suis désolé,
mais si je ne peux pas utiliser
ma stack de monitoring,
elle ne me sert à rien.
Et sur Loki, c'est vite le cas.
Sur Tempo, je n'entends la même part.
Là, je suis en train de tester des tools
pour faire du profiling.
Il y a aussi celui de Grafana.
C'est pareil, en fait.
Dès qu'il commence à stocker
des trucs sur S3,
c'est tout pourri.
Mais c'est vraiment tout, tout, tout pourri.
Oui, mais c'est un standard,
et ce n'est pas cher.
Donc, c'est pour ça que...
Oui, mais sauf que moi,
tu es en astreinte.
Tu as un truc qui sonne.
Si je ne peux pas avoir
l'information rapidement
et avoir mes logs, etc.,
en fait, je ne fais plus d'astreinte.
On va gagner du temps.
De toute façon, je ne peux pas
débloquer parce que je n'ai pas d'info.
C'est pour ça qu'on a appelé le podcast...
Enfin, le titre, c'est inefficace
ou trop cher parce que c'est vrai
qu'on est coincé entre les deux.
Et moi, je suis tout à fait d'accord
avec toi, Maxence.
Moi, je self-host, voilà, aujourd'hui.
Du Thanos, du Tempo,
des choses comme ça.
C'est mégalent.
Parce que tout est basé
sur S3.
Récemment, il y a une nouvelle
release de Tempo qui est sortie
où on peut transformer
des traces en métriques
via une query.
Bon, il y a quelqu'un
dont on déploie,
il y a quelqu'un qui teste.
Sur un service,
faire un quantile,
en gros,
calculer le P99
sur un service
sur la dernière heure,
sur des requêtes HTTP,
sur les traces HTTP,
voilà.
Vu que c'est une requête simple,
le truc, il time-out
au bout de...
Le truc, il est à 5 gigabits
de seconde, la query,
pendant 5 minutes
et elle finit par time-out.
Tu fais bon, OK.
Enfin, c'est des chiffres du style.
Rien que le cool du réseau.
Ouais, non, mais voilà.
Rien que le cool du réseau.
C'est exactement ça.
J'ai dit la même chose.
J'ai dit, la query,
elle a coûté 10 balles
sur la facture Amazon.
Enfin, je ne sais pas.
Mais c'est...
Et donc, c'est le même problème.
Thanos, c'est pareil.
Thanos, c'est méga long.
Franchement,
tu ne peux pas ouvrir
un dashboard sur une semaine.
Là, je vais dire un truc
que vous allez me détester,
mais en soi,
là-dessus,
ELK, j'aime bien le fait
qu'elle soit quand même
bien plus rapide
pour faire des recherches.
Oui, mais pourquoi
c'est bien plus rapide ?
Parce que le stockage
n'est pas S3,
c'est de l'ES.
Pourquoi j'ai viré mon Thanos
pour ma DeVictoria Matrix ?
C'est juste parce qu'il y a
des disques, quoi.
Et que juste,
quand je veux le requêter,
quand je veux faire une requête
alors j'attends un petit peu,
mais j'ai ma réponse.
Est-ce que je ne peux pas
avoir un Vectanos ?
Je suis vu dans l'OK
des fois faire des recherches
de 10 secondes en 10 secondes
dans mes logs
tellement c'était lent.
Pour avoir une réponse rapide,
j'avançais de 10 secondes
par 10 secondes par 10 secondes.
Non, non, enfin...
Donc OK,
on parlait tout à l'heure
qu'on a gagné en outillage
par rapport à avant,
par rapport au Nagios,
machin, etc.
Mais des fois,
je n'ai pas l'impression
qu'à la finalité,
est-ce que mon infrastructure
est mieux monitorée qu'avant ?
Des fois,
je me pose la question.
Dans combien de boîtes
le monitoring,
c'est juste un call HTTP
sur une URL de l'application
et en final,
tout le reste,
c'est de la fleuriture inutile.
C'est souvent,
malheureusement,
ça se finit comme ça
tellement le reste
n'est pas fiable.
J'avoue que LK,
c'est rapide,
on en fait aussi.
Ça marche plutôt bien.
D'ailleurs,
l'opérateur cube
marche très bien.
Je tenais à le préciser
sur le fait du cube,
testez-le.
Mais oui,
comme tu dis,
Maxence,
c'est frustrant
parce que beaucoup de solutions
sont un peu terribles.
Même l'UX de Prometheus,
j'ai toujours trouvé ça
un peu dégueu,
pour être honnête.
J'ai toujours préféré
le push au pouls.
Déjà, ça n'aide pas.
Et on pourrait aussi parler
du coût à implémenter
le monitoring.
Parce que tu parlais
tout à l'heure,
Maxence,
de mettre un agent
et que ça marche très bien.
Il y a le problème
du locking toujours pour moi
sur les protocoles propriétaires,
même si OpenTelemetry,
je pense,
résout ça
et est déjà en train de résoudre.
Mais c'est vrai qu'aujourd'hui,
il y a un vrai coût
que je vois aussi
sur demander aux devs
avec des équipes
qui ne sont pas forcément
toutes familières
avec l'Observability
en général,
implémenter les bonnes métriques,
c'est-à-dire comprendre
comment ça marche prom,
les histogrammes,
les counters,
les gauges,
etc.
Implémenter les traces,
comment ça marche,
les traces,
comment je crée une span,
qu'est-ce que je dois mettre dedans,
les attributs,
Semconf et tout.
Log,
loguer correctement.
Parce que les logs,
c'est qu'est-ce que je dois loguer,
attention,
j'ai des PII,
il ne faut pas que je logue
des données sensibles,
il faut faire des logs level propres,
etc.
Et donc,
c'est un vrai coût
pour les équipes,
en fait,
également,
ce n'est pas que le coût infras,
en fait,
il y a le coût aussi
de maintenance de l'Observability
dans le code
qui est très important
aujourd'hui,
et même en standardisant,
en faisant des librairies,
etc.
C'est un vrai coût
et ça met du temps
également à implémenter.
Là,
je vais peut-être être
un peu l'avocat du diable,
mais en vrai,
aujourd'hui,
si tu regardes
sur le taux d'entreprise,
je pense qu'il n'y en a pas
beaucoup qui l'ont implémenté.
La partie vraiment,
on va dire,
rien qu'avoir un APM basique,
il y a quand même
beaucoup d'entreprises
et de boîtes
qui n'en ont pas.
Et après,
qui passent des heures
à essayer de débug
avec des informations partielles
pour des problèmes de perf,
pour des problèmes de call
sur des URL externes
et tout ça,
alors que tu fous un APM,
tu gagnes du temps en débug.
Mais énormément de boîtes,
je pense que la grande majorité
des boîtes aujourd'hui
n'ont pas d'APM,
n'ont pas de traces,
n'ont pas tout ça.
Et là,
c'est un peu des problèmes,
on va dire,
de riches.
Mais ce qui est dommage,
c'est qu'il y a une vraie,
du coup,
valeur ajoutée.
Est-ce que tu dis
que ça t'enlève aussi
beaucoup de temps de débug ?
Parce que j'ai déjà vu
des cas de débug
où l'application est lente
depuis deux semaines,
il n'y a personne
qui sait pourquoi.
Le dev,
il a passé une semaine dessus.
Tu dis,
mais tu as mis un APM ?
Non,
tu fous un APM.
Le mec,
tu fais,
ah bah oui,
mais c'est bizarre,
là,
tu as un appel
à telle API externe
et elle prend
tant de secondes de trop
et tu te rends compte
que c'est ça
qui te provoque
toute la merde.
Et ça,
pour le coup,
c'est,
je pense,
quelque chose
qu'on oublie aussi.
C'est tout ce temps
à débug
qui a un coût
qui est énorme
en société
et qui,
la majorité des sociétés
le payent aujourd'hui
par ce temps-là.
Moi,
j'ai une chose
que j'aime bien,
j'ai beaucoup d'amis
qui sont dans le métier
mais qui ne sont pas
forcément dans,
je dirais,
dans des boîtes
cutting edge
ou dans des boîtes
qui cherchent à
innover,
le mot est peut-être
un peu fort,
mais à toujours améliorer
les choses
et qui sont dans des boîtes
assez classiques
et je pense
que vous n'imaginez pas
le nombre de boîtes
qui sont dans un état
à ce niveau-là
qui est vraiment,
qui te paraîtrait
l'âge de pierre,
Mathieu,
sans exagérer.
Je sais,
je sais qu'on est
dans notre bulle.
Après,
tu parles d'APM,
c'est aujourd'hui
pour moi tout l'intérêt
d'un open télémétrie,
c'est qu'en fait,
ça t'apporte un APM
plus digne
parce qu'en fin de compte,
ça fait la même chose
et après,
par contre,
tout dépend
de ton langage.
Tu prends Go,
par exemple,
parce que je pense
que Mathieu,
c'est aussi en Go
que tu l'utilises
de ton côté.
En Go,
il n'y a rien de magique.
De toute façon,
en Go,
en général,
il n'y a rien de magique
et donc,
si tu veux des traces,
tu es obligé,
une trace vers ta DB,
tu es obligé
de le faire toi-même
à la main
ou utiliser une lib
qui va t'abstraire le truc
mais à la fin,
tu as du code
que tu as écrit.
Là où si tu fais
des langages différents,
qui sont plutôt
des langages interprétés,
du PHP,
du Node,
etc.,
en fait,
souvent,
en PHP,
je ne sais pas si vous vous souvenez,
mais la lib Datadog
ou numérique,
c'est juste un binaire
en C ajouté dans la lib
et hop,
ton APM,
il est fait
parce que c'est plus facile
de le faire comme ça.
Je crois qu'en Node,
ça marche de la même façon,
etc.
Donc,
tout dépend de ton langage après.
Donc,
c'est des choses
qui sont plus ou moins faciles
et puis,
tu as quand même
une mouvance
qui est en train
de bouger sur ça
avec EBPF
où l'idée,
justement,
c'est de venir
avoir ton layer le plus bas
qui va pouvoir te remonter
tes traces
de façon automatique.
Alors,
tu n'auras peut-être pas tout,
tu n'auras peut-être pas
la granularité des fonctions
dans ton code,
tes requêtes HTTP
ou autres sortantes,
tes accès
au MySQL,
au Postgres
ou autre
à ta base de données
que tu fais,
etc.
Et déjà,
quand tu vois
tes requêtes lentes
parce qu'il ne faut pas
ligner des index,
les index,
ça permet
de gagner du temps
ou tes requêtes HTTP lentes,
tu vois assez vite
tes problèmes,
c'est clair.
Enfin,
c'est clair,
n'est-ce pas le coup ?
C'est vrai.
Après,
je ferai quand même attention
avec EBPF,
etc.
Ça marche très bien.
Enfin,
ça marche très bien.
On est encore au début,
on va dire.
Il y a déjà des solutions,
on va dire.
Par contre,
il y a un truc
qui me dérange aussi sur ça,
c'est que,
OK,
ça marche,
il y a la base HTTP,
etc.
Mais le vrai intérêt
de l'observability,
c'est aussi un peu
ce que je disais au début,
d'avoir des informations métiers.
C'est-à-dire,
moi,
j'adore attacher à mes spans,
si on parle de traces,
des informations métiers,
organization ID,
user ID,
action,
des trucs un peu vraiment
qui parlent au métier
pour pouvoir suivre
des flux utilisateurs
de manière beaucoup plus précise,
comprendre quelle organisation
fait quoi,
à quel moment,
suivre son parcours.
Sur,
sur la partie métrique,
je pourrais aussi mentionner
les SLO.
Les SLO les plus intéressants,
ça reste les SLO produits,
donc avec des métriques
souvent un peu custom.
Moi,
je m'en fais,
mon client,
il m'en s'en fiche
que mon Kafka consumer rate,
il soit à 3% d'erreur,
je ne sais pas quoi.
Lui,
ce qu'il veut,
c'est un SLO de type,
j'arrive à faire
telle fonctionnalité.
Si je suis sur une marketplace,
ça va peut-être être
valider mon panier,
payer,
je ne sais pas,
moi,
naviguer,
enfin,
faire une recherche sur le site.
Donc,
des SLO comme ça,
c'est de la même manière
qu'on ne peut pas ajouter
des attributs custom
sur les traces avec,
enfin,
sur les spans.
Ça reste quelque chose
de très générique,
en fait.
Là où le vrai intérêt
pour moi d'observabilité,
c'est d'aller quand même
dans le spécifique,
dans le métier.
Oui,
pour moi,
ça te fait un premier niveau,
c'est-à-dire que
ce n'est pas parfait,
mais ça fait un premier pas
qui n'est pas trop dur
si ton système a déjà
le BPF,
etc.,
des prérequis.
Au moins,
ça te permet d'avoir
un premier niveau
qui serait plutôt l'APM,
plutôt que de la pure trace.
Et de là,
après,
quand tu vas commencer
à avoir l'intérêt,
c'est là où,
pour moi,
tu vas passer au level d'au-dessus
et te dire,
ah oui,
mais en fait,
maintenant,
je voudrais bien
pouvoir suivre vraiment
ma modernisation ID,
mon user ID,
machin,
et tout transférer.
Et c'est là où tu vas
commencer à aller modifier
ton code,
etc.
Mais New Relic
et Datadog,
au début,
ils se sont fait connaître,
c'est parce qu'ils avaient
des APM qui marchaient.
C'est ça qui les a fait connaître
en tout premier lieu.
Et après,
ils ont développé leur business.
Enfin,
moi,
à Datadog,
j'ai découvert
parce qu'un jour,
j'avais un problème de perf.
J'ai installé leur agent.
Cinq minutes,
mon truc était réglé.
Mon free trial n'était pas fini
que j'avais réglé
tous mes problèmes de perf.
Mais je n'ai jamais payé.
C'est peut-être pour ça
qu'ils se sont rattrapés
maintenant sur les facturations
parce qu'il y a beaucoup
de gens comme moi
qui ont testé
et qui ont réglé
leurs problèmes
et fin.
Donc,
tu es en train de dire
que les gens,
il ne faut plus aller regarder
auprès de Datadog,
mais auprès de toi
pour les prix ?
Ils peuvent essayer.
Je ne suis pas sûr
que j'aurai un grand impact
chez Datadog par contre.
Je peux vous envoyer
un commercial Datadog
si vous voulez.
Non,
mais en vrai,
j'adorerais avoir acheté
pour acheter du SaaS.
J'adorerais,
mais franchement,
trop cher.
Enfin,
tout le monde est proche.
À partir du moment
où le prix du SaaS,
tu peux avoir une équipe
de deux,
trois personnes
qui s'occupent de ça
full time,
plus le matos,
c'est vrai que c'est compliqué
de justifier ça.
Après,
il n'y a pas que ça.
C'est bien,
on a nos métriques,
on a nos traces,
on a nos logs.
Mais maintenant,
quand il faut faire des alertes,
des fois,
typiquement,
la dernière fois,
je cherchais des alertes
pour Traffic,
j'ai l'impression
que j'ai demandé
un truc de fou.
Personne ne partage.
En fait,
on ne partage pas
les alertes qu'on a déjà.
c'est une bête alerte 500
pour toutes les 5 X en code HTTP.
C'est bon,
tu ne trouves rien sur Internet
ou le truc qui ne marche pas.
Et donc,
en fait,
chaque boîte réimplémente
la même chose
pour le même site.
Pour le même soft,
il n'y a rien
qui est partagé.
Alors que tu arrives
sur un Datadog,
un Neuralink,
tu te dis que tu as
Traffic,
tu cliques sur le petit bouton,
tu as le dashboard qui arrive,
tu as les alertes
qui sont arrivées,
et tu n'as plus
qu'à reconfigurer les seuils
et dire vers où
tu veux être notifié.
Et c'est ça,
pour moi,
c'est ça qui vante
ce côté très plug and play
que tu n'as pas
du tout,
quand tu self-host.
Oui,
je suis tout à fait d'accord.
Les alertes,
tout le monde
réinvente sa sauce,
clairement,
moi aussi.
de plus en plus
pour que les devs
n'aient pas trop
à créer du promql,
des abstractions
pour ne pas créer
des fichiers,
etc.
Mais voilà.
Mais je suis désolé,
le pricing,
on parlait de Neuralink,
je connais bien la solution,
je l'ai utilisée dans le passé,
j'ai fait des devis et tout.
Là,
je suis sur la page,
sur l'Enterprise,
pour l'utilisateur core,
ce n'est même pas
le niveau supérieur,
on est à déjà 49 balles
par utilisateur.
Donc,
tu as 100 devs,
tu es déjà à 5000 balles
par mois,
tu n'as encore rien poussé
comme métrique.
Ou par an,
je ne sais plus,
non,
c'est par mois,
5000 balles par an,
tu n'as rien poussé.
Et pour les utilisateurs
full plateforme,
on est à 349 par mois.
Alors,
je pense que ça doit être
les admins,
mais même sur les utilisateurs core,
sur des grosses équipes tech
où il y a 200,
300 personnes,
on ne peut pas dire,
allez,
il y a déjà 200 000 qui partent
ou je ne sais pas,
150,
200 000 par an
qui partent rien que
dans la licence,
sur les sites,
alors qu'il y a zéro user.
Enfin,
il y a zéro métrique encore,
il n'y a rien de poussé,
il y a zéro trace.
Et donc,
c'est ça le vrai problème.
Moi,
je reparte.
En fait,
moi,
je suis coincé.
Je n'ai pas envie de maintenir
la stack d'Observity.
Enfin,
ce n'est plus vraiment moi
qui la maintiens aujourd'hui,
mais quand même,
parce que c'est vrai que c'est du coup,
je suis vraiment tout à fait en accord,
les dashboards,
les alertes,
réinventer la roue en permanence,
mais qui peut payer ça ?
Qui peut payer NeuroDict at scale ?
Je ne comprends pas.
C'est ce que je disais tout à l'heure,
tu payes,
mais tu filtres.
Même en filtrant,
toi,
rien que les utilisateurs,
je ne peux pas filtrer et dire
tout le monde n'a pas accès à la plateforme,
tu vois ?
Bah si.
Les devs,
de toute façon,
les devs,
ils ne veulent jamais regarder.
C'est la faute des devs.
Ils ne veulent pas.
Non,
je ne suis pas d'accord,
mais surtout nous.
C'est tout le problème,
c'est que tu ne peux pas filtrer sur les users
parce que c'est dommage
parce que quelqu'un n'a pas les informations
dont il a besoin pour bosser.
Mais tu prends un graph Anaclote
qui a un pricing
qui est un poil plus simple,
mais en fait,
derrière,
quand tu discutes avec eux,
il n'est pas plus simple
parce que tu as plein de facteurs
qui peuvent rajouter des multiples
sur n'importe quel indicateur.
Moi,
je me rappelle,
pour l'anecdote,
une fois,
chez Datadog,
au tout début de la boîte
où je suis,
chez Farmance,
pour le coup,
on avait trois clusters cubes,
un staging,
un de,
enfin,
et deux de production.
Et en staging,
on activait le full log.
Donc,
ça débitait du log
à pleine balle.
On s'est amusé
pendant quelques temps,
pendant un petit moment,
on faisait des tests de perf,
machin,
etc.
Donc,
vraiment,
ça débitait,
Ah bah,
quand la facture de 12 000,
elle est arrivée,
le mois d'après,
on n'était plus chez Datadog.
C'est quand tu as
une facture mensuelle d'AWS
de 4 ou 5 000 euros
et que tu viens de te prendre
une facture de 12 000
de Datadog,
c'est injustifiable,
en fait.
Tu ne peux pas justifier
que ton petit monitoring
te coûte le double,
voire le triple
de ce que te coûte
ta plateforme de production
qui te rapporte
de l'argent techniquement.
Mais d'un autre côté,
le jour où on a fait ce choix
de quitter Datadog,
on a aussi perdu des choses
parce que le monitoring
était in fine
de meilleure qualité,
au moins dans un premier temps,
que ce qu'on a pu faire
nous-mêmes en un mois
parce que le temps
d'installer les outils,
de virer Thanos
parce que c'est tout pourri,
de virer Loki
parce que c'est tout pourri,
en fait,
tout ça,
tu perds du temps.
Tu adaptes après
à ton besoin,
à ton budget.
Tu peux aller acheter
une baguette de pain très vite
en prenant une Ferrari,
mais après,
ça te revient très cher.
Tu peux aussi y aller
à pied ou en vélo,
ça te revient moins cher,
mais ça te demande
de l'effort et du temps.
Et ça,
c'est dur aussi à savoir.
De un,
c'est très dur à estimer
parce qu'il ne faut pas
tomber non plus
dans le défaut,
je pense,
de power de métrique
parce qu'on retombe
dans le cas
où je disais tout à l'heure
où tu te retrouves
à avoir des coûts cachés
style les devs
qui débug des conneries
ou toi qui débug
des conneries d'infra
pendant des semaines
alors que ça pourrait
te prendre moins de temps.
Et dans un autre temps,
il ne faut pas vouloir
aller trop loin,
on va dire trop vite
et ne pas claquer
tout le budget
pour un monitoring fancy
mais tout le reste
qui ne va pas.
Et c'est très dur à juger.
Pour le coup,
ça,
c'est des décisions
pour moi
qui sont un peu
ce que j'attends
on va dire
d'un CTO
ou en tout cas
quelqu'un un peu
avec ce type
on va dire
de rôle
dans la plupart des sociétés
ou pas toutes
mais c'est quelque chose
qui est un exercice compliqué
de savoir
quand investir dedans,
quand arrêter d'investir,
quand se dire
là c'est bon,
on a cette chose,
là ce n'est pas bon,
ce n'est pas satisfaisant,
ça demande beaucoup de temps
mais moi,
ce que j'espère
en tout cas au niveau
des alerting et tout ça,
ce que j'espère,
ce que je suis curieux de voir
en fait,
c'est que je me dis
tout ce qui est dashboard,
c'est chronophage.
Franchement,
on a parlé des alerting,
moi je trouve
que les dashboards,
c'est pire.
Il n'y a rien de plus dur
que de faire sur Grafana,
alors j'ai quelqu'un
chez Waze
qui est le fondateur
qui est très bon là-dedans
mais c'est ultra,
en fait,
on se rend compte
que c'est ultra chronophage
de faire un dashboard
qui soit parlant
pour les gens
qui vont le lire,
qui remonte les bonnes métriques,
qui soit lisible
et qui ne noie pas l'information.
C'est un exercice
qui est bien plus dur
je trouve
que les alertes.
Les alerting,
on peut adapter,
on part toujours
sur un seuil
de quelque chose,
une agrégation de métriques
ou des choses comme ça.
On arrive toujours
plus ou moins à quelque chose
et après,
on l'adapte avec le temps
parce que les métriques,
les alertes,
ça se travaille beaucoup
je trouve,
beaucoup plus.
Mais les dashboards,
c'est une horreur
et c'est très dur
d'avoir du feedback dessus.
Les gens ne viennent pas
naturellement dire
j'ai été voir ce dashboard,
il n'y avait pas d'info là
donc je l'ai rajouté
ou est-ce qu'on pourrait
voir ensemble pour le rajouter ?
Les gens n'ont pas ce réflexe
donc tu te retrouves
à des fois
te rendre compte
deux mois après
que le dashboard super beau
que tu as fait,
tu étais content et tout.
En fait,
les gens ne l'utilisent pas.
Pourquoi ils ne l'utilisent pas ?
Parce que eux,
ce qu'ils voulaient,
c'était l'info X
qu'ils ne t'ont pas demandé avant
parce qu'ils n'y ont pas pensé
mais il n'y a personne
qui a pensé à te remonter l'info
et je trouve que ça,
c'est le plus gros souci.
Ou voire,
ils ne savent pas
que le dashboard existe.
Ou qu'ils ne savent pas
mais ça,
c'est un problème de com
plus général.
C'est un problème de com
sur ce qui existe
mais c'est des vrais problèmes
qui sont chronophages
mais pour le coup,
c'est aussi des problèmes
qui existent un peu
on va dire sur du Datadog
ou autre
à partir du moment
où tu n'as pas les infos.
Moi,
tu sors des dashboards génériques
parce que les dashboards génériques
sont bien
mais il y a forcément
un moment
où tu sors pour 2-3K
tu vois notamment,
tu vois Mathieu,
tu parlais des métriques
un peu métier.
En général,
ça,
ça va être sur des trucs
vraiment très custom.
C'est surtout,
moi,
ce que je vois aussi
sur les dashboards,
c'est qu'au bout d'un moment,
le graphana,
il est bloated.
En fait,
les gens,
ils ont créé
150 000 dashboards.
Il y en a 15
qui font la même chose
plus ou moins,
qui ont déforqué,
etc.
Et en fait,
il faut,
si dès le début,
il n'y a pas une consistance
forte avec même des normes,
des conventions de nommage
sur les métriques,
les labels
pour pouvoir avoir
des dashboards
partagés entre applications,
même entre langages,
je parle.
Mais voilà,
toutes les requêtes HTTP
s'appellent pareil,
toutes les métriques HTTP,
Kafka,
des spans,
etc.
Enfin,
tout soit standardisé
assez fortement
avec des dashboards de qualité,
avec des honneurs.
C'est sympa à envrer.
Mais ça,
on le voit aussi
sur d'autres outils.
Mais oui,
c'est très complexe.
C'est très complexe
ce qu'on observe ici.
Et c'est vrai qu'en réalité,
il y a assez peu de personnes,
je trouve,
sur le marché
qui ont vraiment
l'expérience complète,
c'est-à-dire sur ce sujet.
C'est-à-dire qu'ils ne sont pas
capables de proposer
une vision
avec,
connaît bien
les différents outils,
les avantages,
les inconvénients,
même les principes derrière,
pas seulement les outils,
mais tous les principes
et même un peu parfois les maths.
On parlait des histogrammes
pour Météus.
Définir des buckets
pour Météus.
On parlait du coup
pour les devs,
l'implémentation,
enfin,
qu'est-ce que ça demande
par rapport à un agent
comme Datadog, etc.
Rien que choisir
les bons buckets,
c'est compliqué.
Parce que des buckets
dans Météus,
ça fait des approximations
ensuite quand on fait
des quantiles.
Les approximations sont calculées
d'une certaine manière
en fonction de la taille
de chaque bucket,
etc.
Donc ça a des impacts
en fait.
Et ça,
c'est des choses,
c'est dur d'avoir
de trouver aussi
des profils
qui connaissent bien tout ça.
Après,
il y a quand même
des trucs qui me manquent
dans la stack open source.
Je veux bien savoir
comment vous faites vous.
Mais par exemple,
à l'époque,
j'utilisais Datadog.
Un truc que j'utilisais énormément,
c'était leur feature
de notebook.
En gros,
l'idée,
c'est que vous avez
un incident
ou vous êtes en train
d'investiguer sur un truc.
Plutôt que d'avoir
40 000 onglets
ouverts en permanence,
grosso modo,
tu te lances dans un notebook,
c'est une espèce
de page Notion,
dans lequel tu peux venir
faire des graphes,
prendre des graphes,
etc.
Mais en fait,
tout est figé
sur la plage de temps
où tu as fait ta requête.
Et donc,
c'est ultra pratique
parce que par exemple,
tu es en train
d'investiguer un incident.
En fait,
le mec qui a réglé
le problème le soir,
par exemple,
s'il a tout bien figé
dans le notebook,
toi,
tu arrives dans le notebook,
tu as toutes les informations
qui lui ont permis
de retrouver l'information
et de là,
tu peux aller chercher
des informations supplémentaires,
etc.
Mais tout restera figé
dans ce notebook.
Et typiquement,
en open source,
je ne connais aucune solution
qui me permet
de faire ce genre de truc.
Et pour autant,
c'est ultra utile.
Mais pour ça,
il faut un environnement
hyper convergé.
Et c'est ce que ne propose
pas la partie open source
parce que même si
tu es full solution graphana,
tu as quand même
des trous dans la requête,
tu as quand même
des trucs que tu n'as pas.
Et chez Datadome,
la data est quand même
beaucoup mieux utilisée.
Enfin,
typiquement,
tu pousses déjà
tes logs,
tes traces,
tes métriques,
tu cliques sur un bouton,
bim,
tu as une partie sécurité
qui arrive avec
une espèce de CM léger,
mais une espèce de CM
qui arrive.
Alors,
ils n'oublient pas
la facturation en parallèle,
mais c'est ce côté-là
qui fait qu'ils arrivent
à signer après
des gros clients,
Mathieu.
C'est qu'en fait,
tu n'y vas pas juste
pour tes logs,
métriques et traces,
tu y vas aussi
pour la partie sécurité,
pour la partie
débug plus facile,
etc.
Et en fait,
tu t'enlèves ce côté
juste métrique,
traces et logs
et tu es prêt à accepter
de payer cher,
entre guillemets,
parce que ça t'apporte
d'autres choses
et un jeu de responsabilité aussi.
Tu n'es plus responsable.
Peut-être que les SaaS,
c'est peut-être bien
pour les tout petites boîtes
qui n'ont pas trop de métriques,
peu de signaux,
ou les énormes grands groupes
qui s'en foutent
de payer globalement.
Comme tu dis,
ils prennent le gros paquet
de jolines
avec un méga contrat
et puis voilà.
Mais les 90% des gens
qui sont au milieu,
galèrent.
C'est peut-être ça aussi le truc.
Je parlais de type d'entreprise
au début.
Pour moi,
un Datadog,
la relation commerciale
que j'avais avec eux
à l'époque
où on était vraiment tout petits,
on était quatre dans la boîte,
ils ne savent pas gérer.
Pour moi,
Datadog,
ça a peut-être changé
en deux ans,
trois.
Mais ils ne savent pas
gérer des relations
avec des petits comptes.
Tu n'as pas besoin
d'entretenir une relation
avec un petit compte,
c'est du sas.
Un petit compte,
il va te servir quoi ?
Parfaitement bien.
AWS,
j'ai des calls de synchro
avec eux tous les trimestres.
Des fois,
ça dure 15 minutes,
des fois,
ça dure une heure
et ils s'intéressent
à savoir où est-ce qu'on en est,
est-ce qu'ils peuvent nous aider
sur certains sujets,
est-ce qu'on peut faire
de l'IA avec eux,
etc.
Tu crées une relation
sur l'avenir.
En fait,
si ton partenaire
t'a travaillé avec lui,
etc.,
même s'il te coûte cher,
tu n'auras pas envie
de le quitter en fait
parce qu'il t'apporte d'autres choses,
parce que tu as une relation
avec lui
et l'humain joue
quand même vachement.
Oui,
je comprends.
Et les Datadogs,
ils sont incapables
de créer cette relation humaine.
En tout cas,
aujourd'hui,
à l'époque,
ils en étaient incapables
avec des petits comptes.
Par contre,
quand j'étais dans
des très grosses boîtes
qui ont utilisé Datadog,
je faisais une très bonne
relation avec eux,
on avait nos calls
très souvent,
etc.
Mais c'est des stratégies
de boîte après,
c'est des vraies stratégies
de boîte de choisir.
Oui,
c'est vrai qu'Amazon,
ils sont forts là-dessus,
une très bonne relation avec eux.
Mais je crois,
même moi,
c'est Dailymotion
qui tourne avec full Datadog
et il me semble
que ça leur coûte cher
et je crois qu'ils ont fait
un rex dessus
mais qui marche
très très bien.
Après,
moi,
je n'ai jamais connu
personne dire
que Datadog ne marchait pas
ou mal.
Moi,
c'est même vrai
avec Datadome
ou des trucs comme ça,
des solutions
qui sont très puissantes.
Après,
du coup,
pour un peu,
parce que je pense
qu'on a fait un peu
le tour de tout ça,
j'ai un peu
fait une ouverture
sur un sujet
où certains auditeurs,
bouchez-vous peut-être
les oreilles,
mais on parlait un peu
des difficultés
sur les dashboards,
la herting et tout ça
et on parlait un peu
tout à l'heure,
Mathieu va parler
des ouvertures
qui sont vraies,
notamment sur les solutions
comme EBPF
et tout ça
pour le tracing
et un peu,
on va dire,
une standardisation,
une amélioration
de tout ça
pour simplifier tout à terme
et un sujet
qui revient souvent
en ce moment
qu'il y a,
est-ce que vous ne pensez pas
sur toute cette partie
vraiment,
pour faire le tri
dans les métriques,
faire des dashboards
qui soient intéressants,
faire de l'alerting
qui soit pertinent,
ça n'a pas un rôle à jouer
parce que moi,
si on parle d'une grosse
quantité de données
qui est à analyser,
à en retirer quelque chose
et à extrapoler
pour pouvoir faire sortir
un truc,
je me demande
si ça ne serait pas
un peu la chose
qu'on attendrait à terme.
Moi, sur ça,
j'ai un vieux rêve
mais qui va encore plus loin
que l'IA
parce que je pense
que l'IA,
en tout cas,
l'IA,
elle est l'aime,
elle n'apportera pas
grand-chose sur ça.
Par contre,
je ne comprends pas
qu'aujourd'hui,
nos stacks de monitoring
ne soient pas blindés
de machine learning.
Moi, je rêverais
de ne plus avoir
des alertes
parce qu'il y a
un truc qui ne marche pas
mais avoir des alertes
parce que le système
a détecté que
ça, c'était un peu chelou,
ce n'est pas dans
les scats d'habitude
et bim,
je reçois une alerte
et en fait,
je suis proactif.
Typiquement,
c'est ce que je faisais
à l'époque
chez la centrale
avec AWS.
On utilisait CloudWatch
et il y a une partie
machine learning
dans CloudWatch
qu'on peut activer
en échange
d'un petit peu de pesos
et pour le coup,
combien de fois
ça nous a sauvé ?
La centrale a un trafic
très prédictible.
La nuit,
très peu de trafic.
Les journées,
beaucoup de trafic.
Dès qu'ils font
des pubs télé,
gros pic de trafic,
c'est très prédictible
et donc,
pour le coup,
le machine learning,
ça marche extrêmement bien
et il y a des fois,
on s'est pris des pics
et en fait,
on a toujours réussi
à retrouver
pourquoi il y avait eu
ce pic-là
et c'était toujours
des choses de
ah, en fait,
il y a une pub
qui a été signée
au dernier moment
et on n'avait pas été
encore au courant.
Bon, une fois que c'est passé,
ça ne sert plus à être au courant
mais c'est des choses comme ça
et on a toujours pu retrouver
et le monitoring,
en fait,
on n'avait plus du tout
un monitoring
entre guillemets
de réactif.
Il y a un problème,
on avait un monitoring
préventif
qui venait vraiment
nous alerter
quand on sortait
des seuils,
des machins,
etc.
Et même sur des trucs
assez bêtes,
on avait des alertes
sur le nombre
d'annonces,
etc.
qu'on avait mis
dans CloudWatch
et c'était juste
trop bien.
Mais aujourd'hui,
par exemple,
en open source,
je crois que le seul
qui permet de faire
à peu près ça,
c'est l'instaculastique
si ils ont un modèle
de machine,
enfin,
ils ont une partie
de machine learning
intégrée.
Mais par exemple,
chez Grafana,
ça n'existe pas.
Je crois que chez Datadog,
il y a quelques trucs
qui font un peu
comme AWS.
Mais moi,
j'aimerais,
enfin,
si on parle d'IA,
etc.,
de data,
pour moi,
le monitoring,
on devrait avoir
de la data
et du machine learning
à pleine balle
partout là-dedans.
Et moi,
les dashboards,
je ne suis pas
un grand fan
de dashboards.
Je ne regarde pratiquement
jamais.
Par contre,
avoir une IA,
data,
appelle-la comme tu veux,
machine learning
ou autre
qui me trouve
les problèmes
et qui peut même
me les corriger avant,
là,
tu peux prendre
ma CB
ou mon compte bancaire
en direct.
Si derrière,
tu réduis
mes incidents,
etc.,
je signe
avec un très grand plaisir.
Alors,
mon avis sur
ça,
c'est que finalement,
le préemptif,
etc.,
c'est déjà possible
d'une certaine manière
avec des SLO.
Si on calcule
un error budget
avec un burn rate,
ça permet de rapidement
détecter,
en théorie,
des déviations,
on va dire,
des rés erreurs
qui commencent à monter
avant que ça devienne
critique.
Mais c'est vrai
qu'il n'y a pas
cette notion
d'auto-apprentissage.
Moi,
l'IA sur le monitoring,
je la vois sur deux parties.
On parlait tout à l'heure
de la difficulté
de trouver des dashboards,
de trouver des docs.
Parce qu'il y a bien sûr
de trouver pourquoi
il y a le problème,
mais aussi comment le résoudre
quand on est en incident,
notamment en astreinte.
Et c'est vrai que moi,
j'y pensais d'ailleurs récemment.
J'aimerais bien des fois
quand je reçois
certaines alertes,
que le truc soit capable
de me dire,
ah bah tiens,
cette alerte-là,
basée sur la doc,
basée sur les incidents,
parce qu'on documente
énormément nos incidents,
les incidents précédents,
etc., etc.,
boum,
il y a déjà des guides,
des liens vers certains dashs,
certaines commandes.
On a beaucoup
d'outillages internes,
donc certaines commandes
pour éventuellement...
Enfin, voilà,
déjà des suggestions,
en fait.
Un bot d'aide,
on va dire,
à l'investigation
qui, à partir des alertes
et de certains signaux,
arrive à faire sortir
une théorie
de qu'est-ce qui se passe.
Ça, c'est un truc
qui, je pense,
serait déjà intéressant,
qu'on n'a pas aujourd'hui,
je pense,
mais qu'éventuellement,
on pourrait.
C'est des trucs
sur lesquels j'ai réfléchi.
Et sur la partie
apprentissage auto,
pourquoi pas,
mais après,
il faut voir comment
ça se matérialise,
en fait.
Parce que c'est vrai que...
Je reviens sur l'histoire
des SLO,
mais en fait,
je pense que les SLO,
c'est un outil
qu'on n'utilise pas assez
dans l'industrie
parce que c'est assez simple,
en fait,
conceptuellement.
Et ça permet déjà
de voir beaucoup de choses
avec des formules
vraiment simples.
Détecter des problèmes
en amont,
même de réfléchir
à c'est quoi un comportement,
on va dire,
un comportement anormal.
Parce qu'il y a ça aussi,
même avec du machine learning,
c'est quoi mon seuil ?
Oui, je peux comparer
à la semaine dernière
ou au mois dernier,
mais est-ce que ça sera pertinent ?
Est-ce que, par exemple,
si je passe de 100 millisecondes
à 150 millisecondes,
est-ce que c'est grave ?
Peut-être,
peut-être pas, en fait.
C'est un peu ça aussi
la difficulté du machine learning,
c'est quand est-ce qu'on déclenche
parce qu'on n'a pas
de fausses alertes
ou des choses comme ça.
C'est là où,
enfin,
si je reviens sur ce que tu disais,
pour moi,
on pourrait très bien avoir
du machine learning,
peu importe,
qui fait de la corrélation
parce que
combien de fois
tu as une alerte
sur un truc B,
mais en fait,
c'est toute la chaîne
qui était en souffrance
et qui n'avait pas
d'alerte dessus
et B n'est que
le dernier maillon
et qui, lui, par chance,
était monitoré
mieux que les autres
et donc ça peut être,
mais en fait,
tu n'as rien à faire sur B,
il faut régler la chaîne en amont
et ça, des fois,
avant de le comprendre
et de le voir,
si tu n'as pas l'expérience
et que tu n'as pas déjà eu
ce genre de problème-là,
en fait,
tu vas mettre un temps immense
et ça, pour moi,
c'est le système de monitoring
qui devrait dire
ben voilà,
ta DB, elle est en souffrance
mais en fait,
je vois aussi une augmentation
du trafic,
je vois que tu n'as que Kafka
et elle est en train
de dépiler comme un cochon.
Je ne sais pas
si c'est une bonne information
ou une mauvaise information
mais je te donne une information
et après,
toi, humain,
traite,
si déjà,
on avait ça,
je ne sais pas combien d'heures
on pourrait gagner
sur des problèmes
mais on en gagnerait beaucoup
et après,
moi,
je pense surtout
qu'aujourd'hui,
en tout cas,
sur la partie open source,
je trouve ça pratiquement honteux
qu'on se pose encore
certaines questions
du genre
comment monitorer
un cluster cube,
par exemple.
Tu vois,
ça devrait être réglé,
tu vois,
comme,
en fait,
on peut critiquer
un agios,
etc.
à l'époque
mais un agios,
tu arrivais,
tu activais ton SNMP
et tu avais ta sonde
CPU,
RAM,
disque,
etc.
Alors,
tu n'as peut-être pas
des bons indicateurs,
on l'a appris
avec la suite
mais au moins,
tu ne te posais pas la question.
Ton agios,
il démarrait
et day one,
tu avais un truc
qui marchait
et qui t'apportait
déjà de la plus-value
et aujourd'hui,
alors tu installes
ton Prometheus,
tu installes ton Loki
et tu installes ton Tembo
et bien,
en fait,
ils ne font rien,
ils ne servent à rien,
ils n'apportent rien
et je trouve que sur ça,
c'est un retour en arrière
qui est juste énorme
et que,
en fait,
ça devrait arriver
built-in avec
tout un tas d'alertes
que tu peux désactiver,
modifier,
etc.
Bien sûr,
il ne faut pas forcément
les laisser comme ça.
Il y en a certaines,
il y en a plein
qui ne seraient pas
bénéfiques à ton business
mais en fait,
tout,
presque,
j'attendrais presque
des triflicks,
etc.
quand je l'installe
qui me créent
des Prometheus rules
directement
et qui me disent
voilà,
tout en fait,
pourquoi moi,
je devrais me faire chier
à savoir
qu'est-ce qui fait
que mon triflick
ne marche pas bien.
C'est qui l'éditeur ?
C'est qui qui fait le ?
Propose-moi des trucs.
Fais-moi un référentiel
de toutes les aires.
Tu en as
qui le mettent
dans les short-term ?
Oui,
mais c'est très,
très peu au final.
Ah oui,
je te dis pas le contraire
mais c'est vrai qu'il sait.
Ça devrait être
practice en fait.
C'est ce qui fait
que pour moi,
le monitoring reste
le truc,
c'est un truc de vieux.
On fait semblant
qu'on a des technos récentes
et tout ça
et en fait,
c'est pourri.
Moi,
je trouve ça pourri.
Combien de fois
j'ai vu des boîtes
où leur alerting,
c'était juste
un call HTTP
qui est fait par le time robot
toutes les minutes
sur leurs API
et le truc,
il détectait des problèmes
avant que leur super monitoring
détecte quelque chose.
Après,
tu rentres dans un truc
qui est vraiment
plus monitoring
qui est qu'à un moment,
tu veux éviter les flaps,
tu veux éviter
les fausses alertes,
tu veux éviter plein de trucs
et du coup,
tu t'adaptes mal,
tu fais trop d'un côté,
trop de l'autre
et en fait,
tu te retrouves dans un état
où c'est un ajustement permanent.
Oui,
mais en fait,
tu devrais,
à mon sens,
avoir le marché
qui te dit
voilà,
entre guillemets,
par défaut,
si tu as une des requêtes HTTP
qui répondent au-dessus
de 500 MS,
c'est un problème.
Après,
tu adapteras,
tu vois.
Et là,
on n'en a même pas
ces informations-là aujourd'hui.
Je suis d'accord
d'un côté
et d'un côté non
parce qu'une requête
qui met 500 MS,
certains vont te dire
c'est la catastrophe absolue.
Tant à d'autres,
ils seront en mode
non mais ça,
c'est un truc,
je m'en fous,
je m'en fous totalement.
Moi,
je connais des gens
qui sont sur des topics
industriels,
etc.
où c'est 500 MS
mais on s'en fout
parce que derrière,
ça n'a pas de conséquences
ni rien.
Par contre,
ils ont un autre critère
un peu à la con
qui pour eux
est super important.
Pour simplifier,
je pense que c'est ce que je dis.
Pour moi,
tout ce qui est
outils,
open source,
Nen,
GNX,
on ne devrait même pas
avoir à se poser la question
de l'alerting,
etc.
Il devrait y avoir
un truc built-in.
On fait clic-clic,
bim,
ça marche
et après,
on adapte
et on devrait se concentrer
que sur la partie métier.
Tout ce qui n'est pas
de l'infrastructure,
tout ce qui est spécifique
à ton métier,
on devrait se concentrer
que sur ça
et arrêter de perdre du temps
à faire des règles
pour avoir les erreurs
à 500
sur ton load balancer,
etc.
C'est juste
on te fait exister encore.
Je suis d'accord
que c'est un énorme effort
aujourd'hui
de créer une stack
de servilities on-prem
même sur des technos
standards sur le cloud.
On parlait de Kubernetes
mais c'est pareil
si vous faites du post-grade,
Kafka et tout,
il faut recommencer
de zéro à chaque fois.
Nous,
on a open source des trucs
notamment sur RDS,
parce qu'on essaye
de partager.
Mais globalement,
c'est un énorme effort.
C'est un effort
qui dure plusieurs années
et même au bout
de plusieurs années,
vous vous prendrez des murs.
Il y a quelques temps,
on a eu un incident
sur un cluster Kubernetes
qui n'était pas critique
où il y a eu un bug
dans Kiberno.
Il y avait un script
qui était buggé,
un script de cleanup
de la charte Kiberno
qui vient d'eux-mêmes
qui fait que les admissions
n'enlaient quoi.
Je ne sais plus,
il y avait une ressource
sur le nombre de ressources
dans le cluster
et à un moment,
le cluster a crashé.
Quand je dis crashé,
c'est-à-dire que le cluster
était quasiment irrécupérable
parce qu'on avait,
je ne sais plus,
700 000,
800 000 ressources Kiberno
et à un moment,
boum,
d'un coup,
le cluster est passé
de je marche
à je ne marche plus.
Et le truc,
maintenant,
on a l'alerte,
c'est cool,
mais en fait,
voilà,
personne,
c'est une métrique obscure
de l'API serveur
qui permet de détecter ça.
Il y a deux personnes
sur Google
qui la documentent
et encore,
c'est un truc
si on ne s'est pas pris
le mur un jour.
Et ça,
on le voit,
moi,
je l'ai vu pendant des années,
ça,
en fait.
C'est que l'expérience
qui permet de créer le...
Il faut déjà avoir
une expérience
de la brique open source
pour pouvoir créer l'alerting,
sinon,
vous prendrez des méga murs
parce que même sur Internet,
il y a très peu de contenu,
en fait.
Si vous regardez
comment on monitorait
du cube sur Internet,
vous allez trouver des trucs,
mais vous aurez à lire
50 articles de blog disparates
et encore,
il n'y aura pas tout.
La moitié,
les alertes ne seront pas bonnes,
il y aura des record rules
qui ne seront pas bonnes,
en fait,
ce sera bugué,
il y aura des problèmes
de cardinité,
parfois,
je ne sais pas quoi,
enfin bref,
il y a toujours des problèmes
et c'est un coup monstrueux,
mais on revient sur...
Moi,
je tourne en boucle sur
je n'ai pas envie de faire ça,
mais je n'ai pas le choix
parce que le ça,
ça coûte cher,
voilà.
En fait,
je suis dans une boucle infernale,
je suis désolé,
je ne sais pas quoi dire d'autre,
en fait,
je ne sais pas quoi dire d'autre.
Mathieu nous renvoie au début.
C'est vraiment ça,
c'est vraiment ça.
Maintenant,
vous reprenez votre curseur,
vous le remettez à 5 minutes
et vous pouvez réécouter.
C'est la fameuse technique
qui est aussi utilisée sur TikTok,
comme ça,
ça revient au début,
les gens ne remarquent pas,
ça fait du listen time.
Mais en tout cas,
je pense qu'on a fait
un bon petit tour du sujet,
un sujet qui,
au final,
est quand même intéressant,
même si ce n'est pas forcément
un sujet qui monopolise
les discussions sur Twitter,
mais on gagnerait peut-être plus
à échanger des fois là-dessus
que sur pourquoi Bash
doit rester dans le monde du cloud
ou pourquoi Kubernetes
a été un peu plus
à échanger des fois là-dessus.
Ça ajoute de la complexité
à mon bar métal,
mais bon,
ça,
c'est,
on va dire,
encore une digression.
Est-ce que vous avez
un petit dernier mot à dire
avant de laisser,
du coup,
à nos auditeurs
et auditrices ?
Oui,
je peux commencer,
allez.
Bon,
on a beaucoup critiqué
le monde du monitoring
aujourd'hui,
à raison,
je pense.
Il n'y a pas de solution magique,
malheureusement.
Il y a des avantages
et des inconvénients
un peu partout.
Mais je voulais quand même dire
que c'était un domaine
qui me passionne quand même.
Je travaille dessus
depuis le début de ma carrière.
Je continue de travailler
énormément dessus.
C'est pour moi un point.
En fait,
l'observabilité en général,
pas que l'infra,
mais métier,
etc.,
l'exploitation de toutes ces métriques,
en général,
c'est quelque chose
qui peut amener
une énorme plus-value,
on va dire,
pour l'entreprise.
Et donc,
ça reste un domaine
avec beaucoup de choses à faire.
Je suis sûr qu'on verra
beaucoup d'évolutions
qui évoluent également
très, très, très vite.
On n'a pas le temps
d'en parler là,
mais c'est un domaine
qui évolue beaucoup.
Des nouveaux standards,
des nouvelles manières de faire,
des nouveaux outils.
Donc,
bon,
on reste positif
et bonne chance
pour tous les SRE,
OPS,
ou les gens de l'infra
qui maintiennent ces stacks-là
parce que c'est vrai que c'est...
De mon côté,
ce serait plutôt une question.
Je serais vraiment curieux
que les gens nous disent
sur Twitter ou autre,
mais on est principalement
tous les trois sur Twitter.
Je serais vraiment curieux
de savoir leur avis
déjà sur leurs stacks
de monitoring,
sur les outils SaaS,
etc.,
et voir si les gens
partagent notre avis
sur la préhistoire
de toute cette histoire
ou est-ce que
c'est juste
qu'ils vont trop fumer
et pourtant on est clean ?
C'est une bonne question.
N'hésitez pas à nous répondre
sur Twitter,
en commentaire,
directement sur
les différentes plateformes
et puis on regardera
ça attentivement.
Moi, de mon côté,
comme je disais,
je pense qu'on se tire
un peu les cheveux
parce que le sujet
nous intéresse
et parce qu'on sait
l'importance que ça a
donc on creuse beaucoup.
Mais je pense quand même
que les choses,
au fond,
s'améliorent petit à petit.
C'est juste qu'il y a
un effet de scope
et qu'on est quand même
de mieux en mieux là-dessus
et que ça va continuer
dans cette voie-là.
Donc on va dire
que je suis quelqu'un
d'optimiste là-dessus
et j'espère qu'on va
continuer de ce côté-là.
Donc n'hésitez pas aussi
à nous suivre.
Du coup, pour cette nouvelle saison,
on va parler comme toujours
de plein de petits sujets tech
qui nous font discuter
et qui nous passionnent
entre nous et avec,
bien sûr, des invités
comme à la saison précédente
et on va essayer d'ajouter
plein de petites choses
cette saison,
changement de générique
comme vous l'avez entendu
et aussi à terme
du live possiblement.
Donc n'hésitez pas
à nous suivre
et je vous dis
à la prochaine !
Sous-titrage ST' 501