Prometheus
inari.prometheus
A Docker Compose file for Prometheus alone, generated from the catalog and checked by the safety inspector. No account needed.
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.
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.