C'est quoi un problème de performance ? Comment est-ce qu'on mesure les performances d'une application ?
Qu'est-ce qu'il faut éviter quand on fait ça ?
Ce podcast est là pour t'aider si tu as des problèmes de perte sur tes applications.
Bienvenue sur Radio DevOps, la balade aux diffusions des compagnons du DevOps.
Si c'est la première fois que tu nous écoutes, abonne-toi pour ne pas rater les futurs épisodes.
C'est parti !
Bienvenue à toi chers compagnons dans ce nouvel épisode de Radio DevOps,
l'émission où on rentre dans un sujet en particulier.
Et aujourd'hui on va parler de performance.
Et cet épisode est une suite et un complément de Radio DevOps n°6
qui parlait de la supervision d'une infrastructure cloud.
Donc si tu ne l'as pas écoutée, arrête-toi tout de suite,
je ne sais pas ce que tu fais là, va écouter l'autre épisode, puis reviens.
Si tu l'as déjà écoutée, ça ne fait rien, tu peux le réécouter,
ça ne fait pas de mal à un petit rappel.
Pour parler de ça avec moi, j'ai une équipe au top de la performance avec René.
Bonsoir René.
Bonsoir Kessoff, bonsoir à tous.
J'ai aussi Nicolas, bonsoir Nicolas.
Salut à tous.
Et enfin Mathieu, bonsoir Mathieu.
Bonsoir.
Si tu apprécies le podcast ou si tu viens d'arriver sur ce podcast,
tu peux t'abonner au podcast ou à la chaîne YouTube
si tu préfères voir nos petites bouilles.
Et puis tu peux activer la cloche sur YouTube pour être lié des sorties.
Et puis si tu suives le podcast, tu peux le partager
parce que ça aide justement le podcast à se diffuser.
Alors j'aimerais qu'on parle un petit peu avant qu'on commence
de notre rapport à la performance et surtout
si chacun d'entre nous pouvait brièvement se présenter
ou est-ce qu'on travaille, quelle expérience on a de la performance,
c'est quoi notre rapport avec les problèmes de performance
et les outils de performance en quelques mots ?
Est-ce que Nicolas, tu veux bien commencer s'il te plaît ?
Oui. Alors moi, je travaille chez C.J. Weier.
Donc on développe une application
pour fiduiter le travail des studios d'animation de D3D.
Et en fait, je suis aussi freelance à côté
pour l'infogérance de plateforme.
Et d'ailleurs, C.J. Weier est un des anciens clients qui m'a empoché.
Et mon rapport à la performance,
depuis 2001, je travaille sur des infrastructures plus ou moins grosses
avec des clients plus ou moins gros,
mais avec des infrastructures qui sont aussi cries pas mal de charges.
J'ai déjà eu quelques applications qui se sont retrouvées
dans des pages de pubs sur des chaînes de grande écoute.
Donc j'ai vu l'infrastructure qui s'emballait
avec des lots de verre-age qui montaient à s'envoler à crever des plafonds
avec un terminier de l'SSH qu'on ne pouvait plus rien faire
et le client qui paniquait.
Mais quand il regardait son compteur de connexion sur Google Analytics,
il était très content parce que ça montait, ça montait, ça montait.
Et en fait, ça plafonnait jamais et de sites répondaient,
ça marchait inutile, etc.
Donc en fait, j'ai eu différentes étapes dans tout ça.
C'est, j'ai eu à la fois des incidents de performance
où tu te lèves un matin, c'est lent, tu sais pas pourquoi,
et ton client t'appelle, il est totalement en panique,
il court dans tous les sens parce qu'il perd du chiffre d'affaires
parce que l'application ne répond pas,
il y a des clients qui veulent se barrer.
Et j'ai aussi eu de certaines migrations
où on savait que l'application avait énormément de charges
et quand je dis énormément de charges,
c'est plusieurs millions de visiteurs par mirores,
je ne sais plus exactement.
Mais bon, en gros, la machine s'entremet vraiment plus dans la tête.
Et pour préparer les migrations,
il fallait prendre en compte la performance.
Donc, tu dois réinstaller des nouvelles plateformes
et tester, voir si avec une charge à peu près équivalente,
on avait des meilleures performances ou pas.
Voilà pour moi.
Eh ben merci.
Est-ce que, René, je vais prendre la suite
et te présenter en quelques mots
et puis ton rapport avec la performance ?
Oui.
Donc, on ne travaille plus trop dans ce domaine-là
parce qu'en début d'année, j'ai rejoint la société Red Hat.
Donc, je fais plutôt du développement actuellement
sur un produit clone qui s'appelle OpenStack,
ceux qui connaissent.
Je pense qu'ils sont nombreux, ceux qui suivent ce podcast d'off-connêtres.
Mais oui, moi, j'étais plutôt confronté
dans mes expériences précédentes
où j'étais plutôt orienté Ops,
Admin,
Admin System et Stokage.
Et alors, je n'ai pas forcément eu trop de problèmes
liés à des grosses consommations
liées à des gros sites internet,
mais plutôt des problématiques suite
à des modifications d'environnement,
soit donc des ménagements de data center,
des changements d'infrastructure
qui ont induit des problèmes de performance à ces moments-là,
ou pas mal de problèmes de performance aussi
qu'on a voulu mettre en place un certain nombre d'applications.
Et au début, qui n'était peut-être pas forcément calibré correctement
ou qu'il y avait un certain nombre de défauts dans le code,
qui faisait que ça ne se passait pas très bien,
donc un petit peu ce que Nicolas expliquait,
des lenteurs qui rendent l'application quasi inutilisables
ou des batchs qui ne se cherchent pas dans des temps voulu.
Voilà, j'ai eu pas mal de choses comme ça
ou des modifications réseaux qui impactent la latence, etc.
Et Mathieu, à toi de me dire un petit peu ton rapport.
Alors moi, je travaille chez Konto.
Je suis serreux chez eux, donc Konto, c'est une grosse start-up française,
on va dire dans le domaine bancaire et financier.
Et je n'ai pas vraiment eu d'énormes problèmes de perte,
faut me dire, je n'ai pas connu dans ma caillère d'environnement
comme Nicolas avec des millions d'utilisateurs par minute,
ou je ne sais pas quoi, enfin voilà,
au passé à la télé ou autre.
Même si quand même, aujourd'hui,
je travaille quand même dans une grosse start-up
avec beaucoup de clients, etc.
Par contre, je travaille beaucoup sur des problématiques de perte
et notamment sur comment détecter et trouver
les problèmes de perte pour les applications du quotidien,
c'est-à-dire pas forcément avec des millions d'utilisateurs,
mais après des relises, par exemple,
voir les dégradations de performance,
après la relise d'une application,
ou bien voir sur telle fonctionnalité que les pertes ne sont pas top,
parce qu'il faut savoir que des services en ligne,
bien sûr, il y a l'aspect épique de charge, etc. à gérer,
il y a aussi l'aspect de la perte faux quotidien
sur le fonctionnement normal de la plateforme
qui est très important pour les clients,
parce que si c'est lent, le client est vailleurs, souvent,
ça se passe comme ça,
et si c'est très lent, ça plante, ça te ment, etc.
Ça peut vraiment causer des problèmes sur la plateforme,
des problèmes applicatifs faux.
Et donc moi, c'est plus de la perte sur ces sujets-là,
sur vraiment de la perte applicative et sur du mundo,
enfin, on ne va pas faire la redite du podcast monitoring,
mais sur trouver les moyens de corriger de la perte
des problèmes de performance,
ou même détecter déjà sur des applications,
parfois aussi sur des applications internes chez SRE,
je fais par exemple du Prometheus ou des outils comme ça,
et c'est les outils,
pourtant, qui sont des outils monitoring,
on a parfois aussi des problèmes de perte,
pareil pour Kubernetes, pareil pour des choses comme ça,
et donc c'est aussi travailler sur l'activisation de la perte,
ou de la consommation en mémoire,
ou des choses comme ça, sur ce genre d'it,
pour éviter une dégradation des performances,
ou autre.
Eh bien merci.
Merci.
Et moi, je travaille chez Lidra,
je suis l'un des co-fondateurs de Lidra,
qui est un collectif de freelance,
et indépendant, je suis aussi productonneur du coup de froguite,
et en fait, mon rapport avec la performance,
ça a été au début de ma carrière de pré-freelance,
j'ai été embauché par une startup pour justement,
ils avaient un seul gros dédié chez OVH,
et en fait, leur application s'écroulait,
dès qu'ils avaient 200 personnes qui se connectaient,
et du coup, mon travail, ça a été de migrer ça
sur Amazon Web Services,
c'est comme ça que j'ai commencé à faire du cloud
dans ma carrière,
et mettre en place des tests de charge une fois que ça a été fait,
et pour pouvoir suivre justement, si ça suivait.
J'ai refait ça, les tests de charge sur une application
qui tournait dans OpenShift,
qui est une distribution Kubernetes,
pour un autre client, il n'y a pas si longtemps,
et là, il va falloir qu'on passe au test de charge justement sur froguite,
et là, je me pose des questions sur comment on va s'y prendre,
mais moi, je suis un peu plus loin de ça,
puisque avec ma double casquette d'entrepreneur, employeur,
city au productonneur, je fais beaucoup moins de techniques qu'avant,
mais je continue à en faire quand même.
Du coup, quand on parle de performance,
et comme à chaque fois, dans RadioDiva,
ça va commencer à définir un peu de quoi on va parler avant d'en parler.
Qui veut bien nous définir un petit peu ce que c'est que la performance
ou ce que c'est qu'un problème de performance ?
C'est lent, c'est ça le problème.
Après, la définition, jusqu'où c'est tolérable.
Finalement, c'est ça.
Et d'ailleurs, on parle souvent de SLE, par exemple,
sur les services web.
C'est vraiment en lien, sur certains services critiques,
on a contractuellement, par exemple,
un contrat qui est écrit avec le client en disant
ton serveur doit répondre en moins d'une seconde,
ou en moins de 500 ms.
En fin, souvent, ce n'est pas ça.
99,9% des requêtes doivent répondre en sous 500 ms.
Donc c'est contractuel parfois, il faut le savoir.
Et on prend en reparlée,
donc il y a déjà cet aspect contractuel bien sûr,
et c'est l'aspect, si c'est lent,
même l'utilisation par les utilisateurs,
s'ils se rendent compte que c'est lent,
souvent, les utilisateurs, ça leur pose des problèmes.
Comme je l'ai dit, il peut voir ailleurs.
Il y a un vrai impact sur la rétention des utilisateurs
sur le web, sur des pages lentes ou non.
Ça joue beaucoup,
et ce fait que l'utilisateur va changer le website ou non.
Donc c'est très important.
Après, la notion de performance
est aussi extrêmement subjective.
Il y a certains sites qui répondent très lentement,
mais côté UX, ils ont fait des choses très malines
avec un petit sablier qui tourne,
et en fait, l'utilisateur va être beaucoup plus patient,
parce que, tu sais, ça travaille derrière.
C'est les bars de progression à la Windows.
Ah, c'est bon, ça travaille.
Donc tout va bien.
Alors que si ça turbine super bien côté backend,
et que d'un point de vue utilisateur,
on a l'impression que ça avance pas,
les utilisateurs vont dire c'est lent.
En fait, c'est pour ça que la notion
de la définition de performance est super importante.
C'est à partir de quand c'est lent pour un utilisateur.
Et qu'est-ce qu'on va pouvoir faire ?
Bref, il faut vraiment se méfier
justement des sensations.
Et du coup, c'est vraiment important
d'avoir justement des métriques,
des choses un peu précises
pour définir ça, parce que
s'il n'y a pas de choses facuelles,
on peut vite partir un petit peu dans tous les sens,
et ça va être compliqué.
Je suis assez d'accord, néanmoins,
quand, enfin plutôt,
si une partie de tes utilisateurs te disent assez lent,
et que toi tu constates factuellement que c'est pas lent,
c'est que peut-être tes utilisateurs
attendent une performance supérieure
à ce que toi tu t'attends.
Donc parfois, écouter les utilisateurs,
c'est bien, surtout quand t'es côté business comme moi,
puisque c'était client en fait,
tes utilisateurs, donc tu peux pas juste leur dire
bah non, en fait, il faut attendre.
Des fois, ça marche pas.
Donc la performance, si je vous écoute aussi,
c'est que l'application doit répondre
en fonction du besoin utilisateur.
C'est ça.
Si on va un peu plus dans nos métiers,
on travaille tous dans la fricie,
on pourrait en parler mais une dégradation de la performance
cache souvent un problème,
une infrastructure, un problème dans le code.
En fait, la performance est aussi importante pour ça,
parce que ça montre des problèmes dans ce qu'on a fait.
Sans parler de l'impact sur le client,
souvent les problèmes de performance
montrent des mauvaises pratiques,
du mauvais code, des mauvais paternes,
des problèmes d'infra, etc.
Je te vois secouer la tête, Nicolas.
Oui, parce que tu peux aussi avoir
une infrastructure qui est bien préparée,
mais qui n'était pas prête,
un pique d'utilisateur
non prévu.
Donc elle n'était pas prête.
Oui, mais ce que je veux dire,
c'est qu'il n'y a pas de problème de conception,
mais t'as eu beaucoup plus
d'utilisateurs que ce que t'avais prévu.
C'est quand je parlais tout à l'heure
de nos millions d'utilisateurs
au prank time, on avait prévu le truc,
on a fait des tests de charge,
on a tout bien préparé et ça roulait.
Mais si t'as exactement la même chose,
et ça en France, on sait très bien
faire ouvrir un géoportage,

on disait c'est bon, venez tous.
Et puis 10 minutes après,
c'est plus la peine de venir, le site est par terre,
machin, etc.
Même si ton infra était bien préparé,
tu peux avoir des trucs
qui ne sont pas...
t'as des soucis dans le code, machin, etc.
Et tout à l'heure,
Christophe, tu disais, je veux préparer
des tests de charge, machin, etc.
Moi, je dirais plutôt, c'est amène
des utilisateurs progressivement dedans
et il t'aura des retours en permanence
de est-ce que c'est long, est-ce que c'est pas long.
Et après, tu peux mettre un petit questionnaire
en disant à tes utilisateurs,
qu'est-ce que tu penses de la performance,
est-ce que tu penses que c'est long, est-ce que tu penses que c'est rapide.
Et tout à l'heure, tu parlais de SLA,
donc effectivement,
tu peux contractuer
ça avec ton business, et tu vas avoir
des objectifs à atteindre.
Mais si t'as des objectifs,
t'as un budget en face.
Donc du coup, tu peux avoir ton infrastructure,
tes développement, etc.
Et c'est un projet d'entreprise
parce que c'est
tant côté
développement, côté opération
que côté business, parce qu'il
il va falloir trouver du pognon, il va falloir
avoir des retours utilisateurs, etc.
Alors là,
les motodologies
développent, ça prennent tout leur sens, parce que c'est vraiment un travail d'outil.
Justement, tu parles de
tests de charge et comment on est encore dans la partie
définition, est-ce que tu veux bien
nous définir un petit peu le test de charge ?
Oui.
Alors, le test de charge,
ça va être un test qui va permettre
de simuler un comportement
d'utilisateur,
ou d'un robot qui viendrait
faire des choses sur notre application.
Et on va essayer de
faire en sorte que ça soit le plus représentatif possible.
Donc on va essayer de retrouver
un parcours d'un utilisateur.
Donc, le utilisateur
il va s'inscrire, il va
remplir tous les champs
qui lui correspondent,
il va aller au plo des déficiers,
machin, etc. Et puis, il y a un autre profil
d'utilisateur, c'est l'utilisateur qui est
déjà enregistré. Donc lui, il va se connecter,
il va aller faire une recherche, il va aller regarder
de trois trucs, etc.
En fait, on va rentrer tous ces différents profils
d'utilisateur. Et en fait,
on va avoir
un outil qui va
reproduire ces profils d'utilisateur
en X exemplaire.
Et donc, au lieu
d'avoir un seul utilisateur qui fait
une seule chose, on va en mettre 100 en même temps
qui vont faire exactement la même
chose, mais de manière
décalée, parce que les utilisateurs
qui viennent sur notre site, ils viennent pas tous en même temps.
Il y a des latents,
ce réseau, machin, etc. Et en fait, on va
simuler tout ça. Et on va
avoir une charge qui va être
représentatif d'un certain
cas d'usage. J'insiste bien
sur le côté certain, machin, etc.
parce que les utilisateurs, ils ne font jamais
tout le temps la même chose. Donc, on essaye
de mettre des choses représentatives.
Et on y reviendra tout à l'heure.
Mais ces choses-là, ça se prépare
et
des fois, c'est absolument
par présentatif. On a fait notre test de charge.
On est hyper confiant. On est en prod.
Et pas tout ce qui a se la gueule, parce qu'on n'avait pas prévu
qu'un utilisateur
désactivrait les profils, je ne sais pas quoi.
Dans le même
champ lexical de
l'armes à feu, a priori, on a le
terme TIR. Est-ce que tu peux
nous le définir un peu plus brillamment, s'il te plaît ?
En fait,
un TIR, c'est
une seule exécution d'un test de charge.
On va lancer
un utilisateur
en X temps.
Et donc, c'est paramoutré.
Ok, merci.
Je pense qu'on peut
juste rajouter un petit truc.
Ce qu'a décrit Nicolas, c'est très vrai
dans les applis web.
Mais après, c'est
plus générique. C'est vraiment ce que t'as dit au début.
C'est vraiment simuler
l'activité humaine quand c'est
un utilisateur.
Ou le batch,
si c'est un batch.
Ou les appels API, si c'est un API par exemple.
Ou alors, tu peux simuler
des clients lourds, dans lesquels
tu vas les cliquer, machin, etc.
Mais là, c'est un peu plus spécifique.
Mais
ça existe aussi.
Je crois qu'en voyant les notes de l'épisode,
on va quand même se concentrer plus sur le web
parce qu'on se connaît le mieux tous les quatre.
Mais en effet, tout s'applique
aux clients lourds et autres.
Est-ce que, Mathieu, tu veux bien nous définir
ce qu'est un APM ?
Alors APM pour Appliques Action
Performance Monitoring. C'est souvent
des outils qui ont cette appellation,
qui sont des agents.
On peut installer
de manière ou d'une autre, le lié à son code,
du moins l'activer et récupérer
toutes sortes de métriques sur son application.
Des outils comme New Relic, par exemple,
ce dit APM.
C'est un bon exemple.
Moi, j'ai une vision contrastée de ces outils
dans le sens où c'est souvent des outils
un peu magiques. On les met,
voilà, ça monitor.
Souvent, les devs se disent
c'est cool, j'ai ça, donc j'ai plus besoin
de mettre de métriques.
Alors que c'est une grave erreur.
J'ai tendance à dire aujourd'hui
qu'une application bien monitorée n'a pas forcément
qu'on pourrait en parler.
Mais c'est pas un sujet sur le monitoring, attention.
Une application bien monitorée n'a pas besoin
d'un APM propriétaire dégueu
à installer à côté
de l'appli. Mais ça, c'est mon avis.
Je ne sais pas si c'était clair.
Justement, on parlera des outils à la fin.
Oui, ça répond,
tout de suite on va rentrer dans les détails à chaque fois.
Yeah, vas-y,
allez.
Ouais, ce que je voulais juste dire c'est que
il ne faut jamais oublier que tous ces outils
aussi puissants qu'ils soient, il y a toujours
une phase d'analyse pour essayer de comprendre
ce que veulent dire les métriques
et de trouver
malheureusement, à un moment, il va falloir
un peu des gens qui s'y collent
et qui essaient de comprendre.
Et c'est la fausse quand même.
Il faut aussi arriver que vous l'installez un jour
où vous avez un problème de performance et en fait
l'application devient inutilisable parce que
vous avez installé l'APM.
C'est ce que j'allais dire.
Des fois c'est l'APM qui prend
tellement de place
dans l'appli, qui capte tous les appels système ou autre.
C'est lui qui crée le problème.
Je ne suis pas fan des APM personnellement.
Moi j'adore.
J'ai eu des problèmes que tu as en PHP.
Après ça se suit un petit peu.
D'ailleurs que ce soit
des APM ou des solutions
de supervision,
il faut faire attention à la place
que ça prend sur le serveur, la place en termes
de ressources, machines, mémoires etc.
Même disque.
C'est important que
l'outil qui nous permet de superviser l'application
ne charge pas trop le serveur
justement, alors qu'il n'est pas là pour ça.
Est-ce que je peux juste rajouter un petit truc ?
Vas-y.
Parce que je ne sais pas trop le qu'allez.
Je voulais juste faire une petite parenthèse.
C'est pas vraiment des problèmes de performance
en tant que telle.
Mais parfois moi j'ai aussi vécu
des...
souvent c'est la mise en production
de certaines applications dont c'est mal calibré.
Des choses qui peuvent se mal se finir.
C'est pas que ça se met à ramer,
c'est que ça se met à exploser parce que
je ne peux pas en dépasser une limite mémoire
ou des paramètres qu'il y a de carnet qui ne sont pas bons etc.
Et...
Alors c'est pas vraiment de la performance en tant que telle
parce que c'est fatal.
Mais c'est aussi des choses qu'on va avoir arrivé
au cours du temps et qui dansent.
Comment dire, ça peut marcher pendant
assez longtemps.
Et puis un phénomène peut venir faire
un éclencheur
sur ce type de choses.

Je suis à la fois totalement d'accord
et à la fois un petit peu pas d'accord.
C'est pour moi ça fait vraiment partie de la performance.
Et c'est justement ce que tu vas essayer
de retrouver avec tes tests de charge
où tu vas pousser
l'application dans ces retranchements.
Et ce que tu veux c'est qu'elle continue à répondre.
Parce que si elle répond pas
ou si elle crache,
là c'est une perte de business total.
Et moi je préfère une application
qui va me répondre en 10 secondes
mais elle va renvoyer quelque chose
plutôt que...
tu as tué Time Out, machin etc.
et du coup tu perds des connections, ton application
va avoir un comportement bizarre.
Ou alors complètement craché
et donc il faut attendre le CERBENA, machin etc.
Pour moi la performance
c'est aussi ce que tu viens de mettre.
Pour moi aussi mais bon je...
je n'étais pas 100%...
Je suis pas sûr que tout le monde qualifierait ça comme un problème de perte.
Alors je vous propose
que comme on est encore dans la définition
qu'on avance un petit peu parce qu'on est déjà à 22 minutes
et on est à la traduction.
Du coup on va parler
un petit peu des méthodes.
Moi je suis assez curieux
parce que c'est un sujet que je connais un peu moins que vous 3.
Du coup je sais que Mathieu
il a mis plein de notes dans les méthodes
sur comment
Nicolas nous montre un livre
Nicolas si tu
si tu pourras nous mettre
le livre
dans les notes de l'émission
et vu que tu en train de le montrer
à l'écran et qu'on est aussi sur Youtube en vidéo
est ce que tu peux nous en parler
et après Mathieu pourra continuer
en gros l'idée c'est
quand on constate qu'on a des problèmes de performance
quelle méthode on peut utiliser
pour essayer d'analyser
j'imagine que c'est ça le sujet.
Eh ben vous achetez le boutien de Brandon
Greg
qui s'appelle System Performance
Enterprise and the Cloud
et la méthode
Mathieu va nous en parler.
C'est ça donc Brandon Greg
Dieu vivant
de la performance dans la formatique
qu'elle n'ont en travaillé chez Sun
puis chez Netflix
qui a un super blog sur le sujet
souvent très bas niveau mais c'est vraiment
super intéressant c'est un très très très grand ingénieur
et il a écrit une méthode en effet
enfin il a inventé une méthode
il a défini une méthode que ça s'appelle Use
donc Use pour le U c'est pour Utilisation
donc le temps
qui a un service et travail on va dire
c'est quelque chose
S pour Saturation donc la saturation
finalement est ce que mon service va atteindre
ses limites ou non
ou est ce que j'en suis finalement dans l'utilisation
de mon service et E pour Errors
donc finalement le nombre
d'éreurs que je vis sur mon application
donc il a un article sur le sujet
c'est une méthode où il explique
en effet sur comment
mettre ça en place
avec quelques exemples etc
des fois des hommes très bas niveau
c'est quelqu'un qui travaille vraiment très proche du hardware parfois
ou ce genre de choses
ça peut aller très très loin c'est très intéressant
on a une méthode autre méthode aussi
alors déjà est ce que quelqu'un veut peut-être
reparler de Use et de Man and Greg
parce que c'est vraiment quelqu'un de très important dans le domaine de la perte
je ne sais pas si quelqu'un devrait ajouter quelque chose
ok super
et il y a une autre méthode inventée par Grafana
codifiée
parce que c'est une chose qui n'a pas été inventée
en fait de la perte et du monitoring
avant d'avoir le nom de la méthode
qui s'appelle Red
qui s'inspire un peu de Use
mais un peu différente
c'est une méthode que je visse beaucoup
donc dans Red le R c'est pour Rate
donc le nombre de requêtes par seconde
par exemple ça va s'avoir chier des P
le E c'est pour Errors
comme avant
le nombre de requêtes en erreur
et le D c'est pour Duration
donc le temps d'exécution
voilà donc c'est deux méthodes
on va dire un peu codifiées
mais finalement qui sont assez proches
et finalement
on va dire c'est pas une science exacte
la performance
finalement
parce que savoir le nom de la méthode c'est une chose
savoir quoi monitorer, ça en est une autre
ça ça vient avec l'expérience aussi
voilà
peut-être
c'est quelqu'un veut réagir
je pense quand même
ce qu'il faut
souvent c'est
ce qui a motivé un peu cet épisode
c'est aussi ce qu'on a vu sur les compagnons du DevOps
c'est des gens qui arrivent
et qui posent des questions par rapport à
certains problèmes de performance
je pense que le B à bas
enfin le B à bas je sais pas c'est B à bas
mais on rentre vraiment dans le DevOps
c'est pour le coup c'est de mesurer
avant de faire quoi que ce soit
c'est d'être capable de mesurer ce qui va se passer
et de mettre en place la
une méthode, ce dont on parle
les Nicolas pour faire des tests de performance
et des tirs, quelque chose qui va nous permettre
de reproduire
en effet il est bon de rappeler
qu'on ne peut pas améliorer quelque chose
qu'on ne mesure pas et la mesure est un
des cinq piliers du DevOps c'est hyper important
et justement
la performance on la mesure mais aussi
on peut provoquer les problèmes de performance
je vais continuer à laisser la parole à Mathieu
je pense que t'es bien là
oui bah oui bah tu parlais des cinq piliers du DevOps
on aime bien les piliers dans l'informatique
parce qu'il y a aussi les trois piliers de l'observabilité
donc on va éliminer tout de suite les logs
les logs c'est bien mais arrêter de mettre
des métriques d'angologues voilà
ça ne passe pas des métriques ou des traces
donc on ne fait pas de la perte selon moi avec les logs
voilà fin du sujet log
ensuite on a les métriques
c'est un sujet très important on en a un peu parlé
mais il faut monitorer un certain nombre de choses
dans nos applications ou sous nos serveurs
pour en peut-être discuter plus tard de
qu'est-ce qu'il faut monitorer mais
mais voilà le nombre d'erreurs
le temps d'exécution de recat HTTP
par statut
le nombre de réponses par statut code
pour donner quelques évents sur une API
c'est très important de mesurer
pour comme a dit Christophe savoir
qu'est-ce qu'il se passe si on a pas de métriques
on sait pas ce qu'il se passe
et enfin on a des traces
donc les traces
c'est assez intéressant
ça vient en complément des métriques
ça ne les remplace pas
les métriques sont une vue agrégée
finalement de ce qu'il se passe sur la plateforme
nombre d'erreurs par seconde, nombre de requêtes par seconde
temps d'exécution, moyen
on va dire médiane ou des choses comme ça
les traces c'est
je prends une requête HTTP et je peux voir tout son circuit
à travers par exemple plusieurs services
base de données ou autre
et voir vraiment pour chaque étape
où il est passé du temps
finalement c'est vraiment une vue unitaire
d'une requête ou d'un événement
là où les log et la où les métriques
ça va être une vue un peu agrégée
via des formes de mathématiques
voilà
pour schématiser un petit peu
c'est les traces, c'est ce que vous avez
dans votre Chrome
avec le graph
network où vous voyez toutes les requêtes
qui définissent les unes à côté des autres
et les métriques
de performance c'est quand vous ouvrez
votre monitor system, votre h-top
vous avez votre cpu, votre mémoire
mais vous savez pas quelle application
grenade serre source
c'est exactement ça
je peux juste me permettre
une petite note juste pour ne pas
c'est pas nuancer mais oui les logs
c'est pas forcément pour la mesure
c'est pas une idéale ça c'est sûr
après je pense que
ce que tu as voulu dire c'est de ne pas
mettre de log, des logs ça va être forcément
très utile pour savoir ce que l'a plifé
quand on va être point
voilà, enfin je voudrais pas que ce soit pris
comme quoi les logs ça sert à rien
non mais je vais donner un exemple
juste j'ai une question
j'ai une question parce que pour un BOSien
comme moi qui n'a pas encore l'habitude
d'utiliser des traces
moi quand je vous vois de traces je me dis
mais c'est quoi la différence avec une log
une trace, est ce que vous pourriez faire
la différence entre les deux
je peux le faire
peut-être que ça n'a rien à voir je sais pas
un log c'est un message
c'est passé ça dans mon application
j'ai eu tel erreur ou autre
une trace c'est quelque chose qui va être
initialisé à un moment
quand la requête arrive sur ton service
même initialisé par ton load balancer
on va mettre un petit ID en Header de ta requête
en disant bah voilà bah c'est mon ID
1, enfin voilà c'est un UID
pour le peu de casse on va dire c'est un numéro
c'est ma trace numéro 1
ensuite dans ton service
tu vas avoir un peu des checkpoints
à l'intérieur de ton service qui vont enregistrer
ils vont dire ah bah tiens ça c'est
par exemple j'ai fait un appel de données
il a été déclenché par ma requête qui était tagué 1
qui avait 1 en Header
et ensuite tu fais un appel à un autre service
et tu forwardes, tu continues de transperte
cette trace en Header
ton second service reçoit par exemple ta requête
avec encore en Header trace égal 1
et là il va dire ah bah tiens ça a encore la trace
égal 1, bah boum je remets un peu
un checkpoints voilà je fais une
spanner dans le vocabulaire
donc je rajoute de l'information etc
et en fait tu peux tracer comme ça
au sein d'un service
mais aussi au sein d'une collection de services
le chemin qui a fait une requête
une requête qui déclenche une autre requête
qui déclenche une autre requête, qui déclenche un appel de données
un appel à une base de données par exemple
ou un autre service interne ou n'importe
et au final tu vois vraiment ce déroulement
dans l'exécution de ta requête
et tout ce qu'elle a déclenché
et où est-ce que tu as passé du temps en final
sur toute ce cycle de vie
je sais pas si c'est très clair
c'est... c'est... c'est...
c'est une des difficultés avec les
systèmes distribués parce que
chaque... chaque service
pourrait avoir son ID
à lui et du coup ça va être
super difficile de...
d'arriver à trouver le lien
entre une requête qui va passer dans plusieurs services
et donc les traces ça va permettre
d'avoir quelque chose qui unifie
et avec effectivement un numéro unique
et être sûr que de bien voir
où elle est passée, donc quel service
elle est passée et combien elle a pris de temps
pour ceux qui seraient...
pas d'excuse
je vais dire pour ceux qui seraient bon
un ordinateur pendant qu'ils écoutent ou qui regardent
ils peuvent faire une pause et regarder
chez eux dans les notes de l'épisode
l'outil
qui est développé par Grafana donc la suite
qu'on a eu juste, c'est Tempo
donc Tempo il est vraiment fait
pour collecter les traces et les visualiser
donc vous aurez une idée de
ce qu'on peut faire avec ces traces là
je pense qu'on y reviendra
un peu plus en détail quand on abondra la partie
outil
je sais plus où on en est des notes
parce que je suis un peu perdu
et moi je voulais revenir rapidement sur les logs
les logs sont quand même importants
donc comme le disait Mathieu
faut pas mettre des trucs
de performance dans les logs
par contre on a dit que dans le use
il y avait les erreurs
et c'est très important d'avoir des logs
où vous tracez systématiquement
toutes les erreurs que vous avez eues
parce que si vous avez des 404
si vous en avez trop
sur une URL, c'est un problème
c'est pas juste quelques erreurs par ci par là
il y a un problème quelque part
c'est vous avez des requêtes
esthuelles qui échouent
il faut pouvoir le tracer
et un contrario
ne tracez pas n'importe quoi
moi j'ai régulièrement, il y a des développeurs
qui rajoutent des prits
et du coup ça pousse les logs
et alors moi
j'arrête de regarder parce que c'est inexploitable
il y a l'écran qui défile
ça va avoir une connexion fibre
tu vois rien passer là-dedans
et c'est justement
c'est là où c'est important d'avoir des logs
bien formés
avec les bons contenus
avec la bonne pertinence
parce que vous allez les voir bouchiller
et puis l'octobre
il s'est très bien travaillé
il va récupérer les occurrence
et il va dire oh ça c'est bizarre
et vous allez regarder et vous allez vous dire
oui bah tiens c'est cette erreur là
elle est quand même assez fréquente
et là vous allez faire du brèpe dans les logs
mais je vous aurais une piste de ou à les chercher
alors juste très rapidement
sur ça pour finir sur la partie log
moi la grosse distinction que je fais
c'est les métriques servent à détecter le problème
donc par exemple mon endpoint htdp-slash toto
il sort plein d'erreurs 500
et ensuite le message
associé à ces erreurs 500
là c'est un log
mais on met pas une alerte pour moi sur un log
c'est-à-dire l'alerte, le problème vient d'abord
de la métrique, mon error rate
mon ratio d'erreurs etc
qui me montre que j'ai un problème et ensuite j'ai les logs
ou avec le détail là
avec un vrai message d'erreurs, une stack tres
selon votre langage, bref un truc avec du détail
et éviter de faire comme njanik c'est de mettre
en gros des métriques dans les logs
et ensuite vous devez passer ça pour sortir de la perte
dans d'autres métiers on est très
on est très orienté à frais
donc les métriques systèmes souvent elles sont connues
on pourra peut-être en parler aussi plus tard
la RAM, le cpu, les limites
le nombre de fichiers ouverts ou autre
ce qui est très important c'est les métriques applicatives également
c'est ce qu'on dit juste avant
il faut vraiment des métriques dans vos applications
c'est que comme ça que vous verrez qu'il y a des problèmes
on parle souvent de monitoring
enfin voilà
voir de la faire de la perte sur une application
sans avoir des métriques dans cette application
mais en essayant de la regarder depuis l'extérieur c'est très compliqué
on a besoin de ça, vraiment à l'intérieur
et ça c'est le nombre du code à l'intérieur de l'application
juste je vais rebondir en effet
c'est important
de faire
de la performance
à partir du moment où vous avez mis
en place un outil de supervision c'est pour ça que je vous ai
envoyé sur l'autre épisode de podcast avant
parce que vous ne pourrez pas faire de performance
si vous n'avez pas de métriques
c'est pas possible et les deux
vous êtes complémentaires
c'est pour aujourd'hui
tu pourras mais alors je te dis pas
comment tu vas galérer parce que quand on dit c'est long
ça va être tiens
Nicolas l'application elle est longue
alors je viens d'arriver dans la boîte
c'est eu le système de
métriques machin
il n'y en a pas, tu ne sais pas quand est-ce que ça a commencé
tu ne sais pas
qu'est ce qu'il faut aller regarder machin
et là tu pleures
oui mais Nicolas
essayons de ne pas conseiller de mauvaises pratiques
à notre auditeur
évite de le faire s'il te plaît pour ta santé mentale
René tu voulais rebondir
je vais même aller plus loin que ça
c'est quand tu arrives dans une boîte s'il n'a pas ça en place
c'est le premier truc à faire
oui ce que je voulais dire c'est que je pense même que
des fois la partie applicative
elle est, enfin elle m'en a eu plus difficile
des fois à mettre en place
mais elle est souvent
pour moi elle a plus de valeur
parce que
parfois on peut avoir
des métriques qui sont surprenantes sur un système
mais c'est pas pour ça qu'il y a forcément
un problème de performance
à cet endroit là
donc avoir la vue de l'utilisateur
savoir s'il est disponible et s'il répond
dans un délai acceptable
ça c'est vraiment important
mais pas forcément le plus simple à faire
en effet
mesurer la performance c'est une fausse
il y a plein d'outils je ne sais pas en ce moment
ce n'est pas un procès sur monitoring mais les histogrammes
c'est très utile et souvent ce qu'on essaie de se dire
c'est que le but c'est pas de savoir
où il y a une requête qui est lente
ce que je veux savoir c'est
99% de mes requêtes
quelle est la performance
à peu près 99%
99,9% de mes requêtes
un peu comme les SLA d'avoir des objectifs
on appelle ça souvent des SLO
donc l'idée c'est de se dire
ok moi j'ai un objectif
je veux que 99,9% de mes requêtes
se déroulent en moins d'une seconde
sur mon savoir chier TP
et je mets en place des métriques ensuite
pour voir que
si je respecte ou pas ce SLO
donc ça peut être un SLO interne
ne laisses pas forcément un contrat
et la métrique de la latence
on appelle ça un SLE
généralement et c'est ça généralement
qui est mis en place pour
pour mesurer la performance
via des histogrammes
via des error rate
via de la latence sur des queues
je vais pas rentrer dans le détail
et un dernier point qui est très important
c'est la cardinalité des métriques
il est label associé à ces métriques
avoir une métrique qui dit mon application web
le temps moyen de toute l'application c'est ça
ou le temps de 99% de requêtes c'est ça
c'est pas important
moi je veux la voir par endpoint
je veux savoir c'est quoi les performances de slash.toto
slash.titi
en poste en get
en delete etc etc
donc ça on appelle ça des labels qu'on associe à des métriques
et l'idée c'est de
monitorer assez précisément
pour vraiment faire la distraction entre 2 appels
si vous avez 2 appels sur l'application web
1 seconde
1 seconde
peut-être que vous avez l'impression que tout est lent
en fait il n'y a qu'un appel qui est lent
et c'est sur ça qu'il y a le problème
et donc avoir une vue globale ici serait pas très utile
avoir des vues avec des labels corrects c'est très important
et également juste pour finir
après j'ai terminé je crois
savoir des métriques à tous les étages
par exemple
vous avez un lobbyancer qui appelle
un serveur HTTP qui appelle une base de données
et bah moi ce que je veux c'est des métriques
côté lobbyancer
combien de temps met mon lobbyancer à faire son appel
et avoir la réponse sur mon application web
dans mon application web je veux le temps
d'exécution de la requête combien de temps j'ai mis à faire le traitement
de A à Z
et ensuite quand j'appelle ma base de données
je veux le temps d'exécution de ma requête
et c'est cette chaîne
de métriques qui est très importante parce que quand vous avez
un problème comme ça vous voyez exactement
immédiatement où est le problème
parce que parfois si vous avez juste des métriques à un endroit
en fait c'est parfois l'an avant
c'est à dire vous n'êtes pas encore entré dans la mesure
en quelque sorte
donc c'est important d'avoir des voilà ces métriques à tous les étages
pour pouvoir très facilement voir
à partir d'où finalement dans votre chaine
d'appel ou dans votre code
le problème apparaît
voilà
je vais revenir
sur ce que tu disais sur les historigrammes
en fait c'est vraiment important d'avoir
des graphes parce que encore une fois
c'est plus ça sera simple plus vous irrez vite
et moi j'ouvre
mon dashboard avec toutes mes métriques
et puis je mets une plage de temps
plus large parce que si on me dit que ça a eu
lieu entre 14 et 15 heures
je vais mettre mes données sur 24 heures
puis je vais regarder et puis je vais faire
défiler sur mon écran tout tout tout tout tout
puis je vais regarder où est-ce qu'il y a des pics
et en fait
si vous avez toutes les métriques
système réseau machin etc
vous allez retrouver les pics
et des fois vous aurez des graphes qui seront plats
parce que cette métrique système
elle ne bouge pas la mémoire
elle est constante donc ça veut dire que c'est pas un problème
de mémoire le cpu
il monte et puis il y a une crête
bah là c'est peut-être un début de piste
c'est et en fait
vous allez faire défiler tout vos graphes comme ça
et ça va être une aide
pour trouver le petit truc
le petit grain de sable
dans votre eau
et ça va pas résoudre votre problème
mais ça va vous donner une piste
de coup creuser plus tard
je suis complètement d'accord avec ça
un autre exemple que j'ai vu récemment
c'était un problème de lenteur sur une application
et ensuite il s'est résolu
en fait on voyait vraiment dans l'autoscaling
des applications qui avaient des nouveaux nœuds
qui étaient créés etc mais le temps qu'ils arrivent
c'était un peu plus long que la normale
et ensuite ça rebaisse parce que la plateforme a fait son travail
et finalement
juste un point sur l'alerting
sur quoi alertait on alerte sur des métriques
on alerte pas sur des logs, pas sur des traces
et surtout le but
c'est d'alerte avant que
les problèmes de perte
deviennent des vrais problèmes
vous avez un endpoint HTTP qui passe
de 0,5 secondes
on va dire le P99
donc en gros votre 99%
des requêtes s'exécutent en 0,5 secondes
ou moins et d'un coup ça passe à 1 seconde 5
bah ouais l'application elle fonctionne encore
c'est pas encore un problème, c'est lent
c'est un peu plus lent, vous avez pas de downtime
mais en fait il faut pas laisser le problème se dégrader
faut comprendre ce qui s'est passé
et pourquoi par exemple après une release d'une application
j'ai fait x2 en perf, même si l'une application
est toujours utilisable la perf c'est un travail au quotidien
au final
c'est pas un truc qui se fait que quand on a des incidents
ou que quand on a des problèmes
parce qu'en fait là c'est déjà trop tard
et donc il faut pouvoir vraiment avoir cette culture
de la perf et d'avoir
au cours du temps, monitorer le cours du temps
et alerter dessus pour voir des dégradations
en fait et pas attendre qu'on arrive
à des pertes dégueulasses pour se dire
ouais il y a un problème d'avoir un problème
parce que là vous avez en plus il y a beaucoup beaucoup de temps
et d'ailleurs par rapport à ça
je vais en parler rapidement
mais c'est l'assist search
que j'utilise pas du tout mais je sais que dans les solutions
Enterprise il y a la possibilité
vous envoyer tous vos maitrisques, tous vos logs
dedans et ils ont une solution
qui fait du deep learning
sur toutes vos maitrisques, tous vos logs
machin etc
vous le rentrez en fonctionnement nominal
le truc qu'il apprend
et quand il y a des incidents, vous le notifiez
et au bout d'une certaine période
d'apprentissage le truc va vous faire votre monitoring
automatiquement et dès que vous aurez
des problèmes de performance
ça va vous a l'air
si vous avez coché une case dans le bingo bullshit
en parlant de cocher des cases
je vois que toutes les cases de Mathieu
sont cochées
et René tu avais plein d'autres
petites choses à nous dire
est-ce que tu veux prendre la suite ?
ouais
je peux dire
à souvent ce qu'on voit et on l'a vu un petit peu
des fois des messages sur le formes des compagnons
c'est des gens qui
en gros qui veulent
déjà modifier du code avant de vraiment avoir
mesuré
ce qui se passe en fait
je pense que
ça rejoint ce que je disais au début
ou ce qu'on a tous dit
vraiment la première chose c'est mesurer
et de se faire quelque chose où on peut voir
ce qu'on va faire
si on a
flu dans le bon sens ou pas
après
ce que je voulais dire
c'est que parfois
c'est pas
comment dire
c'est pas si évident que ça
c'est problématique
et parfois c'est
contre-intuitif en fait
c'est à dire que
des fois on agit sur quelque chose en pensant
qu'on va améliorer les choses
et puis des fois pas du tout
donc encore une fois ça revient
ce que je viens de dire juste avant
mais il faut absolument mesurer
et faire ces changements quand on fait des changements
les faire un par un
et pas commencer à modifier
dans tous les sens
je fais ça à tel endroit
je mets un coup de clé à l'autre endroit
et puis après on sait plus ce qui a été bénéfique
et ce qui ne l'a pas été
moi aussi ce que j'essaye de faire
souvent quand j'ai ce type de problématique
c'est des mutations un peu extrêmes
par exemple quand on règle des paramètres
pour bien voir la différence
je trouve que ça aide
c'est de passer un peu
de changer d'ordre de magnitude
parfois sur certaines valeurs
vraiment faire des changements drastiques
pour voir comment ça va se comporter
plutôt que des fois faire des choses un peu fines
on ne voit pas trop si on a amélioré ou pas
moi j'ai constaté dans ma carrière
c'est quand même que beaucoup des problèmes
c'est souvent des problèmes liés à l'AIO
plus souvent que cpu
voilà je pense que mes collègues
je sais pas ce qui s'en pense
je suis d'accord
faut m'intourer les AIO toujours
avec la méthode red, moi je suis tout le temps
mais juste deux choses
quand on sait pas l'AIO c'est de la crypto
donc faire du machine de passe-froid
avec des cryptes et des trucs comme ça c'est méga lent
ou c'est du calcul de chat ou de md5
on ne se rend pas compte mais c'est méga lent aussi
c'est les deux choses que j'ai vu qui posaient souvent des ralentissements
des algopouris ça arrive aussi
on peut parler de complexité aussi dans ce podcast
mais voilà
c'est tout de suite
agorhythmique on va dire
attention à tout ce qui est je dirais
AIO, mes cryptos, tout ce qui est cryptographique
et à China c'est super lent
très souvent
ça tombe bien c'était mon point suivant
en fait c'est que moi ce que j'ai vécu jusqu'à maintenant
c'est souvent les gros gains
de performance
ils se font très souvent sur l'appli
enfin moi j'ai un peu cette règle
je dis c'est un 80 à 20
c'est à dire que les 80%
ça va être en changeant ce qui se passe dans l'appli
en l'améliorant et justement
les notions de complexité elles sont importantes
réduire la complexité algorhythmique
à un moment ça va vraiment produire
des effets assez
importants sur les performances
et après
le hardware ça peut être une solution
mais c'est souvent que 20%
de ce qu'on peut gagner
parce qu'il y a alors après on peut en mettre beaucoup
mais ça a
toujours des limites si l'algog est pourrié
ou si la requête
la requête qu'on fait par exemple
sur une base de données elle est vraiment très mal optimisée
ou voilà pas d'index
ce genre de choses des choses assez basiques
on peut rajouter beaucoup de hardware
mais ça ne voudra jamais
de mettre un index sur sa base de données
attend je vais... Nicolas
il va craquer la tête
il va s'expercer
ce que je dis systématiquement
au développeur c'est essayez pas
de résoudre des problèmes
de votre application avec des solutions
infrastructure donc si tu as des problèmes
de performance c'est pas en mettant
un truc qui va te faire du cash
c'est pas en mettant une machine plus grosse
c'est pas en mettant plus de RAM
c'est pas en mettant plus de CPU
tu vas d'abord regarder pourquoi
ta requête SQL elle marche pas
il m'ont tiens un index
ah bah d'accord
c'est ce que j'ai dit il me semble
il me semble aussi que c'est ce qu'il a dit
c'est ce que j'ai compris comme ça
c'est ce que j'ai compris moi
j'ai compris comme ça
je suis d'accord
je te refais très rapidement
j'ai dit que 20% des gains ça pouvait être
sur le hardware mais que les gros gains c'était
sur l'applicatif et donc côté DB
mettre un index
j'entends un développeur qui a dit
c'est un problème de hardware on va rajouter
des ressources ça me fait peur
désolé j'ai paniqué
écoutez pas vos développeurs quand ils vous disent
il faut une machine plus grosse d'abord
allez voir votre APM
votre RAS
allez dire au développeur tiens
et si on se mettaient tous les deux et qu'on regarde
est-ce qu'on peut améliorer ça
et comme ça l'ops il travaille ensemble
parce que c'est le mouvement des ops qui est comme ça
exactement
si ton développeur est pas content
il ne veut pas
tu vas voir ton comptable et tu lui dis on va multiplier
la facture d'infrastructure par 2
est-ce que tu es d'accord
est-ce qu'on a fait le tour des méthodes
parce que je vois que le temps avance
quand même on est à 50 minutes
est-ce qu'on peut passer à la section incident
je voulais juste finir
toute dernière petite point
c'était
c'était vraiment attention aussi
aux phénomènes de latence
moi j'ai vu pas mal de choses
ou par exemple des développements qui se font
avec une base locale
avec une très bonne latence
ça se passe plutôt bien, ça marche bien
et du coup quand on déporte la base
la latence
pour différentes raisons
peut changer assez
de manière assez importante
et du coup ça peut induire
des gros problèmes de performance
et les problèmes à la latence souvent
c'est assez compliqué à fixer
la machine du développeur
l'insertion de la base
et on tient chanerat
voilà, on continuera ça
merci pour cette précision
on va pouvoir parler des incidents
et puis
quand on a un incident de performance
qu'est-ce qu'on peut faire
mais avant qu'on commence
il est bon de rappeler qu'on a fait un épisode de radio develop
sur la production, l'exploitation
les astrates en informatique
où on a parlé beaucoup d'incidents
et on a une émission avec René
une libre entelle qui s'appelle
raconte-tout des grosses échecs
où on raconte des histoires de production
et des incidents de production
si ça t'intéresse, viens nous voir en live
avant de vous laisser la parole
parce que je parle pas beaucoup ce soir
je vais vous raconter
un retour d'expérience sur un problème de perte
qu'on a eu il n'y a pas si longtemps que ça
sur Frogit
on a une autre guide là
qui était un peu lent, j'ai demandé à mes collègues
il me disait mon nom, sauf que moi j'avais bien constaté
qu'il était lent, parce que j'y passe vraiment beaucoup de temps
et du coup
je me dis qu'est-ce qui se passe
donc là évidemment je vais voir mes métriques
je vais voir mes logs
et je vois en effet que ma CPU et ma RAM
n'est pas trop utilisée
je me dis qu'est-ce qui se passe
et là je vois mon disque qui est plein à 100%
mais pas tous mes disques
mon disque qui contient mes backups
donc évidemment la solution
pouvait continuer sans aucun problème
et là par contre
je ne moniterais pas mes process
je me suis connecté au serveur
oui je sais c'est pas bien
mais je me suis connecté au serveur
et là j'ai vu qu'en effet mes process de backup s'accumulent
depuis quelques jours
et ils avançaient très lentement
parce que quand il y a un process de backup
qui est arrivé jusqu'à la fin, ils libéraient les backups
sauf que comme le disque était plein à 100%
les process ils se sont accumulés
la première chose que j'ai fait c'est supprimer
les anciens backups
c'est qu'il est les process qui étaient trop longs
la deuxième chose que j'ai fait
c'est ouvrir une petite carte pour dire
attention il faudrait qu'on mette un time out
sur notre processus de backup
il faut aussi qu'on augmente la taille
de notre disque de backup parce que c'est important
et du coup
j'ai fait des actions correctives sur place
ça m'a pris un petit peu de temps
mais pas tant que ça parce que j'avais des bons outils
et ce que je pourrais faire encore
c'est super viser en effet les process
en plus dans ma solution de supervision
voilà mon petit retour d'expérience
sur ce que j'ai fait
sur ce problème de l'antheure
qui finalement ne venait pas de l'application
mais de l'infrastructure qui faisait tourner
l'application
et là je vous laisse la parole
parce qu'on a un beau petit plan
je crois que c'est Nicolas du coup
Nicolas lève la main, Nicolas je te laisse la parole
petite aparté pour les histoires de backup
mettez des alertes sur vos backups
quand il marche et quand il marche pas
et regardez tous les choux
donc du coup
moi je vais vous parler
de comment
on peut faire quand on a un incident
de production
comme je l'ai dit tout à l'heure
j'en ai déjà eu pas mal
et notamment certains
l'application répondait plus
le patron qui y en
s'est fait tout le monde m'appelle
ça marche pas, ça marche pas, il faut rebouter
donc première étape
c'est il faut pas paniquer
très important, regardez son cas
il faut être celui qui va garder la tête froide
parce qu'il faut qu'on puisse réfléchir
ensuite il va falloir trouver comment mesurer
parce qu'on a un problème de performance
on en a déjà bien parlé
mais c'est vraiment le plus important
c'est mesurer d'abord
comment vous pouvez voir vous
que c'est lent
ensuite on panique pas
parce que vous regardez la tête froide
ensuite on va chercher
comment tester ou reproduire en tant qu'utilisateur
si il y a un endpoint
qui est vraiment très lent
parce que
je sais pas pour quelle raison
encore mais que c'est celui qui est utilisé
par 90% des utilisateurs
on essaye de le reproduire
avec un curl, on regarde combien de temps
il m'est pour répondre, c'est bon c'est ça
donc à chaque fois que je lance ce curl
c'est lent, tout va bien
donc je vais avoir ce test là que je vais relancer
à chaque fois, on garde toujours son calme
c'est très important
surtout quand le chef vient derrière votre dos
pour vous dire fourbouter
je gère
ensuite
on va
remer on a parlé tout à l'heure mais ça c'est très important
c'est vous tester une seule chose à la fois
vous voulez redémarrer un composant
ok parce que si on redémarre le serveur
SQL
ça va résoudre le problème
on relance le test de tout à l'heure
le curl, etc
ça résolue
l'incident, très bien, tout va bien
est-ce que tout le monde est content ? ok
non, bon ben ok, alors maintenant
c'est qu'est-ce que je vais pouvoir faire
on fait que c'est
le goulot d'étranglement c'est la base de données
on va essayer des paramètres de tuning
il y a plein de trucs dans tous les serveurs SQL
vous pouvez mettre
des caches par ci par là, machin, etc
et ça encore une fois, René
il a dit tout à l'heure, c'est on teste une seule chose à la fois
on teste un paramètre
on teste un deuxième paramètre
on teste un troisième paramètre
mais on redémarre à chaque fois
et on relance le test à chaque fois
c'est très important
et une autre chose importante
ça s'est arrivé une ou deux fois de faire l'erreur
c'est vous sauvegarder à chaque fois
quelle modification vous avez faite
quel impact ça a eu sur les performances
au moment où vous avez fait votre coeur
ensuite
on en a aussi pas mal parlé
il faut mesurer systématiquement
plus que vous faites
parce que vos coeur ils ont un temps de réponse
etc
la charge de votre serveur est-ce qu'elle évolue
en fonction des paramètres que vous changez
parce que certains paramètres
vont avoir une incidence sur le CPU
d'autres sur la mémoire etc
on surveille un petit peu tout ça pour voir l'évolution
de l'incident
et si c'est ok
vous retournez au point 5
et si c'est caro
vous retournez au point 5
donc vous gardez votre calme
vous refaites un test
vous rechangez comme une seule chose etc
et en fait vous bouclez là dessus
et normalement vous devriez résoudre votre incident
mais toujours en essayant de garder
le maximum la tête croix
merci je vais mettre le plan
dans la description de l'épisode
et tout à l'heure
t'as dit faites une sauvegarder tout
et là je me dis que ce plan là
il est super intéressant quand on fait de la phrase code
parce qu'en plus
quand on fera de la phrase code
on commit nos modifs
on déploie nos modifs
qui sont dans Git
et du coup on peut avec un outil de supervision
indiqué
le déploiement il a lieu sur tel H de comite
et on peut voir dans notre supervision
Abathya tel déploiement
et il a amélioré ou pas
justement les performances
par d'expériences
quand c'est vraiment la merde
tu te connais que ton SSH sur le serveur
tu modifies le fichier de configuration
à la main et tu redémars
à la main sauf si effectivement
tu as désactivé
un truc qui te permet
de pouvoir
déployer des choses à la main
et d'ailleurs ça aussi c'est un truc important
c'est quand vous avez 300 frontaux
qui vont porter votre application
déployez pas
les changements surtout et essayez de trouver
une solution pour faire des tests sur un
serveur d'application isolé
comme ça vous allez à démarrer que celui-là
et il n'y a que vous qui allez atterrir
sur celui-là
si c'est pas un problème de charge avec du nombre
d'utilisateurs mais vraiment une seule
requin
c'est vrai que
ça fonctionne ce que tu dis
dans un contexte VM server
mais dans un contexte
image immuable
slash Docker slash Kubernetes
c'est pas vraiment adapté
ça dépend en fait le contexte dans lequel vous êtes
oui
oui c'est possible
en fait le
mettre tout ça
il faut isoler
il faut réussir à isoler le problème
et c'est vrai que là ça ne transpirera pas
dans le plan que je vous ai mis
mais en gros vous allez faire
un espèce d'arbre de diagnostic
vous allez dire
il y a de fortes chances que ce soit ce problème-là
donc vous allez poser des hypothèses
ça peut venir de là, de là, de là
et vous allez dire bon
pour tester ça comment est-ce que je peux faire
donc vous allez tester
et vous allez régler au suramdure les hypothèses
pour arriver à celle
il faut espérer se fera la bonne
et si ça ne marche pas
voir commencer à zéro juste à trouver
des fois c'est sans fin
parce que parfois moi c'est déjà arrivé
je vois quelle est l'application qui pose le problème
on rajoute de la Kappa, on rajoute des instances etc
et en fait
cette application va mieux mais l'application
derrière cette application commence à tomber aussi
parce que forcément la charge
déporte en fait
donc c'est assez marrant
et sur les métriques
mesurer, comme disait Nicolas
pensez avant l'incident
que la création d'un nouveau service
un jour j'aurai un problème de perte dessus
je le sais, c'est sûr ça arrive
mettez les métriques
et si vos devs ne veulent pas mettre de métriques
vous les mettez d'astrinte sur leurs applications
et vous allez voir en un mois, bizarrement
vous aurez des métriques
donc
faites participer tout le monde à la résolation d'accident
ça permet de responsabiliser
et les gens se rendent compte aussi de pourquoi
des fois
les OGS ou même pas que les OGS
pour moi ça doit être un truc partagé
finalement c'est des sortes de métriques
la responsabilité partagée demande la vous de métriques
sur les applications
après c'est vrai que parfois c'est effectivement non trivial
parce que des fois ça peut être
relativement simple
et parfois surtout dans les systèmes distribués
ce que tu dis
tu touches le service A
et puis effectivement c'est le service B
après qu'il se met à déconner
et parfois c'est vraiment
compliqué
c'est les pires problèmes de la production pour moi
il y a aussi un cas
je n'ai pas évolué et ça ça arrive
relativement souvent
c'est lent, on ne sait pas pourquoi
on regarde ces process
PHP, Java, Ruby, Python
qui prend tout le CPU
vous essayez de faire un Insta
si ça résoule problème tant mieux
c'était un cas à la marge
par contre si jamais ça se reproduit un jour
là il faut vraiment chercher pourquoi
ça se reproduit et c'est là où il faut vraiment
garder la tête froide parce que
votre business il va venir, il va vous dire
c'est pas possible, il faut en démarrer, c'est non
il faut pas redémarrer, là il faut qu'on identifie
pourquoi ça
ça sert à produire
parce que ça s'est produit une fois
ça s'est produit une deuxième fois, ça va se reproduire
une troisième, une quatrième, une cinquième
et la solution c'est pas redémarrer
parce que c'est pas viable
sauf si ils avaient des systèmes
où vous pouvez faire tourner les instances machin
mais c'est complètement foireux
tu mets un crône tous les jours qui redémarre
c'est ça la solution, tu as une de terre
exactement
ça peut régler des problèmes
des fois
comme vous ne l'avez pas la vidéo
c'était totalement ironique
ne le faites pas
oui, justement
puisque tout à l'heure t'as parlé de reproduction
d'incidents qui veut nous parler
d'une méthode de reproduction
d'incidents et de tests de performance
moi je veux bien en parler mais pas pour vous
encore Nicolas
on va laisser la parole à Mathieu
avant que Nicolas
je vais pas dire grand chose en fait c'est pour dire que je suis
incompétent en faisant ça et je suis vraiment pressé
d'écouter Nicolas parce que pour moi
le test de perf c'est super compliqué
souvent c'est sur des données
qui sont très peu semblables à la prod
ça c'est le truc classique
on fait un test en staging ou autre
on arrive sur la prod et les jeux de données en base
ils sont complètement différents, il y a des aspects de l'ego
prendre des données de prod et les mettre en staging
pour faire des tests de perf, faut anonymiser
si tout est un process etc
c'est aussi compliqué parce qu'on n'a jamais
exactement la même chose en staging qu'en prod
on va tester juste un bout de
précise de la plateforme sur un test de perf
en prod c'est beaucoup plus vaste
je vais raconter différents choses du coup
moi je suis très mauvais à ça
et en fait tu vas sûrement parler
j'ai l'impression que la seule souverain solution
c'est de faire le test de perf en prod
je sais pas faire des tests de perf pertinents
en staging
je vais justement
parler de tout ça
donc effectivement il y a plusieurs cas
moi les cas que j'ai eu
c'était principalement
soit de l'optimisation
donc là tu fais tes tirs en prod
et tu le fais dans une fenêtre
où il y a moins d'utilisateurs
parce que tu vas balancer tes tiers
tu vas écouler la plateforme, tu vas redémarrer
les services avec tes utilisations etc
donc
faire ça en prod c'est toujours compliqué
mais c'est le meilleur moyen
d'avoir une plateforme ISO
avec plus que tu décryves
en plus tu as des utilisateurs en parallèle
donc c'est bien ça charge encore plus qu'on s'est à grou
et l'autre solution
plus l'autre cas où j'ai eu besoin de le faire
c'était
quand je préparais une migration
donc en fait
la plateforme sur laquelle je faisais
mes tests de performance c'était la future prod
donc la anonymisation
des données en réalité je m'en foutais un petit peu
par contre ce que tu dis c'est vraiment
intéressant et important
parce que
comme on en a déjà parlé
pas mal de fois
c'est que vous aurez des problèmes de perte
et vous avez préparé les choses en amont
donc faites au fur et à mesure
que vous développez votre application
ou vous aurez rajouté des trucs etc
faites un script qui permet d'anonymiser votre base de données
qui permet extraire
certains morceaux de l'application
certaines données
d'un utilisateur
d'un client, d'un machin etc
pour le donner à un développeur
de manière totalement anonymisée
comme ça il va pouvoir débloquer sur sa machine le truc
et ce script d'anonymisation
vous pouvez l'utiliser pour monter une plateforme
de performance
c'est quoi ? c'est une plateforme
qui ressemble à la prod
avec des dimensions
réduites, avec moins de machines
alors ne mettez pas
une seule machine si vous en avez 10 sans prod
essayez d'en mettre une, deux, trois
avec des ressources plus petites, machin etc
mais vous essayez de mettre un truc qui va ressembler à la prod
et comme ça quand vous allez balancer
3 000 utilisateurs
vous ferez des projections
en vous disant sur la prod
ce sera 30 000 utilisateurs sur une plateforme
et après du coup la méthode c'est quoi ?
donc le plus important c'est
préparer ces outils
on va choisir un outil qui va faire
des tests de perte, moi j'ai beaucoup utilisé
GATID, c'est un truc qui est écrit en Scala
donc il va paralyser vos requêtes
et puis il va briner
et avec un poste de développement ça suffit largement
penser à la vente passante
parce que si vous faites ça derrière
un modem de 56K
le goulou d'étranglement ça sera votre machine
donc vous prenez
une machine chez le même code provider
que vous avez, vous assurez
qu'il y a suffisamment de vente passante
ainsi que suite et vous préparez votre test
donc votre test vous allez
créer un scénario
donc là il y a plusieurs solutions
j'en ai parlé tout à l'heure rapidement
mais vous allez essayer de créer
des utilisateurs typiques
mais ou alors
mais ça il faut en parler avec les développeurs
c'est quels sont les trucs les plus critiques
pour l'application
moi j'avais en mécanique
ce qui est crôlement site
c'est le crôling google
donc il m'a dit
c'est tel page, tel page, tel page
j'ai récupéré les pages
il a fiché les petites annonces
par départements, viles, machins etc
donc forcément il chargait tout en mémoire
ça écrouait la machine
en fait j'ai fait ça, j'ai pris
toutes les pages, il y avait toutes les villes
et mon test
il chargeait toutes les villes en parallèle
et en fait je l'ençais
un scénario test
et il chargeait toutes les villes au hasard
sur X utilisateur en parallèle
donc une fois que vous avez votre scénario
qui fonctionne
pour un seul utilisateur
ça va marcher pour plusieurs
vous faites un petit tir avec 10 utilisateurs
pour vérifier que ça fonctionne bien
il n'y a pas de lock, machin etc
et éventuellement si vous avez la possibilité
vous allez tester ce scénario
sur la prod
parce qu'en fait ça va vous donner
des tiers de référence
donc vous allez pousser la plateforme
dans certains chemins
et vous saurez combien d'utilisateurs
vous allez pouvoir avoir
combien d'utilisateurs c'est quoi ?
combien d'utilisateurs simultanés
ou combien d'utilisateurs sur une tranche de temps
et en fait ça va vous donner
une échelle à avoir
parce que globalement votre client
va vous dire je veux faire 10 fois plus
donc ça va vous donner
une référence
et finalement
comme vous avez pris
le test
qui va écrouler la plateforme de manière sûre
tous les autres cas un petit peu
à la marche ils vont passer plus facilement
je pense que ceux qui vont écouter sa revanche
parce que je parle beaucoup avec les mains
ensuite on va préparer sa plateforme
ça va être la plateforme
la future prod ou la plateforme de terre
on va lui charger les données
on va mettre des données identiques
à la prod en termes de volumetries
et ainsi de suite
et en fait
vous avez lancé votre premier tier
donc votre plateforme est optimisée
vous allez lancer un tier
dans l'idéal vous prenez la cible
que vous avez réussi
à atteindre sur la prod
si vous y arrivez tant mieux
si vous n'y arrivez pas vous allez commencer
à essayer de faire du tuning
de vos différents trucs
comme vous avez développé
déployer votre application sur votre infrastructure cible
vous avez mis en place tout le monitoring
dont Mathieu nous a parlé tout à l'heure
comme ça vous aurez les graffes de performance
etc vous saurez exactement
quels sont les points et vos problèmes
et vous pourrez ajuster les curseurs
rajouter de la RAM sur tel process
mettre plus de conteneurs sur tel process
et ainsi de suite
et en fait à chaque fois que vous allez faire un tier
vous allez analyser à la fois les données du tier
donc en gros quand vous vous faites un tier
vous allez avoir un graphique
de l'évolution des requêtes HTTP
donc le temps de réponse
de chaque requête
donc moyenne
du nombre d'utilisateurs similitant
le nombre d'erreurs
500 etc et donc votre but
c'est d'arriver
à avoir un maximum de requêtes en parallèle
avec zéro erreur
parce que si vous commencez à avoir des erreurs
ça veut dire qu'il y a un problème
dans votre application et ça il faut totalement
de proscrire et après
au bout d'un moment vos requêtes elles vont être
plus en plus lentes mais c'est pas grave
parce que c'est votre application
elle marche toujours
encore une fois c'est pas grave
mais ça dépend des logiciels que vous voulez avoir
et c'est l'accord
et ensuite on revient toujours à la même méthode
c'est qu'on fait un changement
et on en fait qu'un seul
donc par exemple vous voulez appliquer un tuning
sur la base de données
vous noter dans votre tier
quel est le paramètre de la base de données
que vous avez changé, vous faites votre tier
vous avez rajouté des workers
sur votre serveur d'application
vous refait un tier avec
le service de l'application
et en fait vous allez faire des changements croisés
pour essayer d'optimiser un petit peu
et avoir
l'optimum en termes
de base de données, de serveurs d'application
de frontaux, machin, proches
vous essayez de tester au maximum
tous les composants que vous avez dans votre infrastructure
et puis comme toujours
vous retournez au point 5
donc vous relancez un tier
vous analyser le tier, vous faites un changement
et vous bouclez
juste pour être content de votre résultat
voilà pour moi et visiblement
Christophe avait des choses à rajouter
oui parce que ce que tu as dit
me fait penser à
partager mon expérience
alors déjà pour ceux qui n'auraient pas compris
ou pas suivi
on podcast, allez voir la vidéo youtube
pour se revoir
Nicolas, bouger dans tous les sens
en fait je me dis je sais pas si vous vous avez
travaillé dans des grands groupes mais moi j'ai beaucoup
travaillé dans des grands groupes et du coup je vais vous partager
mon expérience sur ce qui se passe dans les grands groupes
là dessus, pas forcément sur les tests de performance
mais sur la gestion des environnements
tout à l'heure Mathieu nous apparaît
de faire des tests en staging alors
ne faites pas ça rare, le staging c'est pas fait
pour faire des tests de performance, c'est fait pour
tester les fonctionnalités de votre application
si vous voulez faire des tests de performance
soit vous le faites en prod comme l'a expliqué Nicolas
mais dans les grands groupes c'est pas comme ça
que ça se passe, dans les grands groupes on a
un environnement qui s'appelle la préproduction
qui est l'environnement avant la production
qui sert à deux choses
la première c'est à tester les déploiements
et la deuxième c'est à
tester la performance parce que souvent
les grands groupes ayant un petit peu
les moyens, leur préproduction ressemble
peu ou prou à la production
dans des dimensions qui sont équivalentes
et notamment chez Kézinoo c'était le cas
notre pré-prod était
équivalente à la prod, elle était
iso, les machines c'était les mêmes
parfois même on faisait
des rafraîchissements de données
pour les rafraîchissements de données
je vais en parler un petit peu
parce qu'il y a un truc c'est vrai
on a tendance à se dire qu'il faut anonymiser
mais en fait si votre environnement
il est interne à la société
il n'y a pas forcément besoin d'anonymiser
surtout si les personnes qui accèdent à votre pré-production
sont les mêmes qui accèdent à votre prod
là ça a aucun intérêt d'anonymiser
la seule chose qu'il faut
faire c'est faire attention aux emails
pour éviter d'envoyer des emails
aux gens si vous faites des tests en pré-production
mais vous pouvez quand même anonymiser vos données
ce que faisait
un des clients chez qui j'étais
qui était la caisse primaire d'assurance maladie
en fait
nous on géré
les infrastructures dans le data center
qui était à Saint-Etienne
qui géré les infrastructures de
tout aura, au verne renalp et autres
donc on était à l'intérieur du data center
et on avait une salle
à l'intérieur du data center
qui était reliée physiquement
aux machines
pas de pré-production mais à un environnement
particulier
et il n'était pas connecté à internet
il était vraiment isolé complètement
et il tournait en vasclos
c'est à dire que les machines étaient reliées
à une salle où il y avait des ordinateurs
et si on voulait physiquement tester des choses
on allait à ces ordinateurs précis dans cette salle
précise et ça j'ai trouvé que
quand on a les moyens c'est le mieux
parce que du coup
il y avait de la virtualisation donc on relançait
des environnements complets
c'est cette fameuse expérience
où j'ai dû mettre 5 jours
à installer un environnement complet parce que la barre
n'était automatisée à l'époque
mais en gros l'idée elle est sympa
c'est à dire si vous avez les moyens
et ça peut se faire de manière virtuelle avec des VPN
c'est avoir
un environnement qui est complètement isolé
du web
sur lequel vous pouvez vous connecter soit avec un VPN
soit
physiquement c'est encore mieux
et là vous faites vos tests de charge sur des environnements
qui sont isos et vous les chargez avec les données de prod
parce que là vous êtes complètement sécurisés
voilà c'est tout ce que j'avais à vous partager pour ce retaut
d'expérience, Nicolas
c'est vachement intéressant parce que
maintenant avec des outils comme Terraform
en Cible, Sale Stack et Compagnie
vous pouvez monter
votre environnement de perre
et vous pouvez le monter quand vous en avez besoin
et ce qui est vraiment génial
et je sais qu'il y en a qui le font
c'est vous avez une nouvelle release de votre application
pas dans votre CI
vous faites un Terraform Apply
vous avez votre infrastructure
vous faites votre en Cible, Playbook
Vibru Truc, Sale Stack, I State
vous avez votre environnement
de performance isoprode
qui est déployée
vous avez des données qui sont pertinentes
par rapport à la volumétrie
et vous lancez votre GagClean
votre truc de perre et vous regardez
les temps de réponse
énormément, les temps de réponse
ne sont pas changés avec la release d'avant
donc vous pouvez envoyer ça en train
et comme votre test de perre
est terminé, je fais
Terraform Destroy et c'est bon
ça vous a coûté 10 balles
et vous savez que votre application
en prod, ça va rouler
mais tu voulais dire que
la Play est pas Terraform
la Play, j'étais trompé
les deux ça marche, ça dépend du quel contexte
mais Nicolas est un peu joueur
ça ne vous a pas coûté que 10€
ça vous a coûté un peu plus cher, déjà il a fallu
tout créer, ensuite
ça dépend la taille de vos environnements
mais grosso modo
ça vous coûte mais pas tant que ça
mais par contre
c'est vrai que
ça demande
du temps et des compétences pour faire
tout ça. Alors sinon
dans le même style
et dans les entreprises qui ont les moyens
il y a un outil
qui existe, c'est Goryplay
en fait vous prenez une capture wire shack
vous l'injectez dans Goryplay
et en fait il va re
re-injecter votre trafic sur votre plateforme
alors bien sûr
ça range pour le faire sur une plateforme
de test, mais en fait ça va vous faire
un test de charge
réel par rapport à la prod
et là vous n'avez même pas, vous embêtez
à faire votre scénario, etc
et sinon il y a une autre possibilité
c'est
Cloudflare qui a cette option là
où en fait vous envoyez
tout le trafic entièrement
du cliquet sur une autre plateforme
qui elle ne fait rien, elle est
pas connectée à la base de données, prod etc
mais
elle a une copie de la base de prod
et en fait à chaque fois que vous faites
une requête sur la prod
c'est envoyé sur cette plateforme là à côté
et en gros vous allez comparer
les temps de réponse des deux
et donc sur la plateforme de la côté
bien sûr vous avez installé votre nouvelle application
avec la nouvelle réalise qui va tout casser
parce que les développeurs ont rajouté
plein de fonctionnalités
et vous allez voir les temps de réponse qui ont changé
et ben merci, je pense qu'on peut
vas-y alors
il y a qu'on se passera la section des outils
si vous faites du gore play de mémoire
c'est à dire que vous faites pas de TLS
est-ce que je me trompe ou pas encore
je sais que ça marche pas non sur
alors je dois dire que je n'ai jamais essayé
ouais et non et je voulais juste
aussi dire que en fait dans ma boîte
d'après-prendre on l'appelle Staging
doux Christophe, ce que tu disais
peut-être un nom étrange
mais oui en fait son appel Staging chez nous
c'est l'environnement avant l'apprendre en fait
et l'environnement avant le Staging c'est quoi ?
on va apprendre à désirer
on va dire en fait on a plein on clique
sur un bouton et on monte à l'environnement
on en a c'est pas peut-être 150
d'accord
c'est à la demande
en effet c'est pas une définition
classique que je rencontrais dans d'autres boîtes
bah pourquoi pas
c'est pour ça que j'étais un peu perturbé
bah merci
du coup on va passer aux outils
alors
Nicolas nous a spoilés donc
j'ai mis en entrée les outils de test de charge
donc il nous a parlé de
Goryplay qui est un outil de test de charge
on a parlé aussi de Gatling
est-ce que vous voulez dire un petit mot
sur Gatling ?
je l'ai utilisé un peu
il y a longtemps
ça marche
j'ai rien d'autre à dire
est-ce que c'est un outil
qui est facile à décrire les scénarios
si tu sais faire du stade là c'est très facile
bah plus sérieusement
j'ai essayé le module
où en fait
on va mettre un proxy
et il va capturer tout ce qu'on fait
à travers ce proxy là pour en faire un scénario test
alors ça marche pour avoir
une idée de ce qu'on va pouvoir faire
mais je vous conseille de réécrire le test
from scratch
c'est un dsl un petit peu particulier
mais ça va vous permettre de rendre
votre test beaucoup plus modulaire
par la suite surtout quand vous allez
vous augmenter le nombre d'utilisateurs en parallèle
et ainsi de suite
après c'est un outil comme un autre
et une courbe d'apprentissage
si vous voulez vraiment le maîtriser
ça va vous prendre du temps
et je pense que des gens qui maîtrisent ça
ils peuvent en faire un métier quasiment
à part entière parce que
la mesure de perf
c'est un métier
je pense qu'en effet la mesure de perf
avec la scalability
excusez moi je dis n'importe quoi il est tard
avec la supervision
c'est vraiment un métier particulier
à part on peut faire ça
auto cop à côté mais quand on veut aller
plus loin il faut vraiment s'y consacrer
à platan
par contre tu as dit un petit truc important
c'est scalabilité
je vais en parler après
j'y metteur
aussi je crois qu'on en a
brièvement parlé est ce que quelqu'un vous
donne un petit mot dessus
oui moi c'est ce que
c'est un outil peut-être le plus ancien
voilà alors l'interface est peut-être un peu vieillote
mais bon ça fait le job
moi je fais un outil que je trouve pas mal
souvent pas mal de possibilités
ça peut s'étendre avec des plugins
voilà
et moi je voulais vous parler de mon petit chouchou
qui est l'ocustio qui a un outil
qui est écrit en python
et si je parlais de scalabilité
c'est parce que j'avais le nez
sur la page
pour me rappeler alors de mémoire
c'est un dsl python c'est assez simple
parce que moi je ne connais pas python
et j'ai pu écrire des scénarios
alors c'est des scénarios qu'on écrit
il n'y a pas besoin d'interface graphique
on écrit des scénarios ça s'interface
sur du web
c'est distribuer escalable
ça veut dire que nos scénarios
ils peuvent s'exécuter sur une, dix, vingt machines
en fonction de la puissance dont on a besoin
pour tester notre infrastructure
et ça nous fournit des rapports
assez simples et ce petit outil
qui est simple mais qui fait le son taf
Nicolas tu voulais parler justement de scalabilité
par juste avant je vais
ajouter une petite précision
sur les outils de pès de pair
en général la gestion des assets
c'est
etsylone dans vos problématiques d'infrastructure
parce que fournir des fichiers statiques
n'importe quel serveur
et un moyen de bien
s'incrocher la gestion
de votre bande passante pendant les tests
c'est de ne pas charger ces assets justement
et donc vous allez vous concentrer
sur toutes les requêtes, diètes, postes etc
de votre API
et du coup ça vous fait ça moins
à rajouter dans vos scénarios test
ils vont être beaucoup plus légers
et du coup je voulais aussi
rebondir sur scalabilité
donc typiquement quand vous utilisez
des outils comme
comme ceux dont on vient de parler
avec quelque chose qu'on utilise
Gatine etc
c'est si vous utilisez un prode avec un auto scaling
désactivez l'auto scaling
parce que sinon vous allez scaler
à l'infini
votre facture sera au-delà
de ce que vous pourrez
payer votre boîte
et surtout votre test
absolument pas pertinent puisque
ce que vous voulez c'est mesurer
à taux constant de VM
donc c'est pour ça qu'avoir
une plateforme de performance
dédiée à ça
ça peut être vraiment intéressant
si vous pouvez tester
vous mettez 4 VM pour avoir
une idée de ce que ça peut donner
vous lancez vos tests à 10, 20, 30, 50
000 utilisateurs et ainsi de suite
et comme ça vous saurez
combien ça va vous coûter
pour avoir le maximum d'utilisateurs
par exemple 50 ça va vous coûter
40 à 40 000
100 000 ça va coûter 8 et ainsi de suite
c'est marrant parce que moi je n'aurais pas donné ce conseil
là j'aurais donné le conseil
de limiter votre auto scaling
à peut-être 2, 3, 4 machines
mais pas plus parce qu'en fait
vous voulez aussi tester en lançant
vos tests de charge que votre infrastructure
elle scale toute seule
si vous le désactivez vous ne pourrez pas tester
cette fonction là vous pouvez tester
chaque serveur unitèrement mais
si vous voulez tester la scalabilité il faut limiter
en effet pour limiter votre facture
et du coup ça peut être un test complémentaire
effectivement comme tu le dis
et avec un outil comme Gatling je sais que c'est possible
tu peux dire tu commences
avec un utilisateur
tu termines avec un utilisateur
et entre les deux t'en es dîmes
donc tu fais une espèce de courbe de Gauss
et du coup vous pouvez tester
que votre auto scaling groupe va grandir
et que votre auto scaling groupe va réétrecir
effectivement c'est aussi un test très intéressant
alors je crois que tous les outils qu'on a cités
là sont des outils libres
là on va parler d'outils SASS
qui ne sont pas des outils de test de charge
mais je crois qu'ils sont des outils de supervision
slash APM ça dépend desquels
moi je n'ai pas une urolique
parce que ça a été longtemps mon chouchou
c'est simple à prendre en main
mais par contre c'est assez cher
il y a un APM qui est
de mémoire et de réputation très efficace
et une supervision
qui est assez efficace je sais pas ce que vous en pensez
mais c'est pas si important
d'avoir une urolique ça marche
ma boîte l'utilise
on a tendance à transitionner vers autre chose
comme je disais au début
aujourd'hui on a du tracing en place
avec un standard open telemetry
on a des maitris qu'on va m'appromter
dans les applications
et on se rend compte que la partie APM
est-ce qu'on en a encore vraiment besoin
moi c'est un peu ma philosophie aujourd'hui
je me dis pourquoi j'ai besoin d'un APM
si j'ai des maitris qui est des traces dans mon appui
j'ai tout ce qu'il me faut en fait
et ça sera encore mieux
c'est que j'aurai la main
je pourrais vraiment avoir des maitris pertinentes
moi qui les place, des vrais maitris
mes métiers parfois
sur le business ou autre
intégrer dans mes applications
donc urolique ça marche très bien
mais je le vois utiliser
c'est à dire que les gens mettent un APM
mais ils ne mettent pas de maitris
les appis de l'APM c'est là pour compenser
au final si on réculture le maitris
moi c'est comme ça que je l'ai vu
je ne dis pas que c'est comme ça partout
mais je l'ai très souvent vu comme ça
et moi je le vois moins l'utilité des APM aujourd'hui
s'il y a une culture de la maitris
et de la trace
Nicolas, après je prends la parole
oui, j'allais dire que
moi je conseillerais les APM dans deux cartes
c'est
vous arrivez sur une application
il n'y a rien du tout
mettez une urolique, ça ne pousse quasiment rien
à déployer
c'est par contre, ça va vous aller casquer
si vous avez du volume
mais bon, il n'y a rien de gratuit dans la vie
et
si vous n'avez pas le temps
de rajouter des maitris
mettez un APM, ça fera déjà
ça qui vous permettra d'analyser
le jour où vous aurez des problèmes
et par contre comme le dit Mathieu, si vous le faites vous-même
les maitris sont encore plus pertinentes
mais c'est un chantier
qui peut être énorme si votre application
a déjà deux ans d'existence
vous n'y arriverais pas
à des maitris rapidement
donc mettez un APM dans votre premier temps
en même temps que le chantier
pour faire vos propres maitris
du coup, moi je vais donner
une troisième voix encore différente
et dissonante mais c'est bien parce que du coup on a des avis différents
mettez en place une supervision
quoi qu'il arrive
vous pouvez mettre en place une urolique, data dog
ou je ne sais quoi, si vous n'avez pas le temps
mettez un SAS en supervision
nous on commence par urolique
data dog c'est pareil, ça s'installe en 5 minutes
il y a des re l'encible
il y a ce que vous voulez, ça s'installe vite
par contre
une fois que vous avez mis ça en place
et si vous êtes en face de développement
de votre application
vous pouvez mettre en place un APM
et c'est comme ça que moi je le conseille
à mes développeurs c'est
en face de développement, sur les environnements
hors production ou production mais
dans un temps limité et court
en face de développement parce que
c'est toujours au début du développement
de l'application qu'on a des problèmes
de performance et autres
supervision plus APM
vous permet d'avoir des informations
hyper pertinentes
moi je ne sais pas vraiment
utiliser le tracing mais
l'idée c'est
pas la peine de le laisser là, à AdVitaMaternum
ça ne sert à rien, c'est vraiment au coup par coup
j'ajouterai une dernière fausse sur ça
et c'est en lien aussi avec Datadog
comme ça on parle des sujets suivants c'est que pour moi c'est très important
d'avoir des formats standards
Neuralik supporte le format open telemetry
on l'utilise aussi comme ça
et donc au lieu de se dire on va utiliser un APM propriétaire
qu'on va installer dans l'appli et tout
on utilise des formats de métric standard
qu'on envoie ensuite
à Datadog, à Lue
à Liger, pour les traces
ou à Tempo de Grafana
mais ça c'est un détail, le stockage devient un détail
d'implémentation et ça c'est très important
pour moi et ça c'est vraiment le futur
pour moi, notamment Open telemetry
c'est l'idée de se dire
on va avoir plusieurs plateformes cloud
de stockage, d'analyse de métric et de traces
mais dans les applications
on aura un standard
implementé par Datadog, Neuralik etc
Justement Datadog
ça fait peu ou peu la même chose que Neuralik
moi c'est devenu mon nouveau chouchou après Neuralik
parce qu'il coûtait moins cher à l'époque
Datadog avait l'avantage aussi
de faire un truc, je ne sais pas si Neuralik le fait maintenant
mais il fait Supervision
il fait APM et il fait
centralisation des logs, attention ça coûte
très cher, c'est hyper facile
à mettre en place
et il est con de votre plateforme
il est con de votre plateforme c'est-à-dire
moi c'est celui que j'ai essayé d'installer
chez un de mes clients et en fait
on active l'agent PHP
et l'application répond plus
l'agent APM tu veux dire PHP
ou l'agent APM
c'est pour ça que je disais
éviter de mettre trop longtemps
en prod des APM
parce que les APM c'est consommateur
il faut le rappeler
je crois qu'il y a une théorie quantique
qui dit que tu ne peux pas
mesurer un système sans le modifier
lui-même un truc comme ça
c'est valable aussi dans la formatique
Exactement
On a Rollbar
ça ce que je ne connais pas, j'avais entendu parler de nom
je ne sais pas, est-ce que l'un de vous l'a utilisé ?
Pour moi c'est un des éléments
qui est super important, ça permet
de remonter les erreurs
qui sont les plus fréquentes
au développeur et après on va
cocher la case de ces bronces
à ces traités, ça c'est correcté
dans tel autre truc mais ça vous permet
d'avoir vos stacktrace très facilement
et comme disait Mathieu tout à l'heure
à partir du moment où tu as
un cluster cube nomad etc
tu n'as pas de temps de m'user à te connecter
et en fait ça permet de centraliser les stacktrace
et si je les mets dans les APN
c'est qu'en plus il fait APN
donc je ne connais pas la partie APN
mais par contre
pour collecter les stacktrace
c'est un outil assez intéressant
On a aussi Senntree
qui est un sas aussi
mais je crois qu'il y a une version libre aussi
c'est-à-dire parce que
GeekLab le fournit en serveur
Senntree, moi je l'ai beaucoup utilisé
je l'utilise toujours
la version primaire
c'est impossible d'installer
il y a 50 dépendances
je pense que c'est by design
avant c'était très simple d'installer
à un moment ils ont fait une usine à gaz
comme ça ils se sont dit tout le monde va y dans le cloud
moi c'est mon avis, c'est du open source
après je...
je trouve extrêmement médisant
c'est un bundle comme GeekLab
qui lance un script sur ta machine
construit les images dockers
à des fois les images dockers
oui voilà mais bon c'est...
Christophe, connais aussi mon avis
pour GeekLab, pour Giro aussi
on pourrait parler de performance
et de rubis et de set kick
mais on pourrait faire un podcast dédié
sinon Senntree ça marche très bien
mais on est là aussi plus sur de l'analyse de Log
de Stack Tress notamment
donc moi Senntree vient vraiment pour
investir un problème et pas pour le détecter
moi je m'attends à avoir un problème de perte
de détecter les démétriques
sauf si ça a changé depuis
c'est Nicolas, je te vois...
en fait moi j'ai déployé la version open source
pour CDWire
et en fait il y a aussi la partie
telemetrie, performance etc
donc
si ton besoin principal
pour tes développeurs c'est d'avoir
les Stack Tress et toi tu dois avoir
un petit peu d'APM
pour regarder du côté de Senntree
je suis entièrement d'accord c'est le ginaigaz
mais ça rend bien certain
oui et n'oubliez pas
que Dieu tu un chaton
à chaque fois que vous avez recouvre
que vous détectez un incident via une alerte Senntree
vous pouvez pas de l'alerting sur des logs
si vous voulez
voilà
pour conclure
sur ces outils là
moi j'en ai utilisé pas mal des outils comme ça
et j'ai souvent eu des problèmes de performance
sur ces outils
parce que j'avais trop de VM
application etc qui envoyaient des logs
à ces trucs là
et en fait mon métier c'était
débeuguer les pertes
des APM
ok alors évidemment on peut pas
tous les citer parce qu'il y en a énormément
en sas etc donc on va passer
aux solutions Libre et Open Source
Libre et ou Slash Open Source
donc il y a aux potes telemetrie dont on a beaucoup parlé
on vous met le lien en description
tu parlais de problèmes de performance
du coup je vais parler de net data
qui a un petit tout petit supervision
qui est très léger
à installer sur les serveurs
et qui permet d'avoir des données en temps réel
vraiment assez pertinents
je trouve que c'est un bon complément
au deuxième qui suit qui est
la stack promettéus, Loki, Grafana
alert manager etc
Grafana fait
beaucoup d'outils
de ce type là
je crois qu'ils ont pas encore d'APM du coup
oui Nicolas
en fait net data tu peux le déployer
soit sur une seule machine
et dans ta stack là tu as le IHM
mais tu peux aussi pousser les données
dans autre chose
comme promettéus
un flux dv etc
et du coup tu vas retrouver exactement
tes mêmes métriques
oui tu peux agrégé
les métriques moi c'est vrai que je l'utilise pas
dans ce cas là mais c'est en effet
le possibilité
si vous utilisez promettéus
Loki, Grafana, tous ces outils
là permettent de faire
de la supervision
la centralisation de Log et on a dit pas d'APM
précision peut-être
comme
oui vas-y
qui ?
comme Mathieu l'a dit plusieurs fois
ne mettez pas d'APM ça sert à rien
fait de l'open telemetrie
dès le début dans votre projet
mettez des métriques dans votre projet
et utilisez la stack promettéus, Grafana, Tempo
et en fait vous aurez plus besoin d'APM
et en plus vous aurez une solution
pour une source et si vous voulez
dépenser des sous, Grafana et vous les prendre
et j'ajouterai une chose
c'est que promettéus c'est très bien moi je l'utilise
par contre on peut avoir des problèmes de perte
mais moi j'ai des instances
ça monte aussi très vite
mais c'est un autre détail
mais juste une chose c'est que promettéus n'est pas fait pour du stockage de métriques long terme
ce promettéus a une rétention
de 7 jours
de 2 jours même voilà
et souvent on passe par des outils pour avoir du
ce que la performance est aussi intéressante
pour faire des amis sur le long terme
à une semaine, un mois, 6 mois etc
et donc là on trouve des outils
historiquement graphite
par exemple maintenant on voit des choses comme Cortex
qui a été sorti
récemment par Grafana
qui est un métrique de stockage
long terme pour promettéus, on utilise Tannos
dans mon entreprise
qui marche également très bien et l'idée c'est
d'avoir accès à ces métriques long terme
parce que promettéus j'ai dit une rétention très faible
d'avoir l'aussi de pouvoir faire du sampling
donc dire
à 6 mois je garde
3 mois je garde toutes mes métriques
entre 3 à 6 mois je garde toutes mes métriques
mais sur une
toute les 5 minutes
par exemple et à 6 mois et 1 an c'est une toute tes heures
et donc ça c'est aussi un aspect important
sur l'évolution de long terme
des performances d'avoir ce genre d'outils
et de penser sur plusieurs mois
historiquement on avait des outils
comme Cacti qui utilisaient des bases
et RRD c'était quoi
préciser la temporalité
de je veux garder
telle métrique sur telle
calcul sur tant de temps
et en gros sur une année je veux garder
le maximum, la moyenne, le minimum etc
et la base elle tournait automatiquement
et ça c'était génial
et c'est vrai que ça
ça me manque beaucoup dans le promettéus
du coup on peut parler de Cacti
Nageos etc avec sur des outils
un peu vieillissant quand même
quand on est des ingénieurs
des votes on utilise des outils
totalement hype
et on utilise plus des trucs de dinosaure
oui c'est vrai d'ailleurs vu qu'on a parlé
de la stack Grafana on peut parler
de la stack Elastique
puisque moi ma préférence va la stack Grafana
mais la stack Elastique
ELK et la stack search
Loxtash et Kibana
sont une stack de super visions
assez répandue
et Elastique a aussi un APM
je sais vous avez dit je ne sais combien de fois
n'installer pas d'APM mais bon voilà
il fallait qu'on en parle
le gros intérêt d'Elastique
c'est qu'il n'y a qu'une seule base de données
et si vous avez des gens qui savent gérer
de l'Elastique search
utiliser Elastique pour
collecter vos logs pour maitriques
parce que vous aurez les ingénieurs
qui sauront skyler
votre cluster Elastique
pour maitris performances
et vous n'aurez pas un A&M
techno à rajouter dans votre infrarre
et qu'il faudra gérer
parce que comme disait Mathieu
et Prometeus, au bout d'un moment
ça va se casser la gueule
et si vous gérer déjà
un cluster Elastique à côté
vous aurez un cluster Elastique de plus
et si vous faites du big data
à côté, votre petit cluster Elastique
pour le gérer le système, ça sera plus le plus
merci
moi j'ai rajouté
dans la liste Zabix
qui a mon petit supervision
aussi libre
ou Nicolas ?
je l'utilise
pourquoi tu ne l'as pas mis ?
si y avait pas pensé ?
parce que je suis en train de le virer petit à petit
je l'ai pas testé
mais il faut qu'on le cite
alors ben je peux expliquer rapidement
au tout début c'était
un concurrent
à Nagios pour faire de l'alertine
le principe c'est qu'il y a une base de données
post gré dans lequel
on injecte des données
et ce qu'il y a de très intéressant c'est que ces données
là, ils s'en servent à la fois pour l'alertine
et à la fois pour
des graphes
pour faire de la performance
donc ça va vous remplacer votre couple
Prometeus, Alert Manager
et Graphana
et c'est assez sommaire
c'est en train d'évoluer petit à petit
et ça vient de plus en plus
plus modulaire pour prendre
en compte les instances cloud etc
c'est juste que
c'est un petit peu vieillissant
et maintenant je préfère la salle Prometeus
mais Zavik c'est très très intéressant
et si vous voulez
un système d'exploitation
pour professionnel comme dirais un copain
c'est
Zavik, ça existe depuis très longtemps
et c'est un vrai système de monitoring
d'alertine qui prend en compte
plein de prutes comme des plages
de maintenance et ainsi de suite
que vous pouvez faire avec Prometeus
mais différemment il va falloir sculpter tout par vous
et enfin on va finir par 2 outils
de tracing
donc Zipkin, qui veut nous parler
de Zipkin
jamais utilisé
moi je l'ai mis parce que je connais
deux noms mais
c'est un outil de tracing
du coup c'est un outil de tracing qu'on n'a pas utilisé
donc si il y en a qui l'ont utilisé
dites nous là en commentaire
dites nous hey j'ai utilisé Zipkin
c'est bien hey j'ai utilisé Zipkin c'est à chier
bon bref donnez nous votre retour
parce qu'on l'a pas du coup
mais on l'a cité
et enfin il y en a en effet que je connais
c'est alors Yeager, c'est comme ça que ça se prononce
Yeager, comme Yeager Master je présume
que je n'utilise pas, je vais mettre assez de soin ailleurs
mais non mais après moi Yeager
j'ai ouvert la dog, j'ai vu qu'il fallait qu'elle cassera
j'ai fermé en fait
ou Elasticseur je crois c'est au choix
et qu'est ce que tu utilises alors Mathieu pour tes traces
on a tout dans New Relic
mais c'est de le pun télévision
et bien je crois qu'on a fait le tour
alors je crois que c'est probablement
l'épisode le plus long qu'on aura enregistré
parce que je vois mon petit compteur on a déjà
à 1h37 minutes
donc on va finir à 1h40
mais si la sortie
d'épisode on aura enregistré d'autres
qui auront duré encore plus longtemps
j'espère que non
Nicolas dit ça parce qu'on a de l'avance
on a plusieurs mois d'avance donc quand on enregistre
l'épisode là il sort plusieurs mois d'après pour vous
mais j'espère que non parce que ça commence
à être long, il est tard, il fait chaud
je ne vois tout censure
donc chers compagnons
si tu as apprécié ce podcast
viens en discuter avec nous dans la communauté
des compagnons de VidiVops
si tu n'es pas inscrit, inscrivez-toi
c'est dans la description
moi je vous remercie tous les 3
d'avoir participé à ce podcast
qui était encore une fois très intéressant
je pense qu'on n'a pas fini de faire le tour
du sujet de la supervision
de l'alerting
et des tests de performance
on y reviendra probablement dessus
un jour mais pas tout de suite
du coup
je vais vous laisser le mot de la fin
et je ne vais pas commencer par Batiou
comme ça il aura le temps de préparer
son mot de la fin et je vais commencer
par Nicolas
qui est calme même des Vops
merci Nicolas, René
quel est ton mot de la fin
on a quand même vu
2 technologies à la fin
on a parlé des Hard and Tool
et de... ah zut
du coup j'ai mangé le...
Zabix
moi ce qui est un truc qui m'intéresse
c'est que c'est pas parce que des fois
c'est des techniques un peu anciennes
qui sont forcément mauvaises
donc voilà, ça sera un moment de la fin
regardez parfois des techniques qui sont un peu vieillissantes
il y a des choses qui sont des fois pas si mal
je suis d'accord avec toi
faut choisir la technique adaptée à son besoin
Mathieu, tu as eu le temps de préparer ton mot de la fin
donc tu as le mot de la fin
de la fin
mon mot de la fin c'est que mettez des métriques
dès le début dans vos applications
et n'utilisez pas les... comme on l'a dit plusieurs fois
la solution de facilité
que sont les APM
parce que sur le long terme vous allez vous moindre
des doigts et en plus ça vous coûtera très très cher
dans tous les sens du terme
merci d'avoir écouté Radio DevOps
n'oublie pas de noter l'épisode
plus la note sera élevée et plus sera mis en avant
dans les applications
tu peux aussi le partager
ça nous aidera à le diffuser et à rendre le mouvement
plus visible
si tu as envie de discuter du mouvement
alors rejoins nous dans la communauté
des compagnons du DevOps
à bientôt
la balade aux diffusions des compagnons du DevOps
est produite par Lydra