Interviews d'experts - épisode #2 : Observabilité

“L’observabilité ne se limite pas à collecter des indicateurs techniques. Il s’agit aussi d’intégrer les besoins business, de relier les contraintes techniques aux objectifs de service et, finalement, d’améliorer l’expérience pour tous les utilisateurs.”

– Guillaume Estassy, expert observabilité

Lors cette série d’interviews, OCTO vous propose un aperçu des sujets à considérer dans votre trajectoire des mois à venir. Aujourd’hui, Guillaume Estassy, nous parle d’Observabilité.

En quoi l’observabilité est-elle différente du monitoring ?

Avant, les architectures étaient majoritairement monolithiques, avec des experts répartis par domaines techniques (ex: base de données, infrastructure, front ou autre). On pouvait surveiller facilement chaque composant puisqu’on savait exactement quoi surveiller.

Aujourd’hui, la donne a changé. Les systèmes se virtualisent, se conteneurisent et évoluent en microservices, ce qui complexifie l’environnement de façon exponentielle. Nous devons donc assurer performance et disponibilité sur une multitude de composants. C’est ce que résout l’observabilité en collectant le maximum d’informations sur les systèmes, et en se reposant sur des outils d’exploitation de ces données brutes pour pouvoir les interroger au besoin, même à propos de ce que nous n’avions pas anticipé.

Là où le monitoring va se concentrer sur de l’alerting souvent réactif, l’observabilité apporte ainsi des capacité de proactivité et d’investigation plus poussées

Par ailleurs, elle ne se limite pas à collecter des indicateurs techniques. Il s’agit aussi d’intégrer les besoins business, de relier les contraintes techniques aux objectifs de service et, au final, d’améliorer l’expérience pour tous les utilisateurs.

Comment l’écosystème a évolué pour faciliter l’observabilité aujourd’hui ?

Historiquement, on trouvait des plateformes spécialisées dans un domaine précis, des entrepôts de logs ou des outils d’APM. Aujourd’hui, de grandes plateformes d’observabilité unifiée ont émergé, regroupant log, métriques et traces. Pour rappel, les logs sont des événements remontés par les systèmes, sous format texte ou formatés (json, yaml …). Les métriques sont un outil plus statistique sur ces systèmes (exemple : temps moyen d’une requête au backend), leur format numérique permet un stockage et une interrogation des données très efficace même sur des volumes importants, grâce à des moteurs spécifiques (TSDB). Et les traces sont des regroupements d’évènements qui permettent de comprendre comment ceux-ci s’enchaînent et se hiérarchisent dans un même processus, au sein d’un même système comme entre plusieurs.

Des acteurs majeurs tels que Dynatrace, Datadog et New Relic (entre autres) proposent désormais une vision globale, grâce à des plateformes qui permettent de recouper de multiples types de données.

Parallèlement, l’adoption d’un protocole commun de télémétrie, OpenTelemetry, permet d’harmoniser la remontée des données, facilitant ainsi l’interopérabilité entre solutions fermées et projets open source.

Quels avantages y vois-tu ?

Ces évolutions apportent de réels avantages fonctionnels. L’intégration de fonctionnalités plus complexes – par exemple, autour de l’intelligence artificielle – nécessite une orchestration fine entre plusieurs composants. Les solutions en mode SaaS, grâce à leur interconnexion poussée, offrent des fonctionnalités avancées qu’il est difficile d’obtenir avec une installation auto-hébergée classique. Cela se traduit par une meilleure intégration et une expérience utilisateur améliorée, tout en facilitant la gestion de la volumétrie et la prévention des alertes parasites. Une autre facilité est leur mode d’installation au sein des systèmes, notamment avec des agents peu intrusifs reposant sur la technologie eBPF.

Un mot pour finir ?

Oui, j’aimerais partager deux concepts clés pour faciliter s’engager dans l’observabilité.

Le premier concept est shift left on observability. Il consiste à intégrer dès la conception de l’application les pratiques d’observabilité. En plaçant l’observabilité en amont, on s’assure que les indicateurs techniques se construisent en parallèle avec les exigences business. Cela favorise une adoption transversale des bonnes pratiques et aide les équipes à anticiper et résoudre les problèmes avant même qu’ils n’affectent la production.

Le second concept, c’est le golden path observability, qui vise à définir un chemin standardisé pour l’observabilité, notamment dans les grandes entreprises où les pratiques peuvent être hétérogènes. L’objectif est de proposer un ensemble de bonnes pratiques simples et efficaces, un golden path, qui facilite la mise en œuvre d’une surveillance homogène sur l’ensemble des entités. Ce dispositif est généralement mis en place par des équipes “plateformes” centralisées. Il laisse toutefois la place à des initiatives spécifiques, afin de répondre aux particularités de chaque contexte, sans imposer une contrainte rigide.

Pour ne pas rater les futures interviews, suivez notre blog et nos annonces sur LinkedIn.