SYS.DOCS // DOCS

Cluster Metrics

The Metrics tab in Clusters → Observability is the cluster metrics explorer for VictoriaMetrics.

Use it to inspect scraped Kubernetes and application metrics without leaving Edka.

Requirements

The Metrics tab requires VictoriaMetrics to be installed from Observability → Settings.

Until the service is installed, the tab stays in a not-installed state and links back to Settings.

What the Metrics tab does

The explorer is a PromQL workflow backed by the in-cluster VictoriaMetrics store.

You can:

enter a raw metric name or a PromQL expression
use autocomplete while typing metric names
browse the indexed metric catalog and filter it by name or category
switch the lookback window from 5m up to 7d
inspect returned series in a table
view a chart for the current query result
zoom into a smaller chart window and rerun the query against that range
open the VictoriaMetrics UI (vmui) when private UI exposure is configured

The tab also surfaces live explorer context from the VictoriaMetrics overview:

indexed metric count
current result series count
total scrape target count

Query behavior

Edka runs an instant query for the expression in the query bar.

If the instant query has no live sample but recent data exists, Edka can fall back to the latest sample from the selected range window so the explorer still shows the newest known value.

This is useful for metrics that are sparse or only emitted periodically.

Metric catalog

The built in metric catalog helps you discover what is already being scraped.

You can:

browse the full indexed metric list
filter metric names with free-text search
group by broad categories derived from the metric name prefix
click a metric to copy it into the query bar

This is the fastest way to discover cluster metrics before writing a larger PromQL expression.

Time windows and charts

The query window controls how far back Edka looks when charting the result and when applying the range fallback behavior.

Available windows currently run from:

5m
15m
30m
1h
6h
12h
1d
7d

When a query returns chart data, Edka renders the series inline and lets you zoom into a narrower time span directly from the chart.

What VictoriaMetrics stores

VictoriaMetrics is installed as a managed observability service and stores cluster metrics on a persistent volume inside the cluster.

From Observability → Settings, Edka can manage:

retention period
scrape interval
whether to scrape all running pod container ports at /metrics when pods have not opted in with prometheus.io annotations
storage size and storage class
CPU and memory requests and limits
private UI exposure through Tailscale-aware traffic classes

The Settings view also shows runtime status such as:

pod readiness
restart count
scrape target health
CPU and memory usage vs requests and limits
PVC capacity and utilization
warnings from the managed app

Scrape model

VictoriaMetrics is configured to scrape:

itself
annotated Kubernetes pods
Kubernetes components discovered through the built in scrape config

If Scrape All Pods is enabled in Settings, Edka also scrapes running pod container ports at /metrics even when the workload has not explicitly opted in with annotations.

That makes the metrics view useful both for standard Kubernetes signals and for application metrics exposed by your workloads.

NAT Gateway metrics

When NAT Gateway is enabled and VictoriaMetrics is installed, Edka adds NAT gateway scrape targets and shows NAT-specific metrics on the NAT Gateway page.

These metrics include:

forward, return, and NAT traffic rates
egress latency
conntrack entries and utilization
conntrack events
interface drops and errors
forwarded metadata and SMTP/25 drops

When NAT Gateway is enabled on an existing cluster, Edka updates the VictoriaMetrics scrape configuration and restarts VictoriaMetrics so the new targets are loaded. Metrics can still take one or more scrape intervals to appear after the restart.

Private UI access

If VictoriaMetrics UI exposure is enabled in Observability → Settings, Edka shows an Open VMUI action in the Metrics tab.

Current behavior:

exposure is private, not public internet access
the Tailscale operator must already be installed on the cluster
access is routed through a Tailscale-aware traffic class

When to use Metrics vs Diagnostics

Use Metrics when you need:

PromQL exploration
historical timeseries context
scrape target visibility
application and Kubernetes metric inspection

Use Diagnostics when you need:

Kubernetes warning events
pods requiring attention
K3s control plane troubleshooting
node and cluster warning summaries