Auto‑héberger l’observabilité pour les agents IA : un cadre de décision pour les CTO

Vos agents IA vous noient sous la télémétrie. Des flux de jetons de longue durée, des appels d’outils, des retries, des prompts, du streaming SSE — tout s’additionne. Si vous continuez à envoyer chaque span et ligne de log vers un APM SaaS, vous allez payer une fortune et faire fuiter des prompts que vous n’aviez jamais l’intention de stocker hors VPC. Cette semaine, Hacker News a mis en avant Traceway — une stack d’observabilité auto‑hébergée, sous licence MIT, déployable en minutes. Ce n’est pas une curiosité. C’est un signal. En 2026, les stacks riches en IA ont besoin d’une stratégie d’observabilité consciente des coûts, des données personnelles (PII) et portable.

Ce qui a changé : la télémétrie des agents IA n’est pas celle des microservices web

Les éditeurs d’observabilité ont optimisé pour les microservices : requêtes courtes, spans uniformes, logs à faible entropie. Les agents renversent ces hypothèses.

• Les sessions sont longues. Un utilisateur lance un workflow agentique qui stream 30–180 secondes de jetons, émet une douzaine d’appels d’outils et écrit en continu dans l’UI pendant toute la durée.
• Les charges utiles sont sensibles. Les prompts, pièces jointes et résultats d’outils véhiculent souvent des PII, de la PHI, du code ou des contrats. Si vous ne pouvez pas prouver où ces données résident, le juridique finira par vous prouver le contraire.
• Le signal est concentré en queue. Les pannes intéressantes sont rares : timeouts au 99,5e percentile, un appel d’outil mal spécifié sur cent. L’échantillonnage en tête jette ce dont vous avez besoin. Les décisions en queue comptent.
• Les clients deviennent des citoyens de première classe. Les apps mobiles et desktop exécutent désormais l’inférence et les outils localement ou sur le LAN. Vous avez besoin de traces de session multi‑appareils, pas seulement de spans serveur.

Dit crûment : l’observabilité des agents est plus proche de l’analytics et de l’eDiscovery que des logs serveur. Traitez‑la comme telle.

Le modèle de coûts que vous devriez réellement utiliser

Ignorez les prix catalogue des vendeurs ; ils changent chaque mois et sont volontairement opaques. Modélisez votre propre gravité des données. Voici une base défendable pour un produit enrichi par l’IA :

• Sessions d’agent quotidiennes : 250,000
• Par session : 10 spans d’appels d’outils (~1 KB de métadonnées chacun), 1 span de modèle longue durée avec prompt + réponse (~10–50 KB compressés), 200–500 événements jetons/télémétrie (~5–15 KB compressés au total), 5–10 entrées de log (~2–5 KB compressés)

Empreinte brute conservatrice par session : 30–70 KB. À 250k sessions, cela représente 7,5–17,5 GB/jour avant enrichissement. Avec des attributs additionnels, des en‑têtes HTTP et du baggage de contexte, un facteur 2× est courant. Disons 15–35 GB/jour de données d’observabilité.

Passons à l’argent :

• Compute de stockage chaud (ClickHouse ou Tempo/ClickHouse pour les traces ; Loki pour les logs ; VictoriaMetrics pour les métriques) sur des instances modestes peut compresser par 8–12× les charges de traces/logs. 20–35 GB/jour bruts aboutissent typiquement à 2–4 GB/jour sur disque pour les traces/logs et 0,5–1 GB/jour pour les métriques après agrégations.
• Stockage objet (S3/GCS) pour la rétention à froid coûte ~$0.021–0.026/GB‑mois en 2026. 1 TB de traces/logs mensuels à froid coûte <$30/mois, plus la récupération quand vous devez fouiller.
• Compute : un cluster ClickHouse à 3 nœuds sur des instances généralistes gère souvent 10–50k spans/s agrégés avec une latence de requête sous la seconde. Attendez‑vous à $600–$2,000/mois selon la région et la classe d’instance. Loki + VictoriaMetrics ajoutent des centaines, pas des milliers.

Comparez cela à l’envoi de 15–35 GB/jour vers un APM SaaS en gardant 7–14 jours en chaud. Les frais d’ingestion et de rétention grimpent couramment à des montants à cinq chiffres (bas) à ce volume, et vous conservez malgré tout des externalités de confidentialité. L’auto‑hébergement n’est pas « gratuit », mais le point de croisement est plus bas que ce que la plupart des équipes pensent.

Architecture : une stack qui ne vous compliquera pas la vie

Pas besoin d’un projet de labo. Il vous faut quatre composants qui tournent dans votre VPC et parlent OpenTelemetry de bout en bout.

1) Instrumentation et contrats de données

• Standardisez sur OpenTelemetry pour les traces, logs et métriques. Adoptez les conventions sémantiques OpenTelemetry émergentes pour les spans IA/LLM : nom du modèle, jetons in/out, appels d’outils, nombre de retries.
• Définissez un contrat de données pour les prompts et charges d’outils. Par défaut, stockez des hachages, pas du texte brut. Ne stockez les prompts/réponses complets que lorsqu’un indicateur « debug » par session est activé. Attachez un attribut pii=true quand un détecteur se déclenche.
• Instrumentez les applications clientes (Android, iOS, desktop) pour émettre spans et logs avec les mêmes IDs de trace et d’utilisateur/session. Pour Android, préférez OTLP à gRPC afin de réduire le head‑of‑line blocking sur des réseaux dégradés.

2) Ingestion et plan de contrôle

• OpenTelemetry Collector partout. Utilisez des processors pour la redaction d’attributs, l’échantillonnage en queue (tail‑based) et le routage. L’échantillonnage en queue est un prérequis pour les agents ; vous devez conserver les cas extrêmes même quand le QPS global est élevé.
• Budgets d’événements : appliquez un maximum de spans/logs par session au niveau du collector, avec plafonds stricts et métriques de contre‑pression (backpressure). Un agent défaillant ne doit pas faire un DDoS sur votre couche d’observabilité.
• Garde‑fous PII : utilisez des processors pour supprimer les attributs détectés et pour bifurquer des charges utiles non expurgées vers un bucket S3 scellé avec un TTL de 7 jours, sans accès UI, récupération via IAM uniquement pour les incidents.

3) Stockage et requêtage

• Traces : traçage adossé à ClickHouse (p. ex., via SigNoz, HyperDX, ou un routeur léger) ou Grafana Tempo associé à ClickHouse pour les index de recherche. ClickHouse vous offre du SQL sur les spans et peut aussi servir d’entrepôt d’analytics de prompts.
• Logs : Loki pour des logs économiques et peu indexés ; des chunks adossés à du stockage objet simplifient l’infra. Si vous devez requêter des logs structurés à grande échelle, streamez vers des tables ClickHouse avec partitionnement par jour et par service.
• Métriques : VictoriaMetrics pour un time series store monobinaire, adapté à la forte cardinalité. Il compresse agressivement les séries numériques ; attendez‑vous à 2–5× de mieux que le TSDB Prometheus brut. Si vous émettez des flux en virgule flottante à haute résolution, envisagez un compresseur sans perte conçu pour la télémétrie flottante ; des travaux comme “fc, a lossless compressor for floating-point streams” montrent des gains supplémentaires de 2–4× sur certains signaux.

4) UI et workflows

• Tableaux de bord Grafana sur métriques et logs, explorateur de traces au‑dessus de ClickHouse/Tempo. Gardez les interfaces simples et centrées sur vos SLOs, pas sur un catalogue de 200 widgets.
• Relecture de session si nécessaire : auto‑hébergez rrweb, liez les relectures aux IDs de trace. Conservez les relectures avec un TTL court et ne stockez jamais de PII dans le DOM sans masquage.

Confidentialité et conformité : arrêtez de faire comme si les prompts étaient « juste des logs »

Si vos agents manipulent des PII, de la PHI ou du code source, votre couche d’observabilité est un magasin de données réglementé. Agissez en conséquence.

• Masquez par défaut. Hachez prompts et réponses. Ne conservez que les comptes de jetons, les durées et les métadonnées de modèle sauf si un indicateur debug est présent. Pour les sessions marquées, dupliquez les charges complètes dans un bucket scellé avec un TTL de 7 jours.
• Résidence régionale. Gardez les données en région. Si vous opérez au Brésil et aux US, respectez la LGPD et les lois locales sur la vie privée en fixant les tiers chaud et froid aux régions et comptes appropriés.
• Contrôle d’accès. Aucun compte partagé. Utilisez SSO + SCIM + RBAC par projet. Masquez les attributs dans l’UI. Chaque accès à des données non expurgées doit laisser son propre span d’audit.
• Rétention des données. 7 jours en chaud pour traces/logs, 30–90 jours en froid sur stockage objet, 15 mois pour les métriques agrégées. Vous pourrez le justifier au juridique tout en gérant efficacement les incidents.

Performance : budgets de latence pour l’observabilité elle‑même

Collectors et exporters tournent in‑process ou en sidecar ; ils ne doivent pas mettre en péril vos p99.

• Exporters OTLP non bloquants avec contre‑pression et files bornées. Jetez au‑delà des budgets d’événements ; ne laissez jamais des blocages d’observabilité impacter les requêtes utilisateur.
• Fenêtres d’échantillonnage en queue de 1–3 secondes qui capturent les traces lentes de façon déterministe sans ajouter de latence côté utilisateur. Crucial pour les flux QUIC/WebRTC et SSE ; une optimisation réseau Linux récente a provoqué un bug QUIC qui serait resté invisible avec un échantillonnage en tête.
• Partitionnez par identifiant de session dans votre store de traces pour améliorer la localité de cache et garder des requêtes réactives en debug live.

Cadre de décision : quand auto‑héberger vs. acheter

Utilisez des déclencheurs, pas de l’intuition.

Auto‑hébergez si l’un de ces points est vrai :

• Le volume de télémétrie dépasse ~15 GB/jour (traces/logs/métriques), ou vous prévoyez de doubler d’ici deux trimestres.
• Les prompts sensibles/PII ne peuvent pas sortir de votre VPC ou de votre région, ou le juridique exige des traces d’audit sur qui a vu les prompts bruts.
• Le debug des agents nécessite une corrélation au niveau session entre mobile/desktop + backend + outils, et vous ne pouvez pas l’exprimer facilement chez votre fournisseur SaaS.
• La volatilité des coûts du SaaS vous a déjà forcés à réduire la rétention ou l’échantillonnage au point que les ingénieurs évitent l’outil.

Restez sur du SaaS (pour l’instant) si tous ces points sont vrais :

• Moins de 5 GB/jour de télémétrie sans charges sensibles, et
• Faible cardinalité des métriques/logs, et
• Pas de capacité SRE/DevEx dédiée pour les deux prochains trimestres.

Il existe une voie médiane : écrivez en double vers le SaaS et l’auto‑hébergé pendant que vous mûrissez vos pipelines, puis basculez la route par défaut.

Mise en œuvre : un plan d’exécution 0–90 jours

Jours 0–30 : Baseline et double écriture

• Adoptez les SDK OpenTelemetry dans votre API gateway, orchestrateur d’agents et vos deux principaux outils. Émettez des spans de modèle avec des attributs standardisés.
• Déployez une stack de référence dans votre VPC de staging : OpenTelemetry Collector → Loki + VictoriaMetrics + ClickHouse. Des outils comme Traceway montrent que l’on peut monter cela en minutes ; la mise en production prend plus, mais les bases sont rapides.
• Double export vers votre SaaS actuel et vers votre stack auto‑hébergée. Validez la parité sur trois golden signals et un incident connu.
• Rédigez le contrat de données pour la redaction et les forks de debug. Transformez‑le en vérification CI : les nouveaux spans sans attribut de classification font échouer les builds.

Jours 31–60 : Bascule en production pour les chemins critiques

• Activez l’échantillonnage en queue par service et taux d’erreur. Conservez 100 % des traces pour les sessions en erreur ou p99 > SLO, échantillonnez 1–5 % sinon.
• Faites respecter les budgets d’événements par session dans le collector. Des alertes se déclenchent quand les drops dépassent les seuils.
• Garde‑fous PII en production : masquage dans les SDKs, redaction dans les collectors, fork vers bucket scellé avec TTL 7 jours. Spans d’audit sur chaque accès aux données brutes.
• Tableaux de bord et runbooks pour vos 3 principaux SLOs : latence de prompt, succès des appels d’outils, durée de session de bout en bout. Entraînez‑vous sur deux incidents simulés et un game day réel.

Jours 61–90 : Optimiser et réduire les risques

• Ajustez partitions de stockage et niveaux de rétention. Basculez tout ce qui a plus de 7 jours vers le stockage objet. Agrégez les métriques à une résolution de 1–5 minutes au‑delà de 7 jours.
• Garde‑fous de coûts : alertes mensuelles sur la croissance du stockage objet et le CPU ClickHouse. Empêchez merges et compactions d’affamer les requêtes.
• Reprise après sinistre : snapshot des catalogues quotidien, test de restauration dans un VPC bac à sable. Documentez votre RTO/RPO et prouvez‑le.
• Réduisez l’ingestion SaaS pour logs/traces dans une fenêtre contrôlée. Gardez les métriques en miroir un sprint de plus avant la coupure finale.

Tactiques qui s’amortissent très vite

• Masquez à la source : ne comptez pas sur des processors en aval pour nettoyer les secrets dans les prompts. Hachage + comptes de jetons répondent à 90 % des besoins de debug.
• Échantillonnage au niveau session : conservez des sessions défaillantes entières ; des traces partielles gaspillent du disque.
• Logs structurés uniquement : JSON avec un trace_id et session_id. Les logs non structurés sont supprimés à 90 jours ; les logs structurés alimentent l’analytics dans ClickHouse.
• Compressez les bonnes choses : stockage objet avec zstd ou parquet ; métriques avec delta‑of‑delta ; les flux riches en flottants profitent de compresseurs spécialisés, sans perte, issus de la recherche scientifique.
• Ergonomie d’astreinte : une vue session unique qui relie prompts → appels d’outils → événements UI résout les incidents plus vite que trois onglets chez des fournisseurs.

Arbitrages et risques bien réels

• Vous êtes responsable du SRE. Quelqu’un doit assurer patching, scalabilité et sauvegardes. Les CVE kernel et dnsmasq continuent de tomber ; intégrez vos collectors et stores dans des images standard avec mises à jour automatiques pendant les fenêtres de maintenance.
• Sans budgets impitoyables, vous sur‑collecterez. Les équipes IA aiment la visibilité. Donnez‑leur des curseurs d’échantillonnage et des coûts clairs ; sinon, votre stack « bon marché » va coûter cher.
• ClickHouse est puissant et tranchant. Un mauvais schéma et des merges dévoreront du CPU. Démarrez avec des schémas éprouvés pour spans et logs ; n’improvisez pas en prod.

Exécution nearshore : comment les équipes y parviennent

Le plus gros du travail n’est pas logiciel ; ce sont la politique et la plomberie. Les équipes qui réussissent associent généralement un petit noyau plateforme à de la puissance nearshore. En pratique, une équipe plateforme de deux personnes aux US plus un pod nearshore (Brazil est fort ici) peuvent mettre en place la stack, l’IaC et les contrats de données en deux sprints avec 6–8 heures de chevauchement. Ensuite, c’est de l’optimisation incrémentale et une revue trimestrielle coûts/rétention.

À quoi ressemble « excellent » d’ici la fin du T1

• Coûts : Tier chaud à $1–2k/mois, tier froid sous $100/mois par TB. Pas de factures SaaS surprises liées aux pics de trafic.
• Confidentialité : prompts hachés par défaut, accès au bucket scellé audité, résidence régionale imposée par politique.
• Fiabilité : requêtes de traces en moins d’une seconde sur les dernières 24 heures. L’échantillonnage en queue conserve toutes les sessions lentes/en erreur. Les game days prouvent RTO < 2 heures, RPO < 24 heures.
• Vitesse de dev : les ingénieurs utilisent une vue session unique pour résoudre les incidents. Les équipes Produit et Data interrogent ClickHouse sur la performance des modèles sans demander des CSV aux SREs.

Conclusion

Les agents IA rendent l’observabilité à la fois plus précieuse et plus risquée. Si vous poussez des dizaines de gigaoctets par jour et que quoi que ce soit est sensible, le réflexe « on envoie chez un fournisseur et on espère » ne tient plus. S’auto‑héberger avec OpenTelemetry, ClickHouse/Loki/Tempo et des contrats de données stricts n’est pas contrarien — c’est de l’ingénierie responsable. Commencez la double écriture ce mois‑ci. Vous dormirez mieux le trimestre prochain — et votre service juridique aussi.

Points clés

• La télémétrie des agents est à sessions longues, dominée par la queue et contient souvent des PII ; traitez‑la comme de l’analytics, pas « juste des logs ».
• Le point de bascule économique pour l’auto‑hébergement arrive autour de 15+ GB/jour de traces/logs/métriques ou de toute contrainte PII.
• Adoptez OpenTelemetry avec échantillonnage en queue, budgets d’événements et contrats de données « redaction‑by‑default ».
• Utilisez ClickHouse/Tempo pour les traces, Loki pour les logs et VictoriaMetrics pour les métriques ; mettez tout le reste en froid sur du stockage objet.
• Exécutez un plan 0–90 jours : double écriture, bascule des chemins critiques, garde‑fous, tests de DR, puis réduction du SaaS.
• Attendez‑vous à des arbitrages : vous possédez le SRE et la discipline de coûts ; à la clé, moins de dépenses, moins de risques et une meilleure réponse aux incidents.