Metrics Dictionary Guide
Service Ping metrics are defined in individual YAML files definitions from which the Metrics Dictionary is built. Currently, the metrics dictionary is built automatically once a day. When a change to a metric is made in a YAML file, you can see the change in the dictionary within 24 hours. This guide describes the dictionary and how it’s implemented.
Metrics Definition and validation
We are using JSON Schema to validate the metrics definition.
This process is meant to ensure consistent and valid metrics defined for Service Ping. All metrics must:
- Comply with the defined JSON schema.
- Have a unique
key_path
. - Have an owner.
All metrics are stored in YAML files:
removed
are added to the Service Ping JSON payload.Each metric is defined in a separate YAML file consisting of a number of fields:
Field | Required | Additional information |
---|---|---|
key_path | yes | JSON key path for the metric, location in Service Ping payload. |
description | yes | |
product_section | yes | The section. |
product_stage | yes | The stage for the metric. |
product_group | yes | The group that owns the metric. |
value_type | yes |
string ; one of string , number , boolean , object . |
status | yes |
string ; status of the metric, may be set to active , removed , broken . |
time_frame | yes |
string ; may be set to a value like 7d , 28d , all , none . |
data_source | yes |
string ; may be set to a value like database , redis , redis_hll , prometheus , system , license , internal_events . |
data_category | yes |
string ; categories of the metric, may be set to operational , optional , subscription , standard . The default value is optional . |
instrumentation_class | yes |
string ; the class that implements the metric. |
distribution | yes |
array ; may be set to one of ce, ee or ee . The distribution where the tracked feature is available. |
performance_indicator_type | no |
array ; may be set to one of gmau , smau , paid_gmau , umau or customer_health_score . |
tier | yes |
array ; may contain one or a combination of free , premium or ultimate . The tier where the tracked feature is available. This should be verbose and contain all tiers where a metric is available. |
milestone | yes | The milestone when the metric is introduced and when it’s available to self-managed instances with the official GitLab release. |
milestone_removed | no | The milestone when the metric is removed. Required for removed metrics. |
introduced_by_url | no | The URL to the merge request that introduced the metric to be available for self-managed instances. |
removed_by_url | no | The URL to the merge request that removed the metric. Required for removed metrics. |
repair_issue_url | no | The URL of the issue that was created to repair a metric with a broken status. |
options | no |
object : options information needed to calculate the metric value. |
Metric key_path
The key_path
of the metric is the location in the JSON Service Ping payload.
The key_path
could be composed from multiple parts separated by .
and it must be unique.
We recommend to add the metric in one of the top-level keys:
-
settings
: for settings related metrics. -
counts_weekly
: for counters that have data for the most recent 7 days. -
counts_monthly
: for counters that have data for the most recent 28 days. -
counts
: for counters that have data for all time.
Metric statuses
Metric definitions can have one of the following statuses:
-
active
: Metric is used and reports data. -
broken
: Metric reports broken data (for example, -1 fallback), or does not report data at all. A metric marked asbroken
must also have therepair_issue_url
attribute. -
removed
: Metric was removed, but it may appear in Service Ping payloads sent from instances running on older versions of GitLab.
Metric value_type
Metric definitions can have one of the following values for value_type
:
boolean
number
string
-
object
: A metric withvalue_type: object
must havevalue_json_schema
with a link to the JSON schema for the object. In general, we avoid complex objects and prefer one of theboolean
,number
, orstring
value types. An example of a metric that usesvalue_type: object
istopology
(/config/metrics/settings/20210323120839_topology.yml
), which has a related schema in/config/metrics/objects_schemas/topology_schema.json
.
Metric time_frame
A metric’s time frame is calculated based on the time_frame
field and the data_source
of the metric.
data_source | time_frame | Description |
---|---|---|
any | none | A type of data that’s not tracked over time, such as settings and configuration information |
database | all | The whole time the metric has been active (all-time interval) |
database | 7d | 9 days ago to 2 days ago |
database | 28d | 30 days ago to 2 days ago |
internal_events | all | The whole time the metric has been active (all-time interval) |
internal_events | 7d | Most recent complete week |
internal_events | 28d | Most recent 4 complete weeks |
Data category
We use the following categories to classify a metric:
-
operational
: Required data for operational purposes. -
optional
: Default value for a metric. Data that is optional to collect. This can be enabled or disabled in the Admin Area. -
subscription
: Data related to licensing. -
standard
: Standard set of identifiers that are included when collecting data.
An aggregate metric is a metric that is the sum of two or more child metrics. Service Ping uses the data category of the aggregate metric to determine whether or not the data is included in the reported Service Ping payload.
Example YAML metric definition
The linked uuid
YAML file includes an example metric definition, where the uuid
metric is the GitLab
instance unique identifier.
key_path: uuid
description: GitLab instance unique identifier
product_section: analytics
product_stage: analytics
product_group: analytics_instrumentation
value_type: string
status: active
milestone: 9.1
instrumentation_class: UuidMetric
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/1521
time_frame: none
data_source: database
distribution:
- ce
- ee
tier:
- free
- premium
- ultimate
Create a new metric definition
The GitLab codebase provides dedicated generators to create new metrics, which also create valid metric definition files:
For uniqueness, the generated files include a timestamp prefix in ISO 8601 format.
Performance Indicator Metrics
To use a metric definition to manage performance indicator:
- Create a merge request that includes related changes.
- Use labels
~"analytics instrumentation"
,"~Data Warehouse::Impact Check"
. - Update the metric definition
performance_indicator_type
field. - Create an issue in GitLab Product Data Insights project with the PI Chart Help template to have the new metric visualized.
Metrics Dictionary
Metrics Dictionary is a separate application.
All metrics available in Service Ping are in the Metrics Dictionary.
Copy query to clipboard
To check if a metric has data in Sisense, use the copy query to clipboard feature. This copies a query that’s ready to use in Sisense. The query gets the last five service ping data for GitLab.com for a given metric. For information about how to check if a Service Ping metric has data in Sisense, see this demo.