OpenTelemetry en production : la stack open source qu’il faut quand même opérer#

Dans un grand groupe, les outils d’observabilité changent. C’est normal : les besoins évoluent, les contrats aussi, et les équipes n’utilisent pas toutes les mêmes outils.

Ce qui me gêne, c’est quand chaque changement de destination oblige à retourner modifier des dizaines ou des centaines d’applications. On recommence le même chantier, avec les mêmes risques. Autant éviter de se fabriquer un cycle sans fin.

C’est pour ça que j’ai proposé OpenTelemetry dans cette migration. Pas pour remplacer Dynatrace, virer Splunk ou imposer une stack Grafana. Dynatrace reste une destination attendue ; les usages Grafana et Splunk existants ne disparaissent pas parce qu’on a choisi un standard.

L’application produit ses signaux avec un contrat commun. La plateforme les collecte, les transforme et les route vers les outils nécessaires. Si une destination évolue, je préfère faire porter ce changement par la plateforme plutôt que réinstrumenter les services un par un.

Évidemment, changer de backend ne migre pas magiquement les dashboards, les alertes ou les fonctions propriétaires. Mais au moins, on évite de recoller chaque application à un outil.

Et il y a une contrepartie : cette couche OpenTelemetry, Alloy, VictoriaMetrics, Tempo, Loki et Grafana, il faut l’exploiter. Les disques, les requêtes, les sauvegardes, la capacité et les incidents ne disparaissent pas avec une architecture plus réversible. Ce n’est pas une façon d’obtenir « Dynatrace gratuitement ». Le REX de ce dernier volet porte justement sur le coût réel de cette liberté.

Hors prod, tout fonctionnait. En prod, on avait oublié le volume#

On l’a découvert avec l’auto-instrumentation OpenTelemetry sur Kubernetes.

L’Operator injecte notamment un initContainer et un volume emptyDir partagé pour mettre les bibliothèques d’instrumentation à disposition du conteneur applicatif. Ce emptyDir ne venait pas de nos jobs : il était ajouté avec l’instrumentation.

Hors prod, les traces remontaient et les pods démarraient normalement. Rien à signaler.

En production, on n’avait pas du tout le même rythme : beaucoup de jobs, des pods éphémères qui se succèdent et, pour ceux instrumentés, autant de phases d’initialisation supplémentaires. Le coût d’I/O se répétait avec chaque nouveau pod.

À cette échelle, les I/O disque ont fini par saturer et certains pods restaient en attente. On a désactivé l’injection concernée pour revenir à la normale, puis repris le sujet.

Le problème n’était pas un emptyDir isolé, ni un bug mystérieux de l’Operator. C’était l’effet cumulé d’un mécanisme tout à fait normal sur une population de workloads qui démarre et disparaît très souvent.

J’avais validé que l’instrumentation fonctionnait. Pas assez ce qu’elle coûtait avec les volumes réels. Oups.

L’observabilité consomme elle aussi des ressources, y compris avant même que l’application démarre. Il faut donc la tester à la bonne échelle.

Hors prod ne raconte pas les volumes de prod#

Le même écart se retrouve côté backends.

Une requête qui répond instantanément hors prod avec un petit jeu de données peut devenir très chère avec plusieurs semaines de production. Un buffer qui paraît anodin change complètement de comportement quand le débit augmente.

On a eu des dashboards Grafana très lents, et parfois des requêtes qui mettaient VictoriaMetrics, Loki ou Tempo sous pression.

Ce n’était pas “Grafana qui rame”. Les questions posées aux backends coûtaient trop cher.

Les plages 1d, 7d ou 30d sont un bon exemple. Si le dashboard recalcule les mêmes agrégations lourdes à chaque ouverture, le coût revient à chaque utilisateur et à chaque refresh.

Les recording rules ont fait une vraie différence#

Pour les métriques, on a déplacé une partie de ces calculs dans des recording rules évaluées par vmalert.

Le mécanisme est simple : calculer périodiquement une expression coûteuse, écrire le résultat comme une série, puis faire lire cette série au dashboard.

On évite de reconstruire la même réponse en permanence.

Ça ne dispense pas de réfléchir à la requête. Une recording rule mal conçue peut aussi créer trop de séries. Mais sur les agrégations répétées et les vues longues, le gain est net.

C’est aussi pour ça que je considère les dashboards comme du code de plateforme. Un dashboard mal conçu peut imposer une charge très réelle aux backends, même sans changer une ligne de code applicatif.

Observer l’observabilité#

VictoriaMetrics, Tempo, Loki et Alloy ont donc leurs propres SLO de fait, même si on ne les appelle pas toujours comme ça.

Je surveille au minimum :

• CPU et mémoire ;
• saturation disque ;
• débit d’ingestion ;
• erreurs d’export ;
• files et buffers ;
• latence des requêtes ;
• séries actives ;
• volumes stockés ;
• état des règles.

Sinon, on découvre le problème au moment où les dashboards ne répondent plus. Et diagnostiquer une plateforme avec une plateforme d’observabilité en panne est rarement le meilleur moment de la journée.

La rétention doit suivre l’usage#

Autre point facile à sous-estimer : tout ne mérite pas la même rétention.

Une trace détaillée est très utile pendant un incident récent. Sa valeur diminue souvent assez vite. Une métrique agrégée peut rester pertinente beaucoup plus longtemps pour suivre une tendance ou préparer du capacity planning.

Les logs ont encore un autre cycle de vie.

Je préfère donc raisonner signal par signal plutôt que copier un “90 jours partout”.

C’est aussi l’intérêt du routage multi-backend : chaque destination reçoit ce qui sert à son usage, avec la rétention adaptée.

Splunk, par exemple, continue de servir certains dashboards qui n’ont pas encore été migrés. Je ne cherche pas à l’éteindre pour le principe. Tant qu’il est utile, la plateforme lui envoie ce dont il a besoin. Si ces usages migrent, on pourra retirer progressivement cette destination sans demander aux applications de changer leur instrumentation.

Open source ne veut pas dire gratuit#

Une stack opérée en interne a un coût très réel :

• stockage et compute ;
• réseau ;
• sauvegardes ;
• mises à jour ;
• capacité ;
• incidents ;
• règles et dashboards ;
• sécurité ;
• temps humain.

Une petite équipe peut l’opérer, mais il faut avoir envie de posséder ce sujet.

À l’inverse, un SaaS ou une offre managée achète beaucoup d’exploitation en moins. Ce service a évidemment un prix, avec souvent de l’ingestion, de la rétention et des fonctions supplémentaires à prendre en compte.

La comparaison utile n’est donc pas “open source gratuit contre SaaS payant”.

Je compare plutôt les coûts complets :

• combien coûte la plateforme à exploiter soi-même ;
• combien coûte le service managé avec les volumes réels ;
• quelles compétences faut-il garder en interne ;
• quelle dépendance contractuelle on accepte ;
• combien coûtera une migration future.

Selon la taille de l’équipe, le trafic et les contraintes, la réponse peut être très différente.

Dans ce cas précis, le compromis reste bon#

Le client avance dans sa migration vers Dynatrace, sans demander aux équipes d’abandonner d’un coup leurs usages Grafana ou Splunk.

Côté plateforme, on garde une responsabilité claire : faire évoluer la collecte, les transformations et les destinations. Les applications ne devraient pas avoir à connaître la prochaine décision d’outillage du groupe.

Cette séparation ne rend pas les backends interchangeables. Il faudra toujours reprendre les requêtes, dashboards et alertes propres à chaque outil. Mais on ne doit pas pour autant remettre les mains dans l’instrumentation de 200 services à chaque évolution.

En face, il faut maintenir cette couche commune. C’est le compromis que j’assume : moins de dépendances applicatives aux fournisseurs, davantage de responsabilité d’exploitation côté plateforme.

Et si c’était à refaire ?#

Je garderais le choix d’OpenTelemetry et la séparation entre instrumentation et destinations. J’écrirais simplement ce contrat et ses limites plus tôt : ce que la plateforme peut faire évoluer, ce qui reste spécifique aux backends, et qui est responsable de chaque adaptation.

Je commencerais par distinguer les services qui tournent longtemps des jobs et CronJobs très éphémères. Même instrumentation, mais pas du tout le même coût quand les pods sont recréés en permanence.

Sur les workloads éphémères, je regarderais la cadence réelle de création des pods, la durée des initContainers, le stockage éphémère consommé et les I/O disque par nœud. Puis je comparerais avec et sans injection, à charge comparable. Pas besoin d’inventer un benchmark : il faut mesurer le vrai profil du cluster.

J’activerais ensuite l’instrumentation par lots, avec des exclusions explicites pour les jobs où elle n’apporte pas assez, et un moyen simple de revenir en arrière. Je suivrais les temps de démarrage et les pods en attente pendant chaque étape.

Côté Grafana, je testerais aussi plus tôt les dashboards sur les volumes et rétentions réels, avec des recording rules pour les agrégations répétées, plutôt que de découvrir leur coût après coup.

Je ne bannirais ni les initContainers ni les emptyDir. Je vérifierais juste plus tôt ce que leur multiplication coûte dans notre contexte.

Ce que je ferais différemment en greenfield#

Sur une plateforme neuve, je partirais plus strict :

• attributs limités par défaut ;
• aucune dimension dynamique sans raison ;
• politique PII avant l’ouverture des flux ;
• sampling défini dès le départ ;
• budgets de cardinalité et de stockage ;
• recording rules prévues pour les vues importantes ;
• destination justifiée pour chaque signal.

En brownfield, on a dû faire presque l’inverse : conserver d’abord, comprendre les usages, migrer, puis fermer progressivement.

Les deux chemins peuvent arriver au même endroit. Ils n’ont juste pas le même risque.

Ce que je garde de cette expérience#

Au départ, je ne cherchais pas à changer les outils de tout le monde. Je voulais surtout éviter que chaque changement d’outil décidé à l’échelle d’un grand groupe déclenche une nouvelle campagne de modifications dans les applications.

OpenTelemetry aide à sortir de cette boucle : les services décrivent ce qu’ils font, et la plateforme prend en charge la collecte, le filtrage et le routage. C’est une séparation des responsabilités, pas une promesse de migration sans effort.

Le revers, on l’a vu sur le terrain : les initContainers et les emptyDir ajoutés par l’auto-instrumentation ont un coût quand les pods éphémères se multiplient. Même chose pour les labels trop dynamiques, les dashboards coûteux, la rétention et les volumes.

Je referais ce choix. Mais je testerais plus tôt les volumes réels, et j’assumerais dès le début que cette couche doit être exploitée comme le reste de la plateforme.

Sources officielles#

• OpenTelemetry Operator : auto-instrumentation

• Kubernetes : volumes éphémères

• Grafana Alloy : fonctionnement

• VictoriaMetrics : vmalert

• Grafana Tempo : architecture

• Grafana Loki : architecture

• OpenTelemetry : architecture du Collector