After talking to cvogel1, I see that we can start working towards defining a Query API that would be used by whatever UI ends up being used/built as part of the Observability solution, as well as other UIs, such as OpenShift console and Kiali.

As we don't know the complete use cases yet, we should start with small steps covering the most basic queries, like:

• trace by ID (possibly requiring a time window, as this is required by some underlying storages)
• traces by service, also requiring a time window
• services (time window?)
• operations (time window?)
• traces by services, time window, and tags
• traces by services, time window, and duration

The Jaeger Query proto definition can be used either as a base or as inspiration:

https://github.com/jaegertracing/jaeger-idl/blob/master/proto/api_v2/query.proto

Once the API is defined with basic cases, we can determine whether:

• Jaeger can be used directly
• Jaeger can be changed to implement the API (propose changes to upstream)
• In case none of the above are possible, build our own query component

This might end up being the same as TRACING-1926, but not necessarily.