While we have Metrics and Logging already available within GitLab, we don't have a true APM solution that can peer deeper into the application.. For example, we may know that latency is increasing, but we won't be able to show why or what function call.
Tracing provides this insight into the inner workings of the application, offering the ability to track spans across microservices and between different layers.
As a first step with tracing, we should do the following:
- Deploy Jaeger into a managed cluster (#5182)
- Documentation on how to instrument application code with open-tracing compatible tracers
- Instrument our sample apps (#5797)
- 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
We should also document that any data logged to this Jaeger instance will be available to users. As we don't have a way to restrict this to only this projects
- We should add
Tracingas a new option to the