Prometheus
inari.prometheus
Time-series database and monitoring server that scrapes metrics endpoints on a schedule, stores samples locally, and evaluates PromQL queries, recording rules and alert conditions against them.
A Docker Compose file for Prometheus alone, generated from the catalog and checked by the safety inspector. Sign in and use Kitchen Credits to activate it.
Uses the Medusa cart and payment-session path. This test control does not create an order or capture payment.
Prometheus pulls metrics from targets found through static configuration or service discovery, storing each sample against a metric name and label set in a local time-series database. PromQL selects and aggregates those series by label, which is what lets one query cover an entire fleet rather than a named host. Recording rules precompute expensive expressions and alerting rules evaluate conditions continuously, handing firing alerts to a separate Alertmanager for grouping, silencing and delivery. Local storage is intended for a bounded retention window, with longer history delegated to a remote-write backend.
You know it worked when
- The interface loads and the targets page shows each target as up.
- A PromQL query returns a series for a known metric.
- A recording rule produces its derived series.
- An alert rule moves to pending and then firing while its condition holds.
- History from before a restart remains queryable with a persisted data directory.
Known sharp edges
- Local storage is sized by retention window and sample rate, and the data directory must be persistent or all history is lost on recreation.
- High-cardinality labels are the usual cause of runaway memory use, and one badly labelled metric can destabilise the whole server.
- Configuration is reloaded on signal or by endpoint rather than automatically, so an edited file has no effect until the reload is triggered.
- Prometheus does not send notifications itself; rules only produce alerts, and delivery requires Alertmanager configured separately.