Skip to content

Tracing Prototype

We need to do investigation to get a deep technical understanding of the best way to move forward with integration of Jaeger.

Key questions to answer:

  • There is no current official "API", what is the best way to get data out of Jaeger?
    • Ideally we re-use the business logic of Jaeger, without having to go direct to storage.
  • What is the best approach for building the UI? Can we leverage any components or JS out of Jaeger to move more quickly?
  • Are there any concerns with ElasticSearch, that would cause us to need to use Cassandra?

At the end of this release cycle, we should have a prototype that can hit Jaeger and pull data back with some basic rendering of some kind.

Potential long term paths forward

Build our own UI component from the ground up

Rebuild the full UI in Vue. Proxy the requests through the k8s adapter, when deployed there.

Pros:

  • Full control over the UI. Will be able to build an integrated workflow between logging/metrics/tracing where you can jump between them.
    • For example, a pod is seeing increased latency, click on pod_id and lookup in tracing. Debug a bit, can right click on a request_id to pull up relevant logs.

Cons:

  • Significant up front effort to be able to hit the minimum functionality to be useful
  • On-going effort to stay up to speed with Jaeger functionality, won't get any help from upstream UI improvements
  • No public API contract for lower level services.

Re-use some Jaeger-UI components

Re-use some components of Jaeger-UI, build into GitLab interface.

Pros:

  • Faster time to market with functionality than rebuilding it all ourselves.
  • Potential ability to make use of future enhancements to Jaeger-UI components.
  • Ability to contribute some changes upstream, including making the UI more pluggable into larger UI's.

Cons:

  • Will likely need to make some changes to support proxying through k8s adapter.
  • Built in different tools: React, different CSS lib. Learning curve for GitLab developers.
  • Trying to route requests through the k8s adapter could require significant rewriting of components.

Short term path forward

Since the above two options will likely require some initial investment, probably larger than a single release, we should consider alternative short term options.

Proposal:

  • Add the ability to proxy the Jaeger interface through workhorse, similar to how Terminal works today.
  • Tracing screen could then be either an iframe, or simply spawn a new tab for now when clicking on the item in the UI.
  • As we start to build our own interface, we could retain this ability to jump into the "full" UI of Jaeger for features we may not have implemented yet. It could be presented as a button, for example.
  • Note: this would also be valuable for Prometheus, to provide the ability to interactively play with queries until we ship https://gitlab.com/gitlab-org/gitlab-ee/issues/4452.

The downside to these options is that this would be a somewhat unusual workflow for GitLab: embedding a third party interface in our own, or shelling out for some major functionality.

Edited by silv