Prometheus API metric schema

Reading time: 0 minute(s) (0 words)

The Prometheus API exposes a fixed, public set of metrics for your SLOs. The tables below list each metric's Prometheus type.

Labels

Every SLO metric carries these labels:

Label	Description
project	Project the SLO belongs to.
slo	SLO name.
objective	Objective (threshold) name within the SLO.
service	Service the SLO is attached to.

Metrics whose names start with component_ carry three additional labels identifying the component SLO within a composite SLO:

Label	Description
component_project	Project of the component SLO.
component_slo	Name of the component SLO.
component_objective	Objective of the component SLO.

Use any of these labels as PromQL matchers, for example reliability{project="default",slo="my-slo"}.

Core metrics

Available for all SLOs.

Metric	Type	Description
reliability	gauge	SLO objective reliability as a ratio from 0 to 1.
target	gauge	Current target of the SLO objective. Reflects the currently configured value.
budget	gauge	Remaining error budget as a ratio from 0 to 1. It can be negative when the budget is overspent.
burn_rate	gauge	SLO objective burn rate, where 1 means a 1x burn rate.
count_good	gauge	Count of good events or good minutes observed in the time window.
count_total	gauge	Count of total events or total minutes observed in the time window. For occurrence composites it is always 1.

The count_good and count_total metrics are gauges because they cover the current SLO time window. Their values can decrease when older observations leave the window.

Count delta metrics

Available for all SLOs. While count_good and count_total report the running totals for the current SLO time window, the delta metrics report how much those counts grew, so you can see event volume over time rather than a single accumulated value.

Metric	Type	Description
count_good_delta	gauge	Increment of good events or good minutes since the previous sample.
count_total_delta	gauge	Increment of total events or total minutes since the previous sample.

Both metrics are also available pre-aggregated at a fixed resolution. Add one of the following suffixes to the metric name to get the increment over that period instead of since the previous sample: _1m, _5m, _15m, _1h, _1d. For example, count_good_delta_5m reports the increment of good events or good minutes over 5 minutes.

Pre-aggregated variants return fewer points over a long time range than aggregating the raw metric yourself, so pick the resolution that matches the range you're querying: _1m or _5m for the last few hours, _1h or _1d for weeks or months.

Aggregating delta metrics

These metrics are gauges that already hold an increment, so sum them over a window with sum_over_time rather than rate or increase, which expect counters.

Threshold SLI metrics

Available for SLOs that use a threshold (single time series) SLI.

Metric	Type	Description
sli_threshold	gauge	Threshold SLI value received by Nobl9.
sli_threshold_status	gauge	Threshold SLI status, where 0 means bad and 1 means good.
threshold	gauge	Current threshold of the SLO objective. Reflects the currently configured value.

Ratio SLI metrics

Available for SLOs that use a ratio (good-over-total) SLI.

Metric	Type	Description
sli_ratio_received_good	counter or gauge	Good ratio SLI value received by Nobl9.
sli_ratio_received_bad	counter or gauge	Bad ratio SLI value received by Nobl9.
sli_ratio_received_total	counter or gauge	Total ratio SLI value received by Nobl9.
sli_ratio_used_good	counter	Cumulative good ratio SLI value used to calculate the SLO budget.
sli_ratio_used_total	counter	Cumulative total ratio SLI value used to calculate the SLO budget.

The received metrics are counters for SLOs configured with incremental: true. For SLOs configured with incremental: false, they are gauges that report the value for each collection interval. Because the same metric names cover both configurations, the /metadata endpoint returns both type entries for each received metric.

The used metrics are always cumulative counters. For a non-incremental SLO, Nobl9 converts the received interval values to cumulative counts before calculating the SLO budget.

The received and used values can also differ when the good (or bad) and total time series aren't aligned in time. Points without a matching counterpart may be dropped, or a value may be interpolated between two existing points. Use the received metrics to see the incoming data and the used metrics to reconcile how the budget was computed.

Time-slices metrics

Available for SLOs that use the time-slices budgeting method.

Metric	Type	Description
time_slice_allowance	gauge	Current configured time-slice allowance. Reflects the currently configured value.
time_slice_reliability	gauge	Good-to-total ratio for a time slice.
time_slice_status	gauge	Time-slice status, where 0 means bad and 1 means good.

Composite metrics

Available for composite (v2) SLOs. The component_ metrics also carry the component labels described above.

Metric	Type	Description
component_weight	gauge	Current configured weight of a component SLO. Reflects the currently configured value.
component_impact	gauge	Impact of a component SLO on the composite budget.
component_delay	gauge	Delay of a component SLO, in seconds, when the composite result was calculated.
component_was_delayed	gauge	Component delay-strategy outcome: 0 used, 1 counted as good, 2 counted as bad, 3 ignored.
composite_max_delay	gauge	Composite max-delay setting, in seconds.

Composite 1.0 not supported

Data for composite 1.0 objectives is not queryable through the Prometheus API. Use composite v2 SLOs to query component metrics.

Configured values versus historical values

Some metrics come from the SLO's current configuration rather than from time-series data: target, threshold, time_slice_allowance, and component_weight. These always report the currently configured value, even when you query a past time range during which the value was different. All other metrics reflect the value computed for the queried point in time.

Discovering what's available

To list the projects, SLOs, services, or objectives you can query, use the /label/{label_name}/values endpoint, for example to list all SLOs in a project:

curl --globoff -u 'clientId:clientSecret' \
  'https://app.nobl9.com/api/prometheus/v1/api/v1/label/slo/values' \
  --data-urlencode 'match[]=reliability{project="default"}'