From ca464b603396693ae992096a4efa05def0fa28e8 Mon Sep 17 00:00:00 2001 From: Andrew Newdigate Date: Mon, 7 Jan 2019 12:40:54 +0200 Subject: Adds inter-service OpenTracing propagation This change allows the GitLab rails and sidekiq components to receive tracing spans from upstream services such as Workhorse and pass these spans on to downstream services including Gitaly and Sidekiq. This change will also emit traces for incoming and outgoing requests using the propagated trace information. This will allow operators and engineers to view traces across the Workhorse, GitLab Rails, Sidekiq and Gitaly components. Additional intra-service instrumentation will be added in future changes. --- config/initializers/tracing.rb | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) (limited to 'config') diff --git a/config/initializers/tracing.rb b/config/initializers/tracing.rb index be95f30d075..46e8125daf8 100644 --- a/config/initializers/tracing.rb +++ b/config/initializers/tracing.rb @@ -3,6 +3,26 @@ if Gitlab::Tracing.enabled? require 'opentracing' + Rails.application.configure do |config| + config.middleware.insert_after Gitlab::Middleware::CorrelationId, ::Gitlab::Tracing::RackMiddleware + end + + # Instrument the Sidekiq client + Sidekiq.configure_client do |config| + config.client_middleware do |chain| + chain.add Gitlab::Tracing::Sidekiq::ClientMiddleware + end + end + + # Instrument Sidekiq server calls when running Sidekiq server + if Sidekiq.server? + Sidekiq.configure_server do |config| + config.server_middleware do |chain| + chain.add Gitlab::Tracing::Sidekiq::ServerMiddleware + end + end + end + # In multi-processed clustered architectures (puma, unicorn) don't # start tracing until the worker processes are spawned. This works # around issues when the opentracing implementation spawns threads -- cgit v1.2.3