GitLab Performance Monitoring allows instrumenting of both methods and custom blocks of Ruby code. Method instrumentation is the primary form of instrumentation with block-based instrumentation only being used when we want to drill down to specific regions of code within a method.

Instrumenting methods is done by using the Gitlab::Metrics::Instrumentation module. This module offers a few different methods that can be used to instrument code:

instrument_method: instruments a single class method.

instrument_instance_method: instruments a single instance method.

instrument_class_hierarchy: given a Class this method will recursively instrument all sub-classes (both class and instance methods).

instrument_methods: instruments all public and private class methods of a Module.

instrument_instance_methods: instruments all public and private instance methods of a Module.

To remove the need for typing the full Gitlab::Metrics::Instrumentation namespace you can use the configure class method. This method simply yields the supplied block while passing Gitlab::Metrics::Instrumentation as its argument. An example:

If the source location points to lib/gitlab/metrics/instrumentation.rb you know the method has been instrumented.

If you're using Pry you can use the $ command to display the source code of a method (along with its source location), this is easier than running the above Ruby code. In case of the above snippet you'd run the following:

Besides instrumenting code GitLab Performance Monitoring also supports tracking of custom events. This is primarily intended to be used for tracking business metrics such as the number of Git pushes, repository imports, and so on.

To track a custom event simply call Gitlab::Metrics.add_event passing it an event name and a custom set of (optional) tags. For example:

Gitlab::Metrics.add_event(:user_login, email: current_user.email)

Event names should be verbs such as push_repository and remove_branch.