Draft - Standard Traces Query API

[itaykat]

[Draft - Work in progress] Standard Trace Query API

This change suggest a standard API definition to query traces stored in any tracing backend platform (generally speaking, observability backends), both open source (Jaeger, Tempo, Zipkin) and proprietary (Datadog, appdynamics, etc.)

Motivation

• The Observability space is getting mature, more and more telemetry producers try to align with the OpenTelemetry standards to produce telemetry signals.

  On the other side, telemetry consumers platforms (platforms that uses traces to enrich and correlate existing events. Kiali [1]), need to implement N backend (each for each observability backend integrated to their platform) APIs to consume and process those telemetry signals.

• Sooner than later, at the same rhythm that the OpenTelemetry client side pipeline (instrument, collect, export) adoption grows, the need for a standard backend to consume these telemetry signals will grow as well.

• OTel collector natively supports exporting telemetry signals to multiple exporters simultaneously hence to multiple observability backends.

This idea of "having a standard for trace query API " has also been discussed by @lucasponce and others at length in #193.

Comments, ideas, feedback, etc. are all very welcome and highly appreciated!

[linux-foundation-easycla]

• ❌ The commit (7898bbb, 083bfd7, 2d27153, 6cc7b6b, 3d05741). This user is missing the User's ID, preventing the EasyCLA check. Consult GitHub Help to resolve.For further assistance with EasyCLA, please submit a support request ticket.