Prometheus: Metrics Collection and Time-Series Database
Last updated on

Prometheus: Metrics Collection and Time-Series Database

Prometheus collects numeric metrics by scraping HTTP endpoints on a schedule, stores them in a purpose-built time-series database, and lets you query them with PromQL.

The pull model

Prometheus fetches metrics rather than receiving them. Targets expose a plain-text metrics endpoint, and Prometheus scrapes it every fifteen seconds or so. This inverts the usual arrangement and has real consequences: targets need no configuration about where to send data, Prometheus knows immediately when a target stops responding, and firewall rules run from Prometheus to targets rather than the reverse.

Exporters do the collecting

Prometheus itself scrapes; exporters produce the metrics. Node Exporter covers Linux host metrics, cAdvisor covers containers, and there are exporters for nearly every database, web server, and network device. Most monitoring setup time goes into deploying exporters rather than configuring Prometheus.

PromQL and alerting

PromQL handles rates, aggregation across labels, and prediction, which is what makes alerts like “disk will be full within four hours at the current rate” expressible. Alerting rules evaluate continuously and fire to Alertmanager, which handles grouping, silencing, and routing to notification channels.

The realistic homelab assessment

Prometheus plus Alertmanager plus exporters plus Grafana is four components before the first graph. It is the right investment if you want real query power and alerting, and considerable overkill if the question is whether a Raspberry Pi is running hot. Beszel, Netdata, or Uptime Kuma answer simpler questions with far less setup.

Storage is local by default and retention is finite; VictoriaMetrics is the common choice for long-term storage at scale.

License

Prometheus is released under the Apache License 2.0.