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

Série OpenTelemetry en production, 4/4. Le précédent : 400 000 bases, cardinalité et autres pièges.

Une fois OpenTelemetry, Alloy, VictoriaMetrics, Tempo, Loki et Grafana installés, il reste à faire tourner tout ça correctement.

C’est la partie moins visible du projet.

La stack est open source. Les disques, le compute, les sauvegardes, les montées de version, les requêtes trop lourdes et les incidents ne le sont pas.

Dans le contexte que j’accompagne, ce compromis vaut le coup. Mais je ne présenterais jamais cette architecture comme une manière d’obtenir “Dynatrace gratuitement”.

L’observabilité peut casser quelque chose

On l’a vu assez tôt avec l’auto-instrumentation Kubernetes.

L’injection via l’OpenTelemetry Operator nous faisait utiliser des emptyDir sur certains jobs éphémères. Sur les environnements moins chargés, rien de particulier. En production, avec le vrai trafic, les I/O disque ont fini par saturer.

À partir de là, le problème n’était plus très théorique : des pods restaient en attente et la plateforme commençait à souffrir.

On a désactivé la partie concernée pour rétablir la production, puis repris le sujet ensuite.

Je ne mets pas ça sur le dos de l’Operator. Le mécanisme fonctionnait ailleurs. Ce cas rappelle surtout qu’une couche d’observabilité consomme elle aussi du CPU, de la RAM, du réseau et du disque.

Il faut la charger, la limiter et la tester comme n’importe quel autre composant de plateforme.

Le dev ne raconte pas les volumes de prod

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

Une requête qui répond instantanément avec quelques jours de données de dev 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.

L’idée est assez basique : 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 JSON Grafana peut mettre une stack d’observabilité à genoux aussi sûrement qu’un mauvais cron.

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, n’est pas notre cible historique. Il reste temporairement parce que certains dashboards n’ont pas encore été migrés. Quand ces usages auront disparu, la dépendance pourra partir avec eux.

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

Ici, l’architecture permet au client d’avancer vers Dynatrace sans perdre les usages Grafana qui restent utiles.

La collecte est plus homogène. Splunk peut sortir progressivement au lieu de disparaître au milieu d’une migration. Les équipes disposent de traces plus riches pour diagnostiquer le code et l’architecture. Et un changement de backend ne demande plus forcément de repartir dans 200 services.

En face, il faut maintenir la stack. C’est le prix.

Je trouve l’échange intéressant parce qu’on achète de la réversibilité et de la maîtrise, pas juste des licences en moins.

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

OpenTelemetry n’enlève pas la complexité de l’observabilité.

Il évite surtout de mettre toute cette complexité dans le code applicatif.

Le service produit des signaux. La plateforme décide comment les collecter, les filtrer et les router. Le client garde le choix de ses backends.

Ensuite, il faut toujours faire le boulot : cardinalité, PII, sampling, capacity planning, stockage, règles, dashboards et incidents.

Ça me va beaucoup mieux comme ça. La complexité existe de toute façon. Autant la mettre dans une couche qu’on peut piloter.

Série complète