Metrics

A metric explorer scoped by entity type rather than by raw metric name, so you start from the thing you are debugging instead of scrolling a list of two hundred names.

Pick the level first

Kubernetes metrics resolve at four levels, and each one is a different entity type with its own metric-name prefix:

Level	Entity type	Prefix	Notes
Container	k8s_pod	container.	Broken down per container by k8s.container.name
Pod	k8s_pod	k8s.pod.
Node	k8s_node	k8s.node.
Host	host	system.

Picking the level first is what stops you summing a container gauge across a node and getting a number that means nothing. It also keeps the board fast: without it, opening the pod level would fire one query per metric across every name on that entity type, most of which are application histograms you did not ask for.

Container metrics live on the pod entity

There is no separate container entity type. Container metrics are stored on k8s_pod and tagged with the container name, which is why the container level groups by k8s.container.name automatically.

Building a view

1. Level — container, pod, node or host.
2. Metric name — scoped to that level’s prefix.
3. Group by — split the series by namespace, workload, node, or any tag. Chips, so you can stack more than one.
4. Tag search — filter to the subset you care about before charting it.
5. Aggregation — avg, sum, min, max, p95.
6. Chart type — line, area or bar.

Sparkline tiles give you the board at a glance; clicking one expands it into a full series chart.

Choosing an aggregation

The aggregation is not cosmetic — it decides what question you are asking:

• max answers “did this ever get bad?” Use it for saturation checks.
• p95 answers “is this normally bad?” Use it for sizing and SLOs.
• avg across many series hides the one that is on fire. Group by first, then average.
• sum is only meaningful over a partition — summing a utilisation percentage across pods produces a number with no unit.

The time range

Shared with Traces and Logs. Presets are 15m · 1h · 6h · 24h · 3d · 7d, or an absolute range. A preset re-resolves against the wall clock — every 15s on 15m, every 5 minutes on the longer windows — so a chart left open keeps moving.

Per-cluster isolation

Metrics are isolated per cluster by tag, so a workload with the same name in two clusters never merges into one series.

A worked view

Which container in the payments namespace is driving pod memory:

1. Level Container.
2. Metric container.memory.usage.
3. Tag search k8s.namespace.name:payments.
4. Group by k8s.container.name — the sidecar usually appears here.
5. Aggregation max to catch the peak, then p95 to see whether the peak is routine.

From the CLI

rtz metrics list --entity-type K8S_POD
rtz metrics query k8s.pod.memory.usage --entity-type K8S_POD --group-by k8s.pod.name --agg max
rtz metrics tags --entity-type K8S_POD --key namespace
rtz metrics entities --entity-type K8S_NODE

--entity-type is required — the API answers a missing one with a 500, so the CLI catches it first and names the flag.

A terminal cannot draw a curve, so metrics query summarises each series as last / min / max plus the point count, and says when the backend rewrote the query as a per-second rate. Use -o json for the raw points.

See Logs, traces & metrics.