KubeBolt / docs
GitHub

Metrics

Three metric sources — Metrics Server for live data, the agent for history and flows, or your existing Prometheus (including managed offerings).

KubeBolt has three metric sources. They compose: every cluster starts with Metrics Server, and the agent adds history when you want it.

SourceSetupWhat you get
Metrics ServerNone (pre-installed on most distros)Live CPU/memory for pods and nodes
Agent — collectors / scrapeInstall the agentHistorical metrics in KubeBolt’s embedded VictoriaMetrics: kubelet and node signals, optional vmagent scrape sidecar for Prometheus targets, optional Hubble network flows
Agent — read your PrometheusAgent with promReadSame history, sourced from the Prometheus you already run — including Amazon Managed Prometheus, Google Managed Prometheus, and Azure Monitor

Metrics Server (baseline)

The Metrics Collector polls metrics.k8s.io/v1beta1 (PodMetrics and NodeMetrics) every 30 seconds. Results are stored in an in-memory cache.

Graceful degradation: if Metrics Server is not installed, KubeBolt shows all resource state and events normally; CPU/memory bars display a one-click install command. The Collector distinguishes “not installed” from “403 Forbidden” via apierrors.IsForbidden().

Namespace-scoped fallback: when cluster-wide metrics access is denied, the Collector polls per accessible namespace instead.

Agent-shipped history

The agent ships samples over gRPC into KubeBolt’s embedded VictoriaMetrics, which powers the Capacity and Reliability tabs, workload metric history, and the Cost tab. One agent has exactly one canonical sample source:

scrape and promRead are mutually exclusive — the chart fails at helm template if both are enabled. If a node-exporter source already ships load/PSI series, set agent.deferNodeStress=true to avoid duplicate series.

Querying

Historical metrics are exposed through the API (/api/v1/metrics/query and /api/v1/metrics/query_range) using PromQL, scoped to the selected cluster.