Chapter Three · Prometheus

Prometheus

The observability stack finally lands on obs-01, and its first working tool is Prometheus. This chapter covers the server end to end — the pull model, prometheus.yml, the exporters that translate hosts and stores, service discovery and relabeling, the TSDB on disk, and the scaling ladder — and finishes with the first real telemetry Harborline has ever had: six hosts and three stores reporting every 15 seconds.

6 topics

One docker compose up on obs-01 brings up Prometheus, Grafana, Loki, Tempo, and Alertmanager — but only Prometheus does real work this chapter. node_exporter goes onto all six machines, postgres_exporter onto db-01, redis_exporter onto cache-01, and RabbitMQ's built-in plugin switches on for mq-01. By the last topic, Mara has host- and store-level telemetry for the whole fleet. The five services themselves stay dark; instrumenting them is Chapter 5's job.

Six topics take the server apart: the pull-model architecture and the deliberate list of things Prometheus refuses to do; the one YAML file that declares everything; the exporter ecosystem that translates systems that don't speak Prometheus; service discovery and the relabeling rule language that shapes every target; the TSDB's head-WAL-and-blocks design with its one-line sizing arithmetic; and the scaling ladder, climbed only as far as honesty requires.

The scrape topology — obs-01 pulls /metrics from every target
Prometheus on obs-01 initiates every scrape; targets never push
The scraperobs-01 · Prometheus :9090
App hosts · node_exporterapp-01 :9100app-02 :9100
Data storesdb-01 · postgres_exporter :9187cache-01 · redis_exporter :9121mq-01 · native /metrics :15692
Six hosts and three stores reporting every 15 s — the five services stay dark until Chapter 5.

Topics in This Chapter

Topic 11
The Prometheus Architecture
A single Go binary that scrapes plain text over HTTP and stores it on local disk — no queue, no cluster, no external database. The pull model is the design decision everything else in the chapter follows from.
Architecture
Topic 12
Configuration — prometheus.yml
Everything Prometheus does is declared in prometheus.yml: global defaults, scrape jobs, and the job and instance labels that identify every series from here on. Mara's 20-line first config takes Harborline from zero telemetry to six hosts reporting every 15 seconds.
Configuration
Topic 13
Exporters
Linux, PostgreSQL, and Redis don't speak Prometheus — exporters translate them at scrape time, statelessly, one sidecar per instance. Four of them turn Harborline's hosts and stores into scrape targets, including a few cache-01 series worth filing away.
Exporters
Topic 14
Service Discovery and Relabeling
A static target list drifts from reality the moment infrastructure moves; discovery makes the list a live query, and relabeling shapes what it returns. Includes the three-step relabel that finally makes blackbox_exporter probe instead of idle.
Discovery
Topic 15
TSDB Internals
An in-memory head journaled to a write-ahead log, immutable two-hour blocks behind it — the layout that makes crashes lossless and snapshots nearly free. Plus the one-line sizing arithmetic: Harborline's full 15 days of history fits in about 1.5 GB.
TSDB
Topic 16
Scaling Prometheus
One well-provisioned server carries millions of active series, and most teams never legitimately outgrow it. The escalation ladder — sharding, federation, remote_write, Thanos/Mimir/VictoriaMetrics — surveyed in order, with the case for staying on the first rung.
Scaling