Metrics¶

Live cluster resource usage, short-term trends, and pod network bandwidth with no observability stack required, plus Prometheus and Grafana side by side when you already run them.

Tier: Free

What it does¶

Metrics gives you live cluster resource usage, short-term trends, and pod network bandwidth without standing up a separate observability stack. If you do run Prometheus or Grafana, the same tab surfaces them side by side. The tab has three sub-tabs: Built-in, which needs only metrics-server; Prometheus, which shows setup guidance until a source is configured; and Grafana, which appears only once a Grafana source is configured. A non-auto metrics source is exclusive: self hides the Prometheus sub-tab, and prometheus hides Built-in and stops its polling. When a sub-tab is missing for that reason, a "Source:" pill in the tab header names the setting that removed it.

Everything in the Built-in sub-tab works with no Prometheus and no configuration beyond metrics-server. Node Capacity opens with four rings — nodes ready, pods against the schedulable ceiling, and CPU and memory against allocatable — so cluster headroom reads at a glance before you look at any single node; per-node cards below break the same figures down, with the resource that will bind first called out on each. Without metrics-server the CPU and memory rings show REQUESTS instead of live usage and say so, rather than drawing an empty ring that would look like an idle cluster. Resource Trends plots CPU (cores) and memory over a 1h/6h/24h/7d window — a background sampler reads pod metrics every 60 seconds and retains one cluster rollup, per- namespace rollups, and the top 20 pods by CPU, pruned after 7 days; charts follow the panel's namespace scope and show a "collecting…" state until at least two samples exist. Network Bandwidth shows pod RX/TX rate trends from the built-in kubelet cadvisor scrape (below). API Server reports the Kubernetes API server's status and latency with no setup at all; request rate, error rate, p99 latency and a per-verb breakdown come from Prometheus, and the card says so when Prometheus is not connected — or when it is connected but the control plane exposes no apiserver_* metrics.

metrics-server exposes no network metrics — the kubelet's embedded cadvisor is the only in-cluster source of pod network bytes. Nothing has to be deployed to use it: cadvisor already runs inside every kubelet. Each sampler tick scrapes every node's kubelet directly, using the agent's own ServiceAccount, and stores raw byte counters; rates are derived at read time with counter-reset handling, so a pod or kubelet restart never produces a bogus spike, and sampler-gap handling, so agent downtime never dilutes a rate.

This is on by default, and the permission it needs is why. The kubelet authorizes the scrape against nodes/metrics, which grants the metrics endpoints and nothing else — it cannot exec into a container, read logs, or proxy any other request. Set metrics.kubeletScrape.enabled=false to turn the whole thing off; CPU and memory are unaffected either way.

Some clusters firewall the kubelet port (10250) away from pods. For those, metrics.kubeletScrape.viaProxy=true routes the same scrape through the Kubernetes API server instead. That path is authorized against nodes/proxy, a permission that reaches every kubelet handler including exec and logs, so it is never granted unless you ask for it — and turning it on is the only thing that puts nodes/proxy in the ClusterRole.

One case may need a decision from you. A kubelet's serving certificate has to be signed by a CA the agent trusts. Managed providers generally issue one that verifies — measured working on AKS with no extra configuration. A self-managed cluster built with kubeadm does not enable serverTLSBootstrap by default, so its kubelet certificates are self-signed and verification fails there.

When it fails, bandwidth charts stay empty and the metrics source names the reason; CPU, memory and everything else are unaffected. KubeManta does not quietly continue when that happens — the connection carries the agent's ServiceAccount token, and anything able to answer for a node's address would collect it. The scrape reports the reason instead, and you choose: viaProxy above, or metrics.kubeletScrape.insecureSkipVerify=true to accept it deliberately.

The scrape is fail-soft throughout: a refused or unreachable node records a reason, visible via the metrics source endpoint, and never affects CPU/memory sampling.

Like the container-scanning source picker, the metrics source is admin-selectable at runtime between auto (self-scrape when the kubelet scrape is on, else Prometheus if configured, else metrics-server only), self (force the built-in cadvisor scrape), and prometheus (KubeManta performs zero kubelet scrapes and defers entirely to your own Prometheus). CPU and memory always come from metrics-server regardless of the source setting — the self-scrape is network-only, never a second CPU/mem path.

The Prometheus sub-tab mirrors the Built-in views — node capacity, CPU and memory, network throughput, a by-namespace breakdown and top consumers — with every series PromQL-backed, and adds what only Prometheus offers: long-retention windows from 1h through 30d/90d, far past the built-in sampler's 7-day prune, and ad-hoc PromQL over the selected window. It requires a Prometheus source configured in Admin → Observability and a Pro license. The sub-tab has three distinct empty states: not configured, configured-but-unreachable, and the important one — reachable, but every panel blank. That happens when your Prometheus scrapes a standalone or Docker cadvisor whose series carry id and interface labels but no namespace/pod labels, so every pod-scoped chart returns nothing; KubeManta detects this case and says so explicitly. Prometheus needs to scrape the cluster's kubelet/cadvisor — kube-prometheus- stack does this out of the box — and Admin → Observability includes a "Generate scrape config" action that emits the exact read-only RBAC and scrape job for your existing Prometheus.

With the built-in source covering live CPU/mem, roughly 7-day trends, and bandwidth, Prometheus is not required for basic container metrics. What it uniquely adds is your own application metrics — latency histograms, custom counters — which are never collected by the built-in path; kube-state-metrics and node-exporter series; ad-hoc PromQL; and PromQL for the AI Copilot, which can query your app metrics during an investigation only when Prometheus is configured.

The Grafana sub-tab appears only when a Grafana source is configured in Admin → Observability, and embeds your own dashboards inside the Metrics tab with a dashboard picker and kiosk-mode embed — separate from, and in addition to, the option to embed one dashboard as the Overview page itself.

Top consumers, and how far the list goes¶

CPU and memory each get their own ranking of the ten heaviest pods, filterable by namespace and node. "See more" extends a ranking to fifty and names how many rows are behind it, so a list that stops at ten is never mistaken for a cluster that only has ten pods. The two rankings expand independently.

Storage¶

The Storage list inventories PersistentVolumeClaims for the selected namespace, or the whole cluster. It is sorted by capacity, largest first — sizes are compared as real quantities, so 10Gi ranks above 9Gi and above 500Mi rather than sorting as text. Any column heading re-sorts the list, and a claim with no capacity yet (still Pending) sorts to the end in both directions rather than appearing to be the smallest volume you have. Long lists are paged.

Following a top consumer¶

Clicking a pod in a top-consumers ranking opens its detail panel beside the list — status, conditions, containers and recent events — rather than navigating to another tab. The ranking stays on screen, because the reason you clicked was to compare that pod against the rows around it. The panel's own links do navigate, when you ask them to.

Setup¶

Reach Metrics from the OBSERVE group in the sidebar. The Built-in sub-tab needs only metrics-server. Pod network bandwidth works out of the box via the kubelet cadvisor scrape described above — no Prometheus, nothing to deploy, and a nodes/metrics grant that covers the metrics endpoints only. To use Prometheus instead, configure it under Admin → Observability and confirm a Pro license entitlement — set the metrics source to prometheus if you want KubeManta to perform zero kubelet scrapes of its own.

Admin → Observability has three sub-tabs, one per system, because they are configured independently and most installs have only one of them: Prometheus (the metrics source, and the scrape-config generator described under Troubleshooting), Alertmanager (where you point your existing Alertmanager at KubeManta so its alerts arrive on the Alerts tab), and Grafana (the dashboard links surfaced beside your own charts). Configuring one does not require or imply the others.

Troubleshooting¶

If bandwidth charts stay empty, first check the metrics source endpoint's scrape-health fields. Each node's failure is reported there by name, with the reason: a 401/403 means the nodes/metrics grant is missing (check metrics.kubeletScrape.enabled), a TLS verification failure means the kubelet's serving certificate is self-signed (choose viaProxy or insecureSkipVerify), and a connection timeout usually means port 10250 is firewalled from pods (use viaProxy). In every case it degrades to an empty chart with an explanatory hint rather than an error. If Prometheus is configured and reachable but every pod-scoped panel is blank, this is almost always the cadvisor-labelling issue above — your Prometheus is scraping a standalone cadvisor instead of the cluster's kubelet/cadvisor, so its series lack namespace/pod labels; regenerate the scrape config from Admin → Observability and point Prometheus at the cluster's kubelet endpoint instead.

Generated from KubeManta 1.2.0 — this page is rendered from the product's own documentation, so it cannot drift from what ships. Manifest built 2026-09-12T02:14:45Z.