2020-08-04 17:09:56 -04:00
---
stage: Monitor
2020-10-19 17:09:06 -04:00
group: Health
2020-08-04 17:09:56 -04:00
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/#designated-technical-writers
---
2018-09-04 09:01:34 -04:00
# Working with Prometheus Metrics
## Adding to the library
2019-09-18 14:06:14 -04:00
We strive to support the 2-4 most important metrics for each common system service that supports Prometheus. If you are looking for support for a particular exporter which has not yet been added to the library, additions can be made [to the `common_metrics.yml` ](https://gitlab.com/gitlab-org/gitlab/blob/master/config/prometheus/common_metrics.yml ) file.
2018-09-04 09:01:34 -04:00
### Query identifier
2018-09-05 16:01:17 -04:00
The requirement for adding a new metric is to make each query to have an unique identifier which is used to update the metric later when changed:
2018-09-04 09:01:34 -04:00
```yaml
- group: Response metrics (NGINX Ingress)
metrics:
2020-07-03 05:08:53 -04:00
- title: "Throughput"
y_axis:
name: "Requests / Sec"
format: "number"
precision: 2
queries:
- id: response_metrics_nginx_ingress_throughput_status_code
query_range: 'sum(rate(nginx_upstream_responses_total{upstream=~"%{kube_namespace}-%{ci_environment_slug}-.*"}[2m])) by (status_code)'
unit: req / sec
label: Status Code
2018-09-04 09:01:34 -04:00
```
### Update existing metrics
2019-12-05 07:07:43 -05:00
After you add or change an existing common metric, you must [re-run the import script ](../administration/raketasks/maintenance.md#import-common-metrics ) that will query and update all existing metrics.
Or, you can create a database migration:
2018-09-04 09:01:34 -04:00
```ruby
2018-12-12 10:38:40 -05:00
class ImportCommonMetrics < ActiveRecord::Migration [ 4 . 2 ]
2018-09-04 16:51:02 -04:00
include Gitlab::Database::MigrationHelpers
2018-09-04 09:01:34 -04:00
DOWNTIME = false
def up
2019-07-09 17:31:28 -04:00
::Gitlab::DatabaseImporters::CommonMetrics::Importer.new.execute
2018-09-04 09:01:34 -04:00
end
def down
# no-op
end
end
```
2019-09-03 10:24:26 -04:00
2020-10-13 20:08:48 -04:00
If a query metric (which is identified by `id:` ) is removed it will not be removed from database by default.
You might want to add additional database migration that makes a decision what to do with removed one.
For example: you might be interested in migrating all dependent data to a different metric.
2019-09-03 10:24:26 -04:00
## GitLab Prometheus metrics
GitLab provides [Prometheus metrics ](../administration/monitoring/prometheus/gitlab_metrics.md )
to monitor itself.
### Adding a new metric
This section describes how to add new metrics for self-monitoring
2020-02-06 10:09:11 -05:00
([example](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/15440)).
2019-09-03 10:24:26 -04:00
1. Select the [type of metric ](https://gitlab.com/gitlab-org/prometheus-client-mmap#metrics ):
- `Gitlab::Metrics.counter`
- `Gitlab::Metrics.gauge`
- `Gitlab::Metrics.histogram`
- `Gitlab::Metrics.summary`
1. Select the appropriate name for your metric. Refer to the guidelines
for [Prometheus metric names ](https://prometheus.io/docs/practices/naming/#metric-names ).
1. Update the list of [GitLab Prometheus metrics ](../administration/monitoring/prometheus/gitlab_metrics.md ).
1. Trigger the relevant page/code that will record the new metric.
1. Check that the new metric appears at `/-/metrics` .