Metrics, dashboards and SLOs

Orbit Pulse stores metrics next to logs and traces, so you can chart them, put them on dashboards and set service level objectives. This page is for developers who send metrics and for members who build dashboards and SLOs.

Send metrics

Send metrics over OTLP with the key and endpoints in Send telemetry with OpenTelemetry, or post JSON points with an ingest key:

curl -sS -X POST "https://acme.orbit.inortix.com/api/v1/pulse/intake/metrics" \
  -H "X-Pulse-Key: $INGEST_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "checkout.queue.depth", "type": "gauge", "value": 42, "service": "checkout", "env": "staging", "tags": {"region": "eu"}}'

The reply is 202 with accepted, rejected and an errors list. You can also send one array of points, or newline-delimited points.

Type	Stored as	Comes from OTLP as
`gauge` (default)	The value at a time	Gauges, and cumulative sums that can go down
`count`	The increase since the previous point	Sums that only go up, and delta sums that can go down
`histogram`	Count, sum, min, max and bucket counts	Explicit-bucket histograms

A JSON point has a name, a value and optionally a unit, a timestamp, service, env, host and up to 32 tags. JSON counts are increases, not running totals. Exponential histograms and summaries are not supported yet.

The series limit

A series is one metric name and type with one combination of service, environment, host and tags. A project can start a limited number of new series each day. Points of further new series are rejected and counted, while existing series keep flowing. The metrics catalog and the Usage view show your project’s limit and how much of it is used today.

A tag whose value changes with every request starts a new series each time. The catalog also lists the rejected points and metric names.

Explore metrics

Open Metrics for the catalog: each metric with its type, series and last point. Pick a metric, then shape the chart:

Filter by tags with the shared syntax, for example service:checkout -env:dev host:web-*. Free text and @attributes are refused with a position.
Rollup combines each series in a time bucket: avg, sum, min, max, last or count for gauges, and sum or rate for counts.
Aggregation combines the series of a group: avg, sum, min, max or count. For histograms you choose a percentile (p50 to p99), avg, sum, count, min or max.
Group by up to four tags. The tags panel adds a value to the filter or excludes it.

Ranges run from 15 minutes to 15 days. The chart shows the 50 largest groups. Create monitor turns the query on screen into a metric monitor; see Monitors and alerts.

Build a dashboard

A dashboard holds up to 40 widgets on a 12-column grid. Members and project administrators edit dashboards, and every role reads them. A project can have up to 200.

Widget	Shows
Timeseries	One line, bar or area per group, with a legend that hides series
Query value	One number, optionally compared with the previous period, with warn and alert thresholds
Toplist	Groups ranked by value, up to 100 rows, with thresholds
Log stream	The latest matching logs, with Open in Logs
Note	Plain text up to 4,000 characters

Each chart widget reads metrics, logs (counts) or spans. For spans it can show hits, errors, error rate, percentiles, and average or maximum latency, for entry spans or for all spans. A dashboard has one time picker.

Add up to 10 variables. A variable such as $service filters on a tag: choosing checkout becomes service:checkout, and * removes the term. Pulse suggests values from metric series and from the last hour of logs and spans.

Edit mode has a widget editor with a live preview. An invalid widget is refused with its position, for example Widget 13 (Checkout CPU): …. Saving a dashboard that someone else changed meanwhile is refused.

You can clone or delete a dashboard. You can also export it as one JSON file that holds everything, and import such a file to create a dashboard. A ready-made template shows one service’s health, with service and env variables. Two more templates, for containers and for the Orbit platform, are made for Orbit’s own stack. Their container charts use the container.* metrics that Orbit’s own agent sends, and they stay empty unless your project receives metrics with those names.

Track an SLO

A service level objective is a target share of good events over a rolling 7, 30 (default) or 90 days.

SLO based on	Good and bad
Requests	Service entry spans. Bad when they match a bad filter (`status:error` by default) or take longer than a latency threshold.
Logs	Logs matching a filter. Bad when they also match a bad filter.
Metrics	A count metric for good events over a count metric for the total, each with a tag filter.
A monitor	Time with no group of the monitor in `ALERT`.

Set a target above 0 and below 100, such as 99.9, and optionally a stricter warning target. A project can have up to 200 SLOs.

Pulse computes the SLI and the error budget left, which is negative once overspent. It also computes the burn rate over 5 minutes, 1 hour, 6 hours, 1 day and 3 days. A burn rate of 1 spends the budget exactly over the timeframe. The state is ok, warning, breached or no data.

The list shows the worst SLOs first. The detail page has the charts, the burn-rate table and the monitors that watch the SLO. Use Alert on burn rate or Alert on budget to create an slo monitor. A burn-rate monitor fires only while a long and a short window both burn. The editor suggests 14.4 over 1 hour, with a 5-minute short window.