Skip to main content
This document describes how the Firebolt Operator exposes Prometheus metrics for the components it manages.

Metrics endpoints

The gateway metrics port defaults to 9090 and is configurable per FireboltInstance CR via spec.gateway.metricsPort. Metadata pods do not currently expose a Prometheus metrics endpoint.

Firebolt Operator metrics mode

The Firebolt Operator metrics endpoint mode is controlled by two Helm values: The Firebolt Operator PodMonitor template automatically adapts its port reference, scheme, bearer token, and TLS configuration based on metrics.secure.

Scraping with Prometheus

The Firebolt Operator Helm chart ships optional PodMonitor resources (one per component type) that can be enabled via values.yaml:
Each PodMonitor uses label selectors to match the relevant pods:
  • Engines: firebolt.io/engine (exists). Matches all engine pods regardless of engine name
  • Gateway: firebolt.io/component=gateway
  • Firebolt Operator: control-plane=controller-manager + chart selector labels
When allNamespaces is true, namespaceSelector.any: true is added so pods in any namespace are discovered. This does not apply to the Firebolt Operator PodMonitor because the Firebolt Operator always runs in the release namespace.

Per-instance monitoring

The chart-level PodMonitors apply uniform scrape configuration to all instances in scope. If you need per-instance control (different intervals, selective enablement, custom relabelings), disable the chart-level PodMonitors and deploy your own alongside each FireboltInstance or FireboltEngine CR. The label selectors to use are:
  • Engine pods: firebolt.io/engine: <engine-name>
  • Gateway pods: firebolt.io/instance: <instance-name>, firebolt.io/component: gateway
The chart creates PodMonitors only when you enable them and the Prometheus Operator CRDs are installed. Customize intervals, relabeling, and TLS settings on your own PodMonitors when the chart defaults do not fit your monitoring platform. The Gateway exposes a read-only stats listener on its metrics port. Its Envoy administration interface remains loopback-only and is not a Prometheus target.

Operator metrics reference

FireboltEngine metrics

FireboltInstance metrics

JWT signing-key rotation metrics

Present on every FireboltInstance, and flat zero on one that does not use auth.

Label glossary

Example PromQL queries

Engine not ready:
Engine stuck in draining phase for more than 10 minutes:
Scaling in progress (ready pods less than desired):
Instance degraded:
Stuck controller (no reconcile for 5 minutes):
Drain probe failures spiking:
Fleet overview (ready engines per instance):
Signing-key rotation stalled for more than 30 minutes:
Which step, and how many engines it is waiting for:
A rotation is in flight (more than one key tracked):

Alerting on a stalled rotation

Every irreversible rotation step waits for the whole engine fleet to converge, and waits indefinitely — parking is the safe behaviour, so a stuck rotation raises no error and leaves AuthReady True. That makes elapsed time the signal worth alerting on. A normal rotation parks each gate only for as long as one engine roll takes, so a threshold well above your rollout time separates the two:
The Firebolt Operator also emits a SigningKeyRotationStalled Warning Event when a rotation remains parked past its threshold.

Cardinality

Each FireboltEngine produces approximately 15 time series (6 phases + 2 conditions + 7 scalar gauges). Each FireboltInstance produces approximately 21 series (4 phases + 6 conditions + 1 info + 1 timestamp + 3 signing-key phases + 3 rotation steps + 3 scalar rotation gauges). For a cluster with 10 Instances and 50 Engines, expect roughly 960 time series from the Firebolt Operator. The phase and step labels on the signing-key metrics are bounded enumerations written on every pass, including zeros, so they add a fixed handful of series per Instance and never grow with rotation count. Metric label sets are cleaned up when CRs are deleted, so terminated engines do not leave stale series.