Tracer l'invisible : OpenTelemetry et Solace au cœur de l'observabilité des intégrations

Chaque jour, des milliers d’événements transitent entre vos flux d’intégration, orchestrés par votre broker Solace. Un flux publie un événement, un autre le consomme : sur le papier, tout fonctionne. Mais savez-vous réellement qui produit quoi, qui consomme quoi, et surtout quand ? Que se passe-t-il entre l’instant où le message quitte l’émetteur et celui où il atteint son destinataire ?

Dans la majorité des architectures événementielles actuelles, cette portion du trajet reste une zone d’ombre totale. Et c’est précisément là, à l’intérieur du broker, que se prépare la prochaine panne difficile à diagnostiquer.

Des flux d’intégration pilotés à l’aveugle

Les architectures d’intégration modernes s’appuient de plus en plus sur l’Event-Driven Architecture (EDA). Un flux d’intégration publie un événement vers un broker ; un autre flux, ailleurs dans l’organisation (parfois dans une autre zone géographique, une autre région ou un autre domaine métier), s’y abonne pour le consommer. Multiplié à l’échelle d’une entreprise, ce modèle donne naissance à un véritable Event Mesh : un réseau de brokers interconnectés, traversé en permanence par des flux d’intégration qui produisent et consomment des événements.

Le Distributed Tracing a justement été conçu pour répondre à ce besoin de visibilité de bout en bout : il permet de suivre un événement à travers les différents sauts d’un système distribué, flux par flux, API par API. Mais dès que cet événement traverse un broker, la trace s’interrompt. Le broker devient une black box.

Le broker a-t-il bien reçu le message ? La queue l’a-t-elle stocké ? Le flux consommateur a-t-il correctement traité l’événement et envoyé son accusé de réception ? Où se situe le goulot d’étranglement qui ralentit l’ensemble de l’Event Mesh ? Sans réponse à ces questions, chaque incident sur un flux d’intégration basé sur l’EDA se transforme en enquête longue et incertaine, d’autant plus complexe que les flux d’intégration impliqués sont eux-mêmes distribués.

Le prix de l’angle mort

70 % des organisations ayant réussi à appliquer l’observabilité bénéficieront d’une latence de décision plus courte d’ici 2026 (Gartner, Top Strategic Technology Trends).

Concrètement, cela se traduit par un débogage plus rapide : moins de temps passé à détecter et comprendre un incident, plus de temps pour le résoudre. Tant que le broker reste une boîte noire au sein de l’Event Mesh, cette accélération s’arrête à sa porte : le diagnostic doit repartir de zéro pour comprendre ce qui s’y est passé.

Plus le temps de détection et de diagnostic (MTTD/MTTR) est long, plus l’incident coûte cher à l’activité. Dans une architecture événementielle où le broker reste une boîte noire, ce temps de diagnostic reste structurellement plus long que partout ailleurs dans le système d’intégration. C’est précisément cet angle mort que l’association d’OpenTelemetry et de Solace PubSub+ vient combler.

OpenTelemetry, en bref

OpenTelemetry (ou OTel) est un framework d’observabilité open source, standard de l’industrie et vendor-agnostic (c’est-à-dire indépendant du fournisseur de la solution d’observabilité), conçu pour collecter et exporter des données de télémétrie. Il repose sur trois piliers :

• Metrics : mesures numériques agrégées dans le temps (utilisation CPU, nombre d’événements, etc.).
• Logs : enregistrements horodatés, structurés ou non, de ce qui s’est produit.
• Traces : la vision bout en bout du parcours d’un événement à travers un système distribué.

Concrètement, un flux d’intégration génère des messages de trace au niveau applicatif ou API ; ceux-ci sont envoyés au collecteur OpenTelemetry, plus précisément à son récepteur. Le Processor traite ensuite ces traces avant de les transmettre à un Exporter, propre à chaque backend d’observabilité (Datadog, Dynatrace, Jaeger, Splunk…), qui les publie dans l’outil choisi.

Dans un système distribué, chaque interaction constitue un événement transactionnel : à chaque saut, un Span est généré, et tous les Spans d’un même événement transactionnel partagent un Trace ID commun (c’est ce qui permet au backend de reconstituer la trace complète).

Comprendre le flux des événements dans une EDA suppose de croiser deux perspectives complémentaires. Au design time, des outils comme un Event Portal permettent de cartographier les relations entre les flux d’intégration et la circulation des événements. Au runtime, c’est le Distributed Tracing qui prend le relais (à condition de pouvoir collecter des traces non seulement au niveau applicatif et API, mais aussi au niveau du broker).

Or, il existe encore aujourd’hui peu d’outils dans l’industrie capables de tracer un événement à l’intérieur même du broker, et d’en extraire des informations sur les queues, les accusés de réception, l’envoi et la réception des messages. C’est précisément ce que permet l’association d’OpenTelemetry et de Solace PubSub+.

La solution : OpenTelemetry x Solace PubSub+

Voici comment cette approche comble l’angle mort du broker.

Un flux d’intégration publie un message garanti vers un broker Solace activé pour le Distributed Tracing, avec une queue prête à le recevoir. Dès que le message arrive, un Span contenant un Trace ID est généré et envoyé vers une queue dédiée au Distributed Tracing, directement sur le broker. Le plugin récepteur Solace du collecteur OpenTelemetry se lie à cette queue et consomme ce Span.

Lorsqu’un autre flux d’intégration consomme le message d’origine et envoie son accusé de réception, un nouveau Span est généré, avec le même Trace ID. Cette continuité est l’élément clé de la context propagation : c’est elle qui relie ce qui se passe à l’intérieur du broker à ce qui se passe dans les flux d’intégration, en amont comme en aval.

Le récepteur Solace transmet ensuite ces traces au Processor du collecteur, qui les envoie à l’Exporter configuré. Les flux d’intégration eux-mêmes génèrent en parallèle leurs propres traces OpenTelemetry, avec ce même Trace ID. L’Exporter regroupe l’ensemble de ces Spans (ceux du broker et ceux des flux) et les publie vers l’outil d’observabilité choisi, par exemple Jaeger, comme l’illustre le schéma ci-dessous, qui les assemble pour reconstituer une vision complète du parcours de l’événement, de bout en bout.

Figure 1 : architecture du Distributed Tracing avec OpenTelemetry et Solace PubSub+, de la publication à la visualisation des traces.

Pour la première fois, le broker cesse d’être une boîte noire : il devient un maillon tracé, au même titre que n’importe quel flux d’intégration.

Illustration concrète : un flux d’intégration publie une commande client vers une queue garantie sur Solace ; un second flux d’intégration, situé dans une autre région, la consomme quelques secondes plus tard pour déclencher la facturation. Sans Distributed Tracing sur le broker, la publication et la consommation restent deux événements isolés, sans lien visible entre eux. Avec un Span et un Trace ID partagés, l’équipe d’intégration suit désormais cette même commande de bout en bout, dans un seul outil d’observabilité, et identifie en quelques secondes si un retard provient du broker ou du second flux.

Par où commencer

Activer le Distributed Tracing sur Solace PubSub+ ne nécessite pas de refondre l’existant. Il suffit d’activer la fonctionnalité sur les queues concernées et de déployer le plugin récepteur Solace au sein du collecteur OpenTelemetry déjà en place. Les flux d’intégration continuent de générer leurs traces comme aujourd’hui ; seul le broker rejoint, à son tour, le périmètre observé (sans rupture pour les équipes d’intégration ni pour l’outil d’observabilité déjà en place).

Les bénéfices concrets

• Visibilité de bout en bout : chaque événement est suivi depuis sa publication par un flux d’intégration jusqu’à sa consommation, en passant par le broker Solace (qui produit quoi, qui consomme quoi, quand).
• Diagnostic accéléré : en cas d’incident, les équipes identifient immédiatement si le problème vient du broker (message non délivré, queue saturée, accusé de réception manquant) ou d’un flux d’intégration, sans enquête manuelle fastidieuse.
• Identification des goulots d’étranglement : les performances de l’ensemble de l’Event Mesh deviennent mesurables, ce qui permet de cibler précisément les optimisations.
• Indépendance vis-à-vis de l’outil d’observabilité : OpenTelemetry étant vendor-agnostic, les traces générées peuvent être exportées vers Datadog, Dynatrace, Jaeger ou Splunk, selon les standards déjà en place.
• Une vision complète, à deux niveaux : le design time (cartographie des flux via un Event Portal) et le runtime (Distributed Tracing) se complètent pour donner une compréhension exhaustive du flux des événements.

Conclusion

Le broker a longtemps été le seul maillon de l’Event Mesh à rester invisible : un passage obligé pour tous les flux d’intégration, mais sans aucune trace de ce qui s’y passe réellement. Avec l’intégration d’OpenTelemetry et de Solace PubSub+, cette zone d’ombre disparaît. Les équipes en charge des flux d’intégration disposent enfin d’une observabilité complète, cohérente et standardisée, du premier producteur au dernier consommateur.

Tracer l’invisible, ce n’est plus une ambition : c’est désormais une capacité concrète, à la portée de toute architecture événementielle qui prend au sérieux la fiabilité de ses intégrations.