Skip to content

Metrics

Live cluster resource usage and short-term trends with no observability stack required, and long-retention history from your own Prometheus on the same page when you run one.

Tier: Free

What it does

Metrics gives you live cluster resource usage and short-term trends without standing up a separate observability stack. It is one page: each section — node capacity, node conditions, CPU and memory trends, top consumers, storage, rightsizing, the API server — appears once. When a Prometheus you connected answers, those sections are drawn from it, with longer history and an ad-hoc PromQL box; otherwise they come from KubeManta's built-in sampler. Each chart names its source. Pod network bandwidth lives on the Network page, and Metrics links there.

Setting the metrics source to self keeps the page on the built-in sections and stops it asking Prometheus anything; a "Source:" label in the header says so. A Grafana tab appears beside Metrics only once a Grafana source is configured.

Everything in the built-in sections 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. 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.

Pod network bandwidth is collected here and shown on the Network page. 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, under Metrics source in Admin → Observability → Prometheus, 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.

With Prometheus connected, the same sections — node capacity, CPU and memory, a by-namespace breakdown and top consumers — are PromQL-backed and gain 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. The CPU and memory history charts are queried together and each one draws as soon as its own answer arrives. It requires a Prometheus source configured in Admin → Observability and a Pro license. When Prometheus cannot serve, the page says why in one line and keeps the built-in sections: not configured (admins see where to connect it), configured but unreachable, and the important one — reachable, but with no pod-labelled series. 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 would return nothing; KubeManta detects this case, says so, and still offers PromQL. 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 tab appears only when a Grafana source is configured in Admin → Observability, and embeds your own dashboards beside Metrics 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.

Rightsizing: requests against what was actually used

The Rightsizing table, below Storage, compares each workload's CPU and memory requests with what its pods actually used, and says which way it is off:

  • Over-provisioned — it uses far less than it requests (CPU under 30%, or memory under 40%, of the request). The difference is capacity reserved for nothing.
  • Above request — it regularly uses more than it requests, so the scheduler is placing it on a promise it does not keep.
  • Near memory limit — its peak memory reached 90% of the limit: the next spike is an OOMKill.
  • No request set — the workload is BestEffort, first to be evicted under pressure. A starting request is suggested from what it used.

CPU is judged on the 95th percentile of each hour's per-pod peak; memory on the per-pod peak, because memory cannot be throttled. Suggested requests add 20% headroom. The window is stated next to the table — "based on the last 5d 3h of usage" — and it matters: a recommendation from a quiet week will be too small for a busy one. Nothing is forecast. Until a workload has 24 hours of history the table says it is still collecting rather than guessing. Workloads whose requests fit are hidden unless you tick Show workloads that fit.

Usage comes from metrics-server, sampled every minute for every pod and kept as hourly figures for the same 7 days as the other trends.

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 sections need only metrics-server. Pod network bandwidth, on the Network page, 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 the bandwidth chart on the Network page stays 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.5.0 — this page is rendered from the product's own documentation, so it cannot drift from what ships. Manifest built 2026-11-03T12:53:14Z.