Prometheus & PromQL¶
Once you know metrics are worth collecting, Prometheus is the tool most teams reach for to actually collect and query them. Its defining choice — pulling rather than receiving pushed data — shapes everything else about how it's used.
TL;DR — in 30 seconds:
- Prometheus scrapes each target's
/metricsendpoint on a schedule — it pulls; targets never push anything on their own. - An exporter re-exposes a thing that can't natively speak Prometheus's format (a database, an OS) at
its own
/metricsendpoint. - PromQL queries an instant vector (latest value) or a range vector (a window, e.g.
[5m]) —rate()over a range vector turns it into a per-second average.
1. Pull, not push¶
Prometheus works by scraping: on a fixed interval, it sends an HTTP request to each configured
target's /metrics endpoint and stores whatever time-series data comes back. The target doesn't send
anything anywhere on its own — Prometheus comes and asks.
flowchart LR
T1["Target A<br/>/metrics"] -- "scraped every N seconds" --> P["Prometheus<br/>time-series DB"]
T2["Target B<br/>/metrics"] -- "scraped every N seconds" --> P
T3["Exporter<br/>/metrics"] -- "scraped every N seconds" --> P
This pull model makes it trivial to see whether a target is even reachable (a failed scrape is itself a signal) and keeps every target's exposition format simple: expose plain text at one URL, nothing more.
2. Exporters — for targets that can't expose /metrics natively¶
Not everything can be modified to expose Prometheus's format itself — a database, an operating system, a
piece of third-party software. An exporter is a small standalone process that reads that thing's native
stats and re-exposes them at its own /metrics endpoint, so Prometheus can scrape it like any other target.
3. Metric types¶
Prometheus exposes a handful of metric types, each shaped for a different kind of measurement:
| Type | Behavior | Example |
|---|---|---|
| Counter | Only ever goes up (or resets to 0 on restart) | Total requests served |
| Gauge | Goes up or down freely | Current memory usage |
| Histogram | Buckets observations to derive quantiles/averages | Request latency distribution |
| Summary | Similar to a histogram, quantiles computed client-side | Request latency distribution |
4. PromQL basics¶
PromQL is the query language you run against the data Prometheus has scraped. Two building blocks cover the common case:
- An instant vector selects the latest value of a metric at one point in time (e.g.
http_requests_total). - A range vector selects a metric's values over a time window (e.g.
http_requests_total[5m]), which functions likerate()then turn into a per-second average —rate(http_requests_total[5m])answers "how many requests per second, averaged over the last 5 minutes."
5. How this connects¶
- The metrics Prometheus collects are exactly the pillar named in Three pillars & golden signals — this page is "how metrics actually get collected," not a new concept.
- A PromQL query is what feeds a Grafana panel, covered next in Grafana dashboards, and what an alerting rule evaluates, covered in Alerting, SLOs & error budgets.
You can defend this when you can explain why Prometheus scrapes instead of receiving pushed data, what
an exporter is for, and read a simple rate(metric[5m]) query aloud in plain English.