Migrate lib/gitlab/tracing to LabKit or elsewhere
The Problem
The GitLab application now has tracing instrumentation built-in
For Go-based services, we vendor the LabKit project (https://gitlab.com/gitlab-org/labkit). For Ruby, the code resides in the lib/gitlab/tracing
directory.
Gitaly uses the LabKit extensions, but Gitaly-Ruby is at present not instrumented.
There would be a great deal of value extending the tracing instrumentation to the Gitaly-Ruby process. This is because Gitaly-Ruby makes some calls back out to the application and having visibility into these requests (for dealing with issues such as gitaly#1447 (closed) / https://gitlab.com/gitlab-org/gitlab-ce/issues/53473) would add a huge amount of value.
Since this code is kept in lib/gitlab/tracing
, it's not possible to reuse it in Gitaly-Ruby. One approach would be to duplicate the source between projects but this has obvious downsides.
Proposed Solution
The benefits of keeping the Go instrumentation outside of the main application have been great. We were able to quickly instrument both Gitaly and Workhorse, with changes and fixes being downstreamed to both projects. Extending this tracing to the runner and pages projects would be trivial.
I propose that, alongside the Go code, we also make the LabKit a Ruby Gem artifact, containing the Ruby instrumentation (ie, what's currently in lib/gitlab/tracing
).
This would allow us to include the same Gem in GitLab-CE as well as Gitaly-Ruby, and possibly in future, GitLab-Shell and other Ruby processes that we run.
Opinions?
cc @jacobvosmaer-gitlab @stanhu @nick.thomas @ayufan @reprazent