kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity
gitlab-org--gitlab-foss/config/initializers/tracing.rb

26 lines
1,022 B
Ruby
Raw Normal View History

Conditionally initialize the global opentracing tracer This change will instantiate an OpenTracing tracer and configure it as the global tracer when the GITLAB_TRACING environment variable is configured. GITLAB_TRACING takes a "connection string"-like value, encapsulating the driver (eg jaeger, etc) and options for the driver. Since each service, whether it's written in Ruby or Golang, uses the same connection-string, it should be very easy to configure all services in a cluster, or even a single development machine to be setup to use tracing. Note that this change does not include instrumentation or propagation changes as this is a way of breaking a previous larger change into components. The instrumentation and propagation changes will follow in separate changes.
2019-01-07 05:40:54 -05:00
# frozen_string_literal: true
Migrate correlation and tracing code to LabKit This change is a fairly straightforward refactor to extract the tracing and correlation-id code from the gitlab rails codebase into the new LabKit-Ruby project. The corresponding import into LabKit-Ruby was in https://gitlab.com/gitlab-org/labkit-ruby/merge_requests/1 The code itself remains very similar for now. Extracting it allows us to reuse it in other projects, such as Gitaly-Ruby. This will give us the advantages of correlation-ids and distributed tracing in that project too.
2019-02-18 15:57:22 -05:00
if Labkit::Tracing.enabled?
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.
2019-01-07 05:40:54 -05:00
Rails.application.configure do |config|
Add latest changes from gitlab-org/gitlab@master
2020-10-30 05:08:39 -04:00
# Rack needs to parse multipart messages before ActionDispatch can filter parameters
config.middleware.insert_after Rack::MethodOverride, ::Labkit::Tracing::RackMiddleware
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.
2019-01-07 05:40:54 -05:00
end
Add cache tracing and Redis tracing This change adds Distributed Tracing support for two new types of events 1. Redis Calls 1. ActiveSupport (Rails) Caching Operations The intention is to help application developers and infrastructure SREs to understand the pressure that caching operations can have on the application when running at scale. The Redis and Caching spans can be viewed in the Jaeger UI by clicking the "Trace" link in the performance bar when running on GDK.
2019-08-23 06:11:19 -04:00
# Instrument Redis
Labkit::Tracing::Redis.instrument
Add latest changes from gitlab-org/gitlab@master
2021-01-22 10:09:08 -05:00
Labkit::Tracing::ExternalHttp.instrument
Add cache tracing and Redis tracing This change adds Distributed Tracing support for two new types of events 1. Redis Calls 1. ActiveSupport (Rails) Caching Operations The intention is to help application developers and infrastructure SREs to understand the pressure that caching operations can have on the application when running at scale. The Redis and Caching spans can be viewed in the Jaeger UI by clicking the "Trace" link in the performance bar when running on GDK.
2019-08-23 06:11:19 -04:00
Adds tracing support for ActiveRecord notifications This change will publish distributed tracing spans related to SQL ActiveRecord queries. These queries are unbound, so will still contain parameter substitution strings in place of actual parameter values. This ensures that the SQL strings do not need to be scrubbed, since the values are not included in the SQL. More details of rails instrumentation can be found here: https://guides.rubyonrails.org/active_support_instrumentation.html
2019-01-23 09:53:23 -05:00
# Instrument Rails
Migrate correlation and tracing code to LabKit This change is a fairly straightforward refactor to extract the tracing and correlation-id code from the gitlab rails codebase into the new LabKit-Ruby project. The corresponding import into LabKit-Ruby was in https://gitlab.com/gitlab-org/labkit-ruby/merge_requests/1 The code itself remains very similar for now. Extracting it allows us to reuse it in other projects, such as Gitaly-Ruby. This will give us the advantages of correlation-ids and distributed tracing in that project too.
2019-02-18 15:57:22 -05:00
Labkit::Tracing::Rails::ActiveRecordSubscriber.instrument
Labkit::Tracing::Rails::ActionViewSubscriber.instrument
Add cache tracing and Redis tracing This change adds Distributed Tracing support for two new types of events 1. Redis Calls 1. ActiveSupport (Rails) Caching Operations The intention is to help application developers and infrastructure SREs to understand the pressure that caching operations can have on the application when running at scale. The Redis and Caching spans can be viewed in the Jaeger UI by clicking the "Trace" link in the performance bar when running on GDK.
2019-08-23 06:11:19 -04:00
Labkit::Tracing::Rails::ActiveSupportSubscriber.instrument
Adds tracing support for ActiveRecord notifications This change will publish distributed tracing spans related to SQL ActiveRecord queries. These queries are unbound, so will still contain parameter substitution strings in place of actual parameter values. This ensures that the SQL strings do not need to be scrubbed, since the values are not included in the SQL. More details of rails instrumentation can be found here: https://guides.rubyonrails.org/active_support_instrumentation.html
2019-01-23 09:53:23 -05:00
Add latest changes from gitlab-org/gitlab@master
2021-05-19 08:10:33 -04:00
# In multi-processed clustered architectures (e.g. Puma cluster) don't
Conditionally initialize the global opentracing tracer This change will instantiate an OpenTracing tracer and configure it as the global tracer when the GITLAB_TRACING environment variable is configured. GITLAB_TRACING takes a "connection string"-like value, encapsulating the driver (eg jaeger, etc) and options for the driver. Since each service, whether it's written in Ruby or Golang, uses the same connection-string, it should be very easy to configure all services in a cluster, or even a single development machine to be setup to use tracing. Note that this change does not include instrumentation or propagation changes as this is a way of breaking a previous larger change into components. The instrumentation and propagation changes will follow in separate changes.
2019-01-07 05:40:54 -05:00
# start tracing until the worker processes are spawned. This works
# around issues when the opentracing implementation spawns threads
Gitlab::Cluster::LifecycleEvents.on_worker_start do
Migrate correlation and tracing code to LabKit This change is a fairly straightforward refactor to extract the tracing and correlation-id code from the gitlab rails codebase into the new LabKit-Ruby project. The corresponding import into LabKit-Ruby was in https://gitlab.com/gitlab-org/labkit-ruby/merge_requests/1 The code itself remains very similar for now. Extracting it allows us to reuse it in other projects, such as Gitaly-Ruby. This will give us the advantages of correlation-ids and distributed tracing in that project too.
2019-02-18 15:57:22 -05:00
tracer = Labkit::Tracing::Factory.create_tracer(Gitlab.process_name, Labkit::Tracing.connection_string)
Conditionally initialize the global opentracing tracer This change will instantiate an OpenTracing tracer and configure it as the global tracer when the GITLAB_TRACING environment variable is configured. GITLAB_TRACING takes a "connection string"-like value, encapsulating the driver (eg jaeger, etc) and options for the driver. Since each service, whether it's written in Ruby or Golang, uses the same connection-string, it should be very easy to configure all services in a cluster, or even a single development machine to be setup to use tracing. Note that this change does not include instrumentation or propagation changes as this is a way of breaking a previous larger change into components. The instrumentation and propagation changes will follow in separate changes.
2019-01-07 05:40:54 -05:00
OpenTracing.global_tracer = tracer if tracer
end
end
Copy permalink