0

We have a 3rd party that we have integrations with and we adopted Open Telemetry but we have a problem building our trace tree. Below is the architecture involved:

enter image description here

Basically, an HTTP request will be initiated by Service A to the 3rd-party API, which will in turn call Service B and process the response before responding back to Service A. The problem with building the trace tree of these interactions is that:

  1. Both companies here use different storages for trace data
  2. The open telemetry protocol sends the trace id and parent span data and not the whole graph of spans

This means that when the 3rd-party service calls Service B, it will pass its last span id in the traceparent header, and since this span id is not in our storage, the collector will report an invalid parent id and hence we'll have two graphs in the same trace:

  1. All spans in Service A
  2. All spans in Service B and C

Ideally, the parent id of Service B should be the span id of the span in Service A that initiated the HTTP call to the 3rd-party service to keep all spans in one graph.

My question is - do we have a standard way, recommended by Open Telemetry, of solving this problem? Although I'm sure there could be clever ways to solve this issue by using baggage data, I would like to know if there's an industry-wide recommended approach.

Thanks!

Kimutai
  • 1,022
  • 11
  • 15

0 Answers0