Skip to main content
Gå til innhold

Metrics

Metrics are numerical measurements aggregated over time, such as counts, rates, latencies and sizes. You graph them, alert on them and use them to understand trends. Choosing your signals describes when a metric is the right signal.

On Platon, metrics are stored in Mimir, and you read them in your team's Grafana organization.

What you get for free on Platon PaaS​

Every Platon PaaS workload automatically emits Kubernetes metrics to Mimir:

  • Container CPU usage
  • Container memory usage
  • Network traffic
  • Pod restarts

In Grafana, you can look in two organizations:

  • Your team's Grafana organization has a Mimir data source that already contains these metrics, so you can take a quick look at pod health there even if your application emits nothing but logs.
  • The "Sikt" Grafana organization, which everyone is a member of, has shared dashboards that show pod CPU and memory across teams.

Custom application metrics with OpenTelemetry​

To emit application-specific metrics, such as business counters, custom histograms and gauges:

  1. Instrument your application with OpenTelemetry.
  2. Configure the OTLP exporter as described in PaaS Full Observability.
  3. Read the metrics in Grafana through your team's Mimir data source.

Each of the example apps emits at least one custom counter or histogram, and you can use any of them as a working template.

Viewing metrics in Grafana​

  1. Go to Grafana.
  2. Open Explore.
  3. Select your Mimir data source.
  4. Write a PromQL query.

Example queries​

Current value of a metric:

http_server_request_duration_count{job="my-namespace/my-service"}

Rate of requests per second, by endpoint:

sum by (http_route) (rate(http_server_request_duration_count{job="my-namespace/my-service"}[5m]))

Error rate as a percentage:

sum(rate(http_server_request_duration_count{http_response_status_code=~"5..",job="my-namespace/my-service"}[5m]))
/ sum(rate(http_server_request_duration_count{job="my-namespace/my-service"}[5m])) * 100

Replace my-namespace/my-service with your job label, which reads <service.namespace>/<service.name>. On PaaS that is your Kubernetes namespace and service name, unless you set service.namespace yourself. SDKs on older semantic conventions (Python FastAPI and Node.js today) emit http_server_duration instead, with the status code in http_status_code. Counters your application sends over OTLP carry no _total suffix. If the first two queries return data and the error-rate query returns none, the service had no 5xx responses in the last five minutes.

Your metrics also carry a deployment_environment_name label, taken from the deployment.environment.name attribute, so you can select one environment. Mimir has added it to metrics received since 21 October 2026.

sum(rate(http_server_request_duration_count{deployment_environment_name="production",job="my-namespace/my-service"}[5m]))

Besides job, instance and this label, Mimir turns no resource attribute into a label. Loki keeps more of them as labels, so {k8s_namespace_name="my-namespace"} finds your logs but matches none of your metrics. The other attributes are on a separate series named target_info.

Cardinality​

Every unique combination of label values creates a new time series in Mimir, so a label like user_id, which has millions of unique values, can overload Mimir when you attach it to a metric. Keep label values low-cardinality. Namespace, route, HTTP status and error kind are appropriate, and user IDs, request IDs and email addresses are not.

See Choosing your signals — Common anti-patterns for more.

Exemplars​

Mimir supports metric exemplars. An exemplar is a representative trace ID attached to a metric data point. When you see a latency spike, turn on Exemplars in the query options. Click an exemplar and choose Query with Tempo to open the trace of a request that was slow.

Under the default exemplar filter, trace_based, only a measurement recorded inside a sampled span can become an exemplar. The SDK keeps a few of those for each series, so not every request gets an exemplar. Exemplars are attached to a histogram's _bucket series, so they appear on a latency graph built from _bucket and on none of the _count queries above.

SDK support for exemplars varies by language, so look up yours in the OpenTelemetry compliance matrix. In Python, opentelemetry-sdk supports exemplars from 1.28.0, and 1.29.0 fixes exporting metrics with exemplars. The JavaScript SDK does not implement exemplar sampling yet (opentelemetry-js issue 5147), so Node.js services emit no exemplars.

Platon sets up the link from an exemplar to its trace per tenant. If it is missing, ask the Platon team on #platon-observability.

Query language​

Mimir uses PromQL (Prometheus Query Language).

Metrics are retained for 180 days by default. See Tenants — Data retention for details.

Next steps​