Skip to content

Next

GitLab
GitLab
Closed
Opened by Joshua Lambert@joshlambert0 of 3 tasks completed0/3 tasks
Report abuse New issue

Tracing MVC

Problem

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.

Solution

Tracing provides this insight into the inner workings of the application, offering the ability to track spans across microservices and between different layers of a monolith.

As a first step with tracing, we should do the following:

  1. Add Tracing to Operations side bar, below Metrics.
  2. Clicking on Tracing would show an empty state, with a button to configure Tracing. (Only show to people with access to Settings)
  3. Clicking the button would take you to Settings -> Operations (new page)
  4. Tracing URL is entered and saved on Operations page
  5. Once a URL is saved, clicking on the Tracing item in the sidebar will pop a new tab to Jaeger.

Current UX Proposal (from https://gitlab.com/gitlab-org/gitlab-ee/issues/7950)

ee_7950-jaeger-config-v12

Illustration SVG Measure spec previews

Original Description 

### Problem

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.

### Solution

Tracing provides this insight into the inner workings of the application, offering the ability to track spans across microservices and between different layers of a monolith. 

As a first step with tracing, we should do the following:
- [ ] Provide a method to view the Jaeger UI from within GitLab
- [ ] Instrument our sample apps (https://gitlab.com/gitlab-org/gitlab-ee/issues/5797)
- [ ] Documentation on how to instrument application code with open-tracing compatible tracers 

We have done some exploration on potential options for integrating the Jaeger UI with GitLab in: https://gitlab.com/gitlab-org/gitlab-ee/issues/5159. We determined that the best short term path forward was to try to use GitLab to reverse proxy the Jaeger UI from within GitLab.

### Proposal

#### Technical approach

Utilize the Kubernetes reverse proxy capability in the api-server, to proxy through to the Jaeger UI service. This is similar to what we do for Prometheus, but instead of a webservice call we will be proxying browser traffic. We will likely need to set the `baseURL` parameter of Jaeger, for this to work.

This approach offers a few key benefits:
1. We get to re-use the full existing authentication and authorization of GitLab, as opposed to relying on an external component. This is because Jaeger has no auth layer.
1. We also get to re-use our existing k8s proxy functionality, which we currently use for Prometheus queries.

When a user goes to a specific URL, for example `http://gitlab.com/namespace/project/cluster/1/proxy/app_name/#`,
the requests will be proxied 1:1 to the application installed through Gitlab UI. So for example, Jaeger could be `http://gitlab.com/namespace/project/cluster/1/proxy/jaeger/#`.

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

#### UX Proposal

* We should add `Tracing` as a new option  to the `Operations` tab, below `Logs`.



* This should then display a page within GitLab to allow users to select an environment, then a button to pop open Jaeger in a new tab.

![ee_7950-jaeger-config-v10](/uploads/6ebfa20d22d842d8bc61dab22f53aa58/ee_7950-jaeger-config-v10.png)
Edited by Amelia Bauerly

Related issues