Commit graph

21 commits

Author SHA1 Message Date
Yorick Peterse
a257d117a0
Fix setting of "action" for Grape transactions
Merely setting the "action" tag will only result in the transaction
itself containing a value for this tag. To ensure other metrics also
contain this tag we must set the action using Transaction#action=
instead.
2016-04-20 22:42:52 +02:00
Yorick Peterse
229f3ce9ce
Configuring of points per UDP packet
This allows users to configure the number of points stored in a single
UDP packet. This in turn can be used to reduce the number of UDP packets
being sent at the cost of these packets being somewhat larger.

The default setting is 1 point per packet so nothing changes for
existing users.
2016-04-19 14:35:25 +02:00
Yorick Peterse
3240ecfbef
Added ability to add custom tags to transactions
One use case for this is manually setting the "action" tag for Grape API
calls. Due to Grape running blocks there are no human readable method
names that can be used for the "action" tag, thus we have to set these
manually on a case by case basis.
2016-04-13 11:22:37 +02:00
Yorick Peterse
7eed4608fe
Fixed stubbing for Gitlab::Metrics specs
If the measure method uses Transaction.current directly the SQL
subscriber (Subscribers::ActiveRecord) will add timings of queries
triggered by DB cleaner.
2016-04-11 14:29:38 +02:00
Yorick Peterse
d9110a7eca
Track call counts in Gitlab::Metrics.measure_block 2016-04-11 13:27:52 +02:00
Yorick Peterse
16926a676b
Store block timings as transaction values
This makes it easier to query, simplifies the code, and makes it
possible to figure out what transaction the data belongs to (simply
because it's now stored _in_ the transaction).

This new setup keeps track of both the real/wall time _and_ CPU time
spent in a block, both measured using milliseconds (to keep all units
the same).
2016-04-11 13:09:36 +02:00
Yorick Peterse
1af6cf28c0 Measure Ruby blocks using Gitlab::Metrics
This allows measuring of timings of arbitrary Ruby blocks, this allows
for more fine grained performance monitoring. Custom values and tags can
also be attached to a block.
2016-04-06 14:31:52 +02:00
Yorick Peterse
2367160015 Make the metrics sampler interval configurable 2016-01-13 12:29:48 +01:00
Yorick Peterse
355c341fe7 Stop tracking call stacks for instrumented views
Where a vew is called from doesn't matter as much. We already know what
action they belong to and this is more than enough information. By
removing the file/line number from the list of tags we should also be
able to reduce the number of series stored in InfluxDB.
2016-01-12 15:41:22 +01:00
Yorick Peterse
8fdc00bd4c Remove InfluxDB username/password
InfluxDB over UDP doesn't use authentication, thus there's no need for
these settings.
2016-01-06 17:49:56 +01:00
Yorick Peterse
cafc784ee1 Removed tracking of hostnames for metrics
This isn't hugely useful and mostly wastes InfluxDB space. We can re-add
this whenever needed (but only once we really need it).
2015-12-31 17:55:10 +01:00
Yorick Peterse
55ed6e1c96 Cache InfluxDB settings after the first use
This ensures we don't need to load anything from either PostgreSQL or
the Rails cache whenever creating new InfluxDB connections.
2015-12-31 17:47:07 +01:00
Yorick Peterse
701e5de910 Use Gitlab::CurrentSettings for InfluxDB
This ensures we can still start up even when not connecting to a
database.
2015-12-29 15:49:12 +01:00
Yorick Peterse
620e7bb3d6 Write to InfluxDB directly via UDP
This removes the need for Sidekiq and any overhead/problems introduced
by TCP. There are a few things to take into account:

1. When writing data to InfluxDB you may still get an error if the
   server becomes unavailable during the write. Because of this we're
   catching all exceptions and just ignore them (for now).
2. Writing via UDP apparently requires the timestamp to be in
   nanoseconds. Without this data either isn't written properly.
3. Due to the restrictions on UDP buffer sizes we're writing metrics one
   by one, instead of writing all of them at once.
2015-12-29 14:53:45 +01:00
Yorick Peterse
ed214a11ca Handle missing settings table for metrics
This ensures we can still boot, even when the "application_settings"
table doesn't exist.
2015-12-28 22:38:34 +01:00
Yorick Peterse
4d925f2147 Move InfluxDB settings to ApplicationSetting 2015-12-28 18:00:32 +01:00
Yorick Peterse
1be5668ae0 Added host option for InfluxDB 2015-12-28 13:14:48 +01:00
Yorick Peterse
f181f05e8a Track object counts using the "allocations" Gem
This allows us to track the counts of actual classes instead of "T_XXX"
nodes. This is only enabled on CRuby as it uses CRuby specific APIs.
2015-12-17 17:25:48 +01:00
Yorick Peterse
a41287d898 Only track method calls above a certain threshold
This ensures we don't end up wasting resources by tracking method calls
that only take a few microseconds. By default the threshold is 10
milliseconds but this can be changed using the gitlab.yml configuration
file.
2015-12-17 17:25:48 +01:00
Yorick Peterse
60a6a240ea Improved last_relative_application_frame timings
The previous setup wasn't exactly fast, resulting in instrumented method
calls taking about 600 times longer than non instrumented calls
(including any ActiveSupport code involved). With this commit this
slowdown has been reduced to around 185 times.
2015-12-17 17:25:48 +01:00
Yorick Peterse
141e946c3d Storing of application metrics in InfluxDB
This adds the ability to write application metrics (e.g. SQL timings) to
InfluxDB. These metrics can in turn be visualized using Grafana, or
really anything else that can read from InfluxDB. These metrics can be
used to track application performance over time, between different Ruby
versions, different GitLab versions, etc.

== Transaction Metrics

Currently the following is tracked on a per transaction basis (a
transaction is a Rails request or a single Sidekiq job):

* Timings per query along with the raw (obfuscated) SQL and information
  about what file the query originated from.
* Timings per view along with the path of the view and information about
  what file triggered the rendering process.
* The duration of a request itself along with the controller/worker
  class and method name.
* The duration of any instrumented method calls (more below).

== Sampled Metrics

Certain metrics can't be directly associated with a transaction. For
example, a process' total memory usage is unrelated to any running
transactions. While a transaction can result in the memory usage going
up there's no accurate way to determine what transaction is to blame,
this becomes especially problematic in multi-threaded environments.

To solve this problem there's a separate thread that takes samples at a
fixed interval. This thread (using the class Gitlab::Metrics::Sampler)
currently tracks the following:

* The process' total memory usage.
* The number of file descriptors opened by the process.
* The amount of Ruby objects (using ObjectSpace.count_objects).
* GC statistics such as timings, heap slots, etc.

The default/current interval is 15 seconds, any smaller interval might
put too much pressure on InfluxDB (especially when running dozens of
processes).

== Method Instrumentation

While currently not yet used methods can be instrumented to track how
long they take to run. Unlike the likes of New Relic this doesn't
require modifying the source code (e.g. including modules), it all
happens from the outside. For example, to track `User.by_login` we'd add
the following code somewhere in an initializer:

    Gitlab::Metrics::Instrumentation.
      instrument_method(User, :by_login)

to instead instrument an instance method:

    Gitlab::Metrics::Instrumentation.
      instrument_instance_method(User, :save)

Instrumentation for either all public model methods or a few crucial
ones will be added in the near future, I simply haven't gotten to doing
so just yet.

== Configuration

By default metrics are disabled. This means users don't have to bother
setting anything up if they don't want to. Metrics can be enabled by
editing one's gitlab.yml configuration file (see
config/gitlab.yml.example for example settings).

== Writing Data To InfluxDB

Because InfluxDB is still a fairly young product I expect the worse.
Data loss, unexpected reboots, the database not responding, you name it.
Because of this data is _not_ written to InfluxDB directly, instead it's
queued and processed by Sidekiq. This ensures that users won't notice
anything when InfluxDB is giving trouble.

The metrics worker can be started in a standalone manner as following:

    bundle exec sidekiq -q metrics

The corresponding class is called MetricsWorker.
2015-12-17 17:25:48 +01:00