Forecasts for Prometheus-compatible metrics, exposed as Prometheus metrics.
promforecast reads a YAML config, queries a Prometheus-compatible TSDB
(VictoriaMetrics by default), runs statsforecast
models, and exposes the predictions on /metrics. Forecasts become first-class
metrics — graphable in Grafana, alertable through Alertmanager, indistinguishable
from anything else in your monitoring stack.
- Drop-in.
helm installnext to an existing Prometheus and point it at a long-term TSDB. No production scrape changes required. - Speak Prometheus everywhere. PromQL in, exposition format out. The TSDB is swappable (VictoriaMetrics, Mimir, Thanos).
- Forecasts are just metrics. Same labels, same retention, same dashboards. Compose with recording rules and alerts you already know.
- Stateless. No database to operate. Models refit on a schedule; results
live in
/metrics.
helm repo add promforecast https://esops-dev.github.io/promforecast
helm install promforecast promforecast/promforecast-stackThis installs VictoriaMetrics, the forecaster, and example dashboards.
For an existing TSDB, install only promforecast/promforecast.
The umbrella chart ships sink + VictoriaMetrics as the canonical
forecast write path: the forecaster pushes the full forecast curve into
VM with native future timestamps, and the bundled ServiceMonitor drops
the redundant *_forecast / *_forecast_lower / *_forecast_upper
snapshot families from the scrape so dashboards plot a smooth forward
curve rather than averaging the sink push against a 5-minute snapshot
staircase. See docs/reference/emission-paths.md
for what each path emits and the dual-source trap that motivates the
defaults. Existing snapshot-only installs upgrading to the new defaults
should follow docs/how-to/migrate-to-sink-first.md
and use promforecast diagnose duplicates to confirm the cutover.
Editing the YAML config does not require a pod restart: the
forecaster watches the mounted ConfigMap, validates the new config
in-place, and rolls back on validation failure (kubectl apply to the
ConfigMap is enough). POST /-/reload and SIGHUP trigger the same
path. See docs/reference/cli.md for promforecast validate,
which CI users can run against a config file before merging.
See docs/ for configuration, model selection, and operational
guidance. Before flipping production traffic, walk
docs/production-checklist.md — sizing
tables, reference architectures, and the boxes worth ticking off
before going live. For a real-world deployment — multi-group config,
HA values, and ready-to-apply ArgoCD/Flux manifests with a reference
architecture diagram — see examples/production/.
New to forecasting Prometheus metrics? The
docs/cookbook/ collection covers the common
metric families (disk-fill, request rate, Kafka lag, JVM GC, AWS
spend, ...) with copy-pasteable configs sized for a small fleet and
companion alert snippets — the fastest path from "I want to forecast
X" to "X is on a dashboard with an alert".
Early development. Output metric names are part of the public API and follow Prometheus conventions strictly (no colons — those are reserved for recording rules).
Found a vulnerability? See SECURITY.md. Please do not open public issues for security reports.
See CONTRIBUTING.md and the docs/ folder for rule authoring.