Jaeger tracing next steps
Due to the current lack of an official API for Jaeger, and the fact we can't simply iframe Jaeger due to security concerns, we need to consider an alternative method of proceeding with the integration.
The unofficial API is fairly stable and has undergone little change since initial release, however is planned to undergo a significant changes with the switch to gRPC: https://github.com/jaegertracing/jaeger/issues/773, https://github.com/jaegertracing/jaeger/issues/706
Any of these integration options prior to the switch to gRPC could be unpredictably fragile.
Shipping the Jaeger Frontend
Ship the Jaeger Frontend components, for example by hosting it at
jaeger.gitlab.domain (or some other method). Since the UI code is controlled by the GitLab administrator, it should be able to be embedded without major security concerns.
We would then reverse proxy the calls to
/api/* to the correct backend Jaeger instance.
This would allow us to leverage the velocity of the main Jaeger UI, as well as some of the integration options like the recent iframe support.
Build our own frontend
Rather than bundling the Jaeger front end, we could also consider building our own UI. We could start this process before the gRPC interface is complete with the understanding we would need to switch later, or wait until that is done.
This would allow us to fully control the experience, and have workflows which could span between the monitoring pillars. (E.g. I can click on a hostname in a trace, and see the logs/metrics/errors). We would also have to re-invent the entire UI, and would not benefit from any further investments there.