As a first step with tracing, we should do the following:
- Deploy Jaeger, storage backend into a managed cluster (#5182)
- Documentation on how to instrument application code with open-tracing compatible tracers
- Provide a method to view the Jaeger UI from within GitLab
We have done some exploration on potential options for integrating the Jaeger UI with GitLab in: #5159 (closed). We determined that the best short term path forward was to try to use GitLab to reverse proxy the Jaeger UI from within GitLab.
Utilize existing Workhorse functionality, specifically how Terminal is implemented there, to proxy the Jaeger UI from within GitLab. Terminal is essentially doing two way proxy with an external service and does authorization with GitLab's pre-auth API.
This approach offers a few key benefits:
- We get to re-use the full existing authentication and authorization of GitLab, as opposed to relying on something like
oauth_proxywhich is authorized at the instance level.
- We also get to re-use our existing k8s proxy functionality, which we currently use for Prometheus queries.
When a user goes to http://gitlab.com/namespace/project/cluster/1/proxy/app_name/#
This request will be proxied 1:1 to the application installed through Gitlab UI. So for example, Jaeger could be
Until the Operations tab arrives (gitlab-ce#43673) we can simply put a button to open the Jaeger UI next to the monitoring button for an environment:
The downside to this is that the Jaeger UI is not environment specific. Certainly open to other ideas on where to surface this as well.
When the button is clicked, we can simply pop open a new tab taking the user to the proxied URL (see above).