debian-mirror-gitlab/doc/development/instrumentation.md

162 lines
4.8 KiB
Markdown
Raw Normal View History

2020-10-24 23:57:45 +05:30
---
stage: Monitor
2021-04-29 21:17:54 +05:30
group: Monitor
2021-02-22 17:27:13 +05:30
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
2020-10-24 23:57:45 +05:30
---
2021-03-11 19:13:27 +05:30
# Instrumenting Ruby code **(FREE)**
2016-06-02 11:05:42 +05:30
2019-12-04 20:38:33 +05:30
[GitLab Performance Monitoring](../administration/monitoring/performance/index.md) allows instrumenting of both methods and custom
2016-06-02 11:05:42 +05:30
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.
2021-03-08 18:12:59 +05:30
Please refer to [Product Intelligence](https://about.gitlab.com/handbook/product/product-intelligence-guide/) if you are tracking product usage patterns.
2020-03-13 15:44:24 +05:30
2016-06-02 11:05:42 +05:30
## Instrumenting Methods
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:
2021-02-22 17:27:13 +05:30
- `instrument_method`: Instruments a single class method.
- `instrument_instance_method`: Instruments a single instance method.
- `instrument_class_hierarchy`: Given a Class, this method recursively
instruments all sub-classes (both class and instance methods).
- `instrument_methods`: Instruments all public and private class methods of a
2016-06-02 11:05:42 +05:30
Module.
2021-02-22 17:27:13 +05:30
- `instrument_instance_methods`: Instruments all public and private instance
methods of a Module.
2016-06-02 11:05:42 +05:30
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:
2017-08-17 22:00:37 +05:30
```ruby
2016-06-02 11:05:42 +05:30
Gitlab::Metrics::Instrumentation.configure do |conf|
conf.instrument_method(Foo, :bar)
conf.instrument_method(Foo, :baz)
end
```
Using this method is in general preferred over directly calling the various
instrumentation methods.
Method instrumentation should be added in the initializer
2019-02-15 15:39:39 +05:30
`config/initializers/zz_metrics.rb`.
2016-06-02 11:05:42 +05:30
### Examples
Instrumenting a single method:
2017-08-17 22:00:37 +05:30
```ruby
2016-06-02 11:05:42 +05:30
Gitlab::Metrics::Instrumentation.configure do |conf|
conf.instrument_method(User, :find_by)
end
```
Instrumenting an entire class hierarchy:
2017-08-17 22:00:37 +05:30
```ruby
2016-06-02 11:05:42 +05:30
Gitlab::Metrics::Instrumentation.configure do |conf|
conf.instrument_class_hierarchy(ActiveRecord::Base)
end
```
Instrumenting all public class methods:
2017-08-17 22:00:37 +05:30
```ruby
2016-06-02 11:05:42 +05:30
Gitlab::Metrics::Instrumentation.configure do |conf|
conf.instrument_methods(User)
end
```
### Checking Instrumented Methods
The easiest way to check if a method has been instrumented is to check its
source location. For example:
2017-08-17 22:00:37 +05:30
```ruby
2018-12-05 23:21:45 +05:30
method = Banzai::Renderer.method(:render)
2016-06-02 11:05:42 +05:30
method.source_location
```
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:
2019-12-04 20:38:33 +05:30
- `$ Banzai::Renderer.render`
2016-06-02 11:05:42 +05:30
2021-02-22 17:27:13 +05:30
This prints a result similar to:
2016-06-02 11:05:42 +05:30
2020-04-22 19:07:51 +05:30
```plaintext
2016-06-02 11:05:42 +05:30
From: /path/to/your/gitlab/lib/gitlab/metrics/instrumentation.rb @ line 148:
Owner: #<Module:0x0055f0865c6d50>
Visibility: public
Number of lines: 21
def #{name}(#{args_signature})
2016-06-22 15:30:34 +05:30
if trans = Gitlab::Metrics::Instrumentation.transaction
trans.measure_method(#{label.inspect}) { super }
2016-06-02 11:05:42 +05:30
else
super
end
end
```
## Instrumenting Ruby Blocks
Measuring blocks of Ruby code is done by calling `Gitlab::Metrics.measure` and
passing it a block. For example:
```ruby
Gitlab::Metrics.measure(:foo) do
...
end
```
The block is executed and the execution time is stored as a set of fields in the
currently running transaction. If no transaction is present the block is yielded
without measuring anything.
2019-02-15 15:39:39 +05:30
Three values are measured for a block:
2016-06-02 11:05:42 +05:30
2020-06-23 00:09:42 +05:30
- The real time elapsed, stored in `NAME_real_time`.
- The CPU time elapsed, stored in `NAME_cpu_time`.
- The call count, stored in `NAME_call_count`.
2016-06-02 11:05:42 +05:30
Both the real and CPU timings are measured in milliseconds.
2021-02-22 17:27:13 +05:30
Multiple calls to the same block results in the final values being the sum
2016-06-02 11:05:42 +05:30
of all individual values. Take this code for example:
```ruby
3.times do
Gitlab::Metrics.measure(:sleep) do
sleep 1
end
end
```
2021-02-22 17:27:13 +05:30
Here, the final value of `sleep_real_time` is `3`, and not `1`.
2016-09-29 09:46:39 +05:30
## Tracking Custom Events
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:
```ruby
Gitlab::Metrics.add_event(:user_login, email: current_user.email)
```
Event names should be verbs such as `push_repository` and `remove_branch`.