Observabilité, c'est un terme que vous avez déjà certainement entendu parler ou que
vous allez entendre parler très très régulièrement.
On le voit souvent dans des blog posts et c'était un élément prépondérance en matière
d'architecture sur différents outils qu'on utilisait parfois auparavant et qui ont eu
besoin un petit peu d'être refondus.
Donc on va découvrir tout ça ensemble.
N'hésitez pas à vous abonner à ce podcast ou à le partager autour de vous.
Jingle et c'est parti !
Alors oui, l'observabilité, c'est quelque chose d'important.
La première chose qu'on peut dire sur l'observabilité, c'est qu'il existait déjà des éléments
précurseurs à cette brique qui est l'observabilité puisque finalement l'observabilité, c'est
une fusion de trois éléments.
On va y revenir tout de suite.
Mais historiquement, une partie de ces trois éléments existait déjà puisque tout simplement,
ces trois éléments, on va les résumer à d'une part le monitoring, en tout cas les
maîtriques liés au monitoring, d'autre part les logs et par ailleurs le tracing.
On va revenir un petit peu dans le détail sur chacune de ces briques, mais en tout
cas, vous voyez déjà quand on parle de monitoring, maîtrique, c'est des choses qui existent
depuis des dizaines d'années et également quand on parle de logs, ça existe déjà depuis
plusieurs dizaines d'années, on va dire.
C'est quelque chose qui est quand même relativement ancien et pour autant, c'est deux briques
essentiels de l'observabilité.
Alors pourquoi ? Parce que tout simplement, les pratiques se sont intensifiées, les périmètres
se sont étendus.
Il faut voir ça sur l'ensemble de chacune des briques.
Ce qui se passait auparavant, c'est qu'en tout cas, plus historiquement, les données
qui étaient collectées étaient plutôt collectées avec des spécificités liées au système d'information
ou au système informatique même lui-même, c'est-à-dire plutôt des maîtriques de réseau,
de système et on cherchait plutôt à savoir comment fonctionner, est-ce que en tout cas,
nos serveurs fonctionnaient correctement, notre infrastructure fonctionnait correctement.
Maintenant, les périmètres se sont vraiment beaucoup étendus avec bien sûr la partie
applicative mais également et encore en plus des données métier pour pouvoir accentuer
la supervision et voir des défaillances qui ne sont pas forcément strictement applicatives
mais qui peuvent être simplement des lenteurs qui occasionnent des difficultés par exemple
pour passer des commandes, ce genre de choses.
Donc, c'est quelque chose qui est très, très important à avoir en tête.
Alors donc, on va revenir sur l'ensemble de ces trois points avec un petit peu plus de
détails et quelques petits exemples.
Première brique, donc le monitoring et les maîtriques.
La première chose qu'il faut dire, c'est tout simplement que, comme on disait tout
suite, les maîtriques ont fortement évolué ces dernières dizaines d'années.
Pourquoi ? Tout simplement parce qu'au part avant, comme je vous disais, on est passé
de maîtriques qui étaient strictement systèmes et réseaux, on va dire.
Donc, on avait toujours le CPU, le load, le trafic réseau, etc.
Eh bien, ça s'est étendu.
Ça s'est étendu tout simplement dans un premier temps à la brique applicative.
Donc, bien sûr, on supervise les applications avec les maîtriques strictement liés aux
applicatifs qui permettent de checker leur performance.
Et puis également, et ça, c'est encore un petit peu plus récent, on va dire des
données éventuellement métiers.
On peut éventuellement retrouver des éléments de chiffres d'affaires journaliers, ce genre
de choses.
Et tantôt, vous voyez, on se situe un petit peu à la limite entre la business intelligence
qui est plutôt sur des échelles de temps relativement longues.
Et puis finalement, des maîtriques qui n'ont pas un but à vérifier finalement un chiffre
d'affaires, etc.
Mais plutôt à faire ressortir des anomalies et à réagir rapidement face à un dysfonctionnement.
Donc derrière, on va coupler au monitoring et aux maîtriques, bien sûr, un système
d'alerting qui va permettre de notifier.
Il y en existe différents types, plus ou moins synchrones, plus ou moins qui va permettre
de plus ou moins de notifier les gens de différentes manières, ça peut être du MEL, du SMS ou
d'autres moyens.
Et donc ça, c'est quelque chose qui est assez important.
Parmi les normes qui ressortent des maîtriques, la collègue de ces maîtriques, on va retrouver
OpenMetric, donc qu'on retrouve sur des stacks relativement connus.
Alors justement, parlons un petit peu des stacks de monitoring et de maîtriques pour
finir de boucler avec ce premier point qui est le monitoring et les maîtriques.
Et bien, première stack généralement qui vient un petit peu à l'esprit quand on parle
de monitoring et de maîtriques, ça va être Prometerus.
Éventuellement, on tannose ou en tout cas, un back-end de Prometerus, puisque Prometerus
n'est pas fait pour stocker beaucoup de maîtriques et sur une période relativement longues.
Il a besoin de ce qu'on appelle un back-end qui est finalement son stockage long duré.
Et à côté, bien sûr, Prometerus, on va l'associer à Grafana.
Donc ça, c'est une première stack.
Deuxième stack qui existe également.
Alors là, du coup, on n'est plus vraiment sur une stack où éventuellement on peut
retrouver une combinaison entre Prometerus et lui-même, c'est-à-dire Zabix.
Zabix, c'est également un système de monitoring qui perce de plus en plus Open Source toujours
et qui fait son bonhomme de chemin.
Et pendant le même temps, et là, ça, on va le retrouver sur l'intégralité de la stack
d'observabilité ou en tout cas l'intégralité des stacks d'observabilité, il y a la société
Grafana Labs, qui est la créatrice finalement de Grafana, qui s'est développée de plus
en plus et très fortement, vraiment au cours des trois à quatre dernières années.
Il y a eu un développement considérable de différents outils de Grafana qui est
complètement sorti du simple petit outil qui était à la base simplement l'exploitation,
la mise en place de Dashboard.
Éventuellement, on l'avait en tête pour simplement valoriser les données de Prometerus.
Là, on est carrément beaucoup plus loin.
Et on va retrouver par exemple un outil qui s'appelle Mimiar.
Mimiar va permettre de stocker des métriques et s'est développé par la société Grafana.
Alors maintenant, on va parler des logs tout simplement.
Donc, c'est le deuxième point important dans la stack d'observabilité.
Donc, les logs, qu'est-ce qu'on peut dire dessus ?
Donc, l'objectif des logs, on parle généralement et historiquement de centralisation de logs.
C'est-à-dire qu'on va avoir un petit peu partout, dissiminer sur notre infrastructure
des outils qui vont permettre de récupérer des logs de système applicatif ou de système
plus généralement informatique.
Donc, on va retrouver des logs système, des logs réseau.
Éventuellement, on va retrouver des logs dédiés aux applicatifs eux-mêmes.
Et donc, tout ça, il va falloir pouvoir les collecter.
Et à la différence des métriques, on n'est pas du tout sur le même type de données.
Une métrique, c'est quelque chose qui est relativement facile à collecter puisque généralement,
c'est un chiffre tout simplement, donc un float éventuellement.
Et derrière, on va pouvoir facilement condenser cette donnée, compresser cette donnée avec
des formats qui sont assez connus, donc le delta ou le double delta, qui fait que si
vos métriques évoluent peu finalement, eh bien, vous allez vraiment pouvoir compresser
très, très fortement la donnée.
Pour les logs, c'est beaucoup plus complexe.
Donc, première chose sur les logs, les problématiques qu'on va retrouver, ça va être tout simplement
la mise en forme de ces logs.
Et là, il y a un travail encore qui est à réaliser.
On retrouve très souvent du JSON, mais il y a aussi d'autres moyens de pouvoir uniformiser
ces formats de logs, les formats 6 logs également.
Eh bien, il y a beaucoup de choses à faire pour unifier les logs entre l'aspect système,
l'aspect réseau et l'aspect applicatif.
Donc, ça, c'est une première chose qui est importante.
La deuxième chose qui est importante, ça va être le stockage de ces logs.
Bien sûr, ça va prendre de la place.
On est sur quelque chose qui est relativement verbeux.
Et derrière, il va falloir faire les bons choix de base de données type pour pouvoir
stocker ces logs.
Alors, je dis bien stocker, je dis pas exploiter les logs.
Il y a deux options en matière d'exploitation de logs.
Donc, stocker ces logs, ça va prendre éventuellement beaucoup de place et ça peut devenir très,
très coûteux éventuellement.
Donc, c'est vraiment un poste de dépense qui, je pense, au cours des années précédentes,
beaucoup de sociétés pouvaient faire l'impasse sur le stockage des logs.
Plus ça va, plus les sociétés collectent et stockent ces logs.
À la fois d'un point de vue valorisation de ces logs, c'est quand même de la donnée.
On retrouve derrière beaucoup d'informations qui peuvent être utiles, mais également en
matière de sécurité.
Il y a des aspects de Siem ou ce genre de choses.
Et ça, c'est quelque chose qui est assez important.
Alors, je vous disais ensuite aussi en matière d'exploitation au-delà du simple stockage
des logs.
Pourquoi ? Parce qu'il y a deux aspects en matière d'exploitation et deux angles de
vue différents.
L'angle de vue historique et lui, il a été apporté par la société élastique.
C'est le stockage sous format d'Ocuments avec un objectif d'exploitation relativement
intensive et offrant le plus de possibilités possibles.
C'est ce qu'on retrouve avec notamment Elastic Search.
C'est-à-dire qu'on va, chaque ligne de logs va être indexée en totalité.
Chaque élément du log va être indexé pour pouvoir couvrir le plus de cas de figure
de recherche possible.
Donc ça, c'était un premier choix qui est historique.
Le problème de ce choix, c'est qu'en matière de consommation de ressources, il est relativement
important.
C'est-à-dire que même si je ne requête pas mes logs, je prévois d'indexer ces logs.
Et ça, ça a un impact au niveau de la ressource.
C'est-à-dire qu'au moment où je vais vouloir ingérer les logs, il faut que mon moteur
de base de données en question puisse disposer de ressources assez importants, notamment
en RAM.
Ça, c'est quelque chose qui est considérable pour pouvoir indexer.
Donc ça, c'est le premier point.
La deuxième option, ça a été finalement avec le temps d'observer que finalement, les
logs, on ne les interroge pas si souvent que ça.
Et donc de fait, mettre des moyens colossaux sur quelque chose qu'on utilise ponctuellement
et vouloir avoir une réponse finalement très très rapide, c'est peut-être pas la meilleure
option.
Et ça, c'est le choix qu'a fait la société Grafana Labs, notamment avec le développement
de Loki.
Et là, ils sont partis sur une approche complètement différente en se disant, les logs, c'est
quelque chose qu'on interroge très très rarement, très souvent sur une plage de temps
relativement limité.
Et donc derrière, on va faire une recherche sur laquelle éventuellement, on peut se donner
du temps un petit peu pour attendre.
Et donc derrière, ils sont passés outre l'indexation.
Or, mis une indexation simplement du timestamp, quoi, on va dire.
Mais pour la partie vraiment string, la partie du log lui-même, ils ne cherchent pas à exploiter
l'intégralité de la verbosité des logs.
Et derrière, du coup, ça fait un gain assez considérable en matière de RAM si ce n'est
qu'au moment de l'exploitation des logs en question, donc du par le moteur de base
de données qui est Loki, eh bien il va falloir disposer de CPU puisque finalement, c'est
comme si on faisait un gros grep sur l'ensemble de ces logs.
Donc ça, c'est un choix qui a été fait.
Donc pour boucler sur les logs, qu'est-ce qu'on peut dire encore d'autres ?
Bien, tout simplement ensuite, on a aussi l'aspect qui est souvent un petit peu minoré
et qui commence à émerger de plus en plus.
C'est l'étape intermédiaire.
Donc entre la collecte des logs et le stockage des logs.
Vérrière, on a une étape intermédiaire qui est soit de la transformation, soit c'est
un petit peu plus rare ou en tout cas de l'enrichissement.
Et puis également, on va avoir de la temporisation, en tout cas des outils qui vont permettre
de la gestion à synchrone.
Alors pourquoi très, très souvent, ça va être pour permettre d'éviter de faire,
entre guillemets, surchauffer un moteur de base de données avec des pics de logs qui
pourraient être très, très importants, essayer de rendre le plus linéaire possible l'ingestion
de logs.
Pour ça, il faut utiliser ce qu'on appelle des message queue ou des commit logs, tick,
type, pardon, Kafka.
Et donc derrière, ça va être un outil un petit peu intermédiaire où finalement,
les collecteurs vont envoyer des logs sans se poser de questions en masse dans un outil
intermédiaire qui va permettre de stocker et de temporiser les logs.
Et finalement ensuite, un autre outil va venir les récupérer, un autre collecteur
finalement va venir récupérer les logs de Kafka pour pouvoir les écrire directement
dans le stockage final, par exemple, et la six search.
Donc ça, c'est quelque chose qui ressort de plus en plus pourquoi ?
Parce que tout simplement, les volumes de logs explosent.
De plus en plus, ces infrastructures sont de plus en plus grosses.
De plus en plus, on essaye de collecter des logs et ça devient quelque chose d'un sujet
vraiment très, très important.
Alors on retrouve différentes stacks pour la centralisation de logs, un peu moins de
choix ou de quatre figures possibles pour stocker les logs que pour le monitoring.
On va retrouver notamment donc la stack historique qui est ELK, donc pour elastic
search, logstache et kibana.
Et puis éventuellement des bits, donc 5-bit qui est un collecteur de logs, tout simplement,
et très, très historique également.
Et également, on retrouve EFK, éventuellement, qui est une divergente avec Fluentbit ou
Fluentd, qui sont des outils également de collect pour pouvoir écrire dans elastic search.
En parallèle de ça, on retrouve toujours notre fameuse société Grafana Labs qui existe
maintenant depuis quelques années et qui a développé un outil qui s'appelle Loki.
Et donc, on retrouve les deux quatre figures, les deux solutions qu'on a vues tout à l'heure,
c'est-à-dire d'une part EFK, donc avec la volonté d'indexer beaucoup et historiquement,
ça a été bassé sur ça.
Et puis de l'autre côté, Loki qui lui est donc la deuxième solution qu'on a vu tout
à l'heure, l'idée étant d'éviter d'indexer au maximum.
Et donc là, on voit tout de suite que la société Grafana veut se faire se centrer
et être le leader.
Et d'ailleurs, on peut maintenant les considérer un peu comme leader avec elastic search ou
le leader et l'ensemble de la stack d'observabilité.
Donc on retrouve Grafana Labs avec Loki une fois de plus.
Maintenant, on va parler du tracing.
Tracing, c'est quoi ce sont les traces ? Alors les traces, la problématique, c'est
quoi ? De quoi on parle exactement ? Alors les traces, c'est quelque chose qui est encore
un petit peu plus récent que les deux autres stacks finalement.
C'est quelque chose qui a émergé notamment avec l'arrivée des microservices.
Pourquoi ? Parce que dès lors qu'on passe à une architecture de microservices, on va
avoir un ensemble d'enchaînement d'actions sur des applicatifs différents.
Le problème, ou en tout cas la difficulté qu'on essaye de résoudre avec notamment le
tracing, c'est de se dire « Ok, quand je reçois un hit par exemple de quelque chose
sur un site de e-commerce, je veux être capable de retracer l'intégralité des actions qui
sont menées derrière sur l'ensemble de mes microservices, sur l'ensemble de l'architecture,
de manière à avoir une vision globale de quel microservice prend du temps,
lequel ne prend pas de temps et où je peux éventuellement corriger les choses. »
Et au-delà de ça, le tracing permet aussi de rentrer à l'intérieur de chacun des
applicatifs pour ensuite tracer au sein même de l'applicatif les différentes fonctions
qui vont être lancées ou les différentes actions qui sont lancées sur notre applicatif.
Par exemple, si je fais un select sur une base de données SQL, il va pouvoir dire « Ok,
voilà, tu as commencé ton action, tu fais un select, ensuite mettons que je fasse un insert,
je vais avoir une trace aussi pour l'insert. » Et donc ça va me donner le détail de ce qui
va être réalisé. Par exemple, pour une simple action de mon applicatif, je vais avoir l'ensemble
des éléments qui vont être réalisés. Donc le select, l'insert, éventuellement d'autres calculs.
Et ça va me permettre ensuite de pouvoir travailler la performance de mon applicatif
pour faire en sorte qu'il soit plus performant, donc plus rapide et réduire la latence. Donc ça,
c'est un enjeu primordial qui est couvert par le tracing. Le tracing, pour faire ça,
utilise ce qu'on appelle des spannes. Les spannes, en fait, c'est simplement des jalons sur lesquels
on va pouvoir mesurer un début et une fin d'une action, ou en tout cas d'une action donnée qui
vont être découpées en ensemble de spannes. Et donc ces actions, telles qu'on parlait tout à l'heure
des hits, pour un hit donné, on va pouvoir avoir l'ensemble des spannes qui vont être réalisés,
tracés. Et on va pouvoir dire, ok, on passe du temps à cet endroit-là, on passe du temps à cet
endroit-là, mais là on peut éventuellement améliorer de telle et telle manière. Donc ça,
c'est quelque chose qui est très, très important, qui monte de plus en plus. Et derrière, donc on
va retrouver des stacks qui vont être un petit peu différentes également. On va retrouver,
historiquement, Yeager, donc un outil qui est vraiment centré sur le tracing et qui est toujours
dans la... je crois qu'ils ont été rachetés d'ailleurs par Grafana Lab et donc qui retourne
dans la stack Grafana. Donc on voit tout de suite l'aspect observabilité. Et tous les outils dont
on parle de Grafana, l'objectif unifié, unique, c'est tout simplement quand vous faites des
dashboards au niveau de Grafana, la possibilité au sein même d'un dashboard donné, par exemple sur
un applicatif donné, afficher les traces, afficher les logs et afficher les métriques. Et ça,
c'est quelque chose qui est important. Et Grafana va même plus loin que ça puisqu'ils sont des outils
type on call, donc pour également tracer des résolutions d'incidents, etc. Donc vraiment des
outils qui sont importants et qui rendent plus moderne la partie monitoring un petit peu historique
en reprenant l'ensemble de la stack. Alors tout ça, c'est bien et ça a fait émaner des sujets. Et
parmi les sujets qui ont émané, donc on va parler d'autres choses, on va parler d'open
telemétrie. Donc bien sûr, au fur et à mesure, on a vu qu'on a des stacks et surtout des acteurs
qui sont différents, qui particident de différentes manières. On a la CNCF qui pousse
différentes solutions, donc le Prometheus, Thanos, etc. Et puis on a des acteurs plutôt privés qui
eux, leur but bien sûr, c'est de faire de l'argent comme élastique, Grafana, etc. Et chacun est venu
avec sa solution et finalement, ce qui se passe, c'est que les acteurs ont besoin de migrer,
de passer d'une solution à une autre. Et ça, c'est quand même quelque chose qui n'a pas été
prévu bien sûr et qui est rendu du coup de fait difficile. Donc open telemétrie, on va dire,
repose un petit peu sur cette base-là avec l'idée de refondre l'ensemble et de permettre
l'interopérabilité entre les outils. Pour ça, sur un fondement de base, ça va être d'un côté
une partie collecte, de l'autre côté une partie stockage et faire en sorte qu'il y ait une brique
au milieu avec une forte standardisation qui permet de passer outre le fait qu'on est sur des
stacks différents tout simplement en matière de stockage et en matière de collecte par exemple.
Et faire en sorte qu'on puisse toujours finalement retrouver ces petits et pouvoir passer d'un outil
à un autre suivant le souhait grâce à ce principe de fonctionnement. Historiquement,
on parlait d'open tracing et open census qui sont maintenant devenus open telemétrie.
Open telemétrie, ça émerge depuis 2019 grâce à la CNCF et c'est vraiment un outil sur lequel
on va retrouver les grands noms de la stack d'observabilité d'un point de vue général,
de nos travail élastique, travail grafana mais aussi plein d'autres sociétés.
On parle également de protocoles. Donc le protocole, c'est OTLP, non pas OLTP mais OTLP pour
open telemétrie, line protocol. Voilà, donc ça va être tout pour aujourd'hui. On a brossé
brièvement la stack d'observabilité. Avec ça, vous en saurez certainement un petit peu plus. N'hésitez
pas à me faire des commentaires par ailleurs mais surtout à partager ce podcast, à vous abonner
si ce podcast vous a plu et moi je vous dis à très bientôt sur Xavki.