Pourquoi votre monitoring est inefficace ou trop cher ? - S02E01

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,

du tout,

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,

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,