GitLab Prometheus metrics development guidelines

GitLab provides Prometheus metrics to monitor itself.

Adding a new metric

This section describes how to add new metrics for self-monitoring (example).

1. Select the type of metric:

   • Gitlab::Metrics.counter
   • Gitlab::Metrics.gauge
   • Gitlab::Metrics.histogram
   • Gitlab::Metrics.summary

2. Select the appropriate name for your metric. Refer to the guidelines for Prometheus metric names.

3. Update the list of GitLab Prometheus metrics.

4. Carefully choose what labels you want to add to your metric. Values with high cardinality, like project_path, or project_id are strongly discouraged because they can affect our services availability due to the fact that each set of labels is exposed as a new entry in the /metrics endpoint. For example, a histogram with 10 buckets and a label with 100 values would generate 1000 entries in the export endpoint.

5. Trigger the relevant page or code that records the new metric.

6. Check that the new metric appears at /-/metrics.

For metrics that are not bounded to a specific context (request, process, machine, namespace, etc), generate them from a cron-based Sidekiq job:

• For Geo related metrics, check Geo::MetricsUpdateService.
• For other “global” / instance-wide metrics, check: Metrics::GlobalMetricsUpdateService.

When exporting data from Sidekiq in an installation with more than one Sidekiq instance, you are not guaranteed that the same exporter will always be queried.

You can read more and understand the caveats in issue 406583, where we also discuss a possible solution using a push-gateway.