Metrics
Metrics are aggregated numerical measurements over time — counts, rates, latencies, sizes. They are what you graph, alert on, and use to understand trends. For guidance on when a metric is the right signal, see Choosing your signals.
On Platon, metrics live in Mimir and are accessed through your team's Grafana organization.
What you get for free on Platon PaaS
Every Platon PaaS workload automatically emits Kubernetes metrics to Mimir, with no setup required:
- Container CPU usage
- Container memory usage
- Network traffic
- Pod restarts
These are pre-wired into two places:
- Your team's Grafana organization has a Mimir data source preloaded with Kubernetes metrics.
- The "Sikt" Grafana organization (which everyone is a member of) has shared dashboards showing pod CPU and memory across teams.
This applies even if your application emits nothing but logs. For a quick read on pod health, no further setup is needed.
Custom application metrics with OpenTelemetry
To emit application-specific metrics (business counters, custom histograms, gauges):
- Instrument your application with OpenTelemetry.
- Configure the OTLP exporter — see PaaS Full Observability.
- Access metrics in Grafana via your team's Mimir data source.
The example apps each emit at least one custom counter or histogram and serve as a working template.
Viewing metrics in Grafana
- Go to Grafana.
- Open Explore.
- Select your Mimir data source.
- Write a PromQL query.
Example queries
Current value of a metric:
http_server_request_duration_seconds_count{namespace="my-namespace"}
Rate of requests per second, by endpoint:
sum by (http_route) (rate(http_server_request_duration_seconds_count{namespace="my-namespace"}[5m]))
Error rate as a percentage:
sum(rate(http_server_request_duration_seconds_count{status=~"5..",namespace="my-namespace"}[5m]))
/ sum(rate(http_server_request_duration_seconds_count{namespace="my-namespace"}[5m])) * 100
Cardinality
Every unique combination of label values creates a new time-series in Mimir. Attaching a label like user_id (millions of unique values) to a metric can overload the backend. Keep label values low-cardinality: namespace, route, HTTP status, and error kind are appropriate. User IDs, request IDs, and email addresses are not.
See Choosing your signals — Common anti-patterns for more.
Exemplars
Mimir supports metric exemplars — a representative trace ID attached to a metric data point. When you see a latency spike, click the exemplar to jump to a real slow request in Tempo. OpenTelemetry enables exemplars automatically when both traces and metrics are wired up.
Query language
Mimir uses PromQL (Prometheus Query Language).
Metrics are retained for 180 days by default. See Data Retention for details.
Next steps
- Choosing your signals — when to reach for a metric vs. a log vs. a span.
- Alerting — notifications on metric thresholds.
- OpenTelemetry tutorial — if you have not enabled OTel yet.