debian-mirror-gitlab/lib/gitlab/metrics/metric.rb

53 lines
1.9 KiB
Ruby
Raw Normal View History

module Gitlab
module Metrics
# Class for storing details of a single metric (label, value, etc).
class Metric
2016-06-02 11:05:42 +05:30
JITTER_RANGE = 0.000001..0.001
2016-09-13 17:45:13 +05:30
attr_reader :series, :values, :tags, :type
# series - The name of the series (as a String) to store the metric in.
# values - A Hash containing the values to store.
# tags - A Hash containing extra tags to add to the metrics.
2016-09-13 17:45:13 +05:30
def initialize(series, values, tags = {}, type = :metric)
2016-08-24 12:49:21 +05:30
@values = values
@series = series
@tags = tags
2016-09-13 17:45:13 +05:30
@type = type
end
def event?
type == :event
end
# Returns a Hash in a format that can be directly written to InfluxDB.
def to_hash
2016-06-02 11:05:42 +05:30
# InfluxDB overwrites an existing point if a new point has the same
# series, tag set, and timestamp. In a highly concurrent environment
# this means that using the number of seconds since the Unix epoch is
# inevitably going to collide with another timestamp. For example, two
# Rails requests processed by different processes may end up generating
# metrics using the _exact_ same timestamp (in seconds).
#
# Due to the way InfluxDB is set up there's no solution to this problem,
# all we can do is lower the amount of collisions. We do this by using
2016-08-24 12:49:21 +05:30
# System.real_time which returns the nanoseconds as a Float providing
# greater accuracy. We then add a small random value that is large
# enough to distinguish most timestamps but small enough to not alter
# the timestamp significantly.
2016-06-02 11:05:42 +05:30
#
# See https://gitlab.com/gitlab-com/operations/issues/175 for more
# information.
2016-08-24 12:49:21 +05:30
time = System.real_time(:nanosecond) + rand(JITTER_RANGE)
2016-06-02 11:05:42 +05:30
{
series: @series,
tags: @tags,
values: @values,
2016-08-24 12:49:21 +05:30
timestamp: time.to_i
}
end
end
end
end