Skip to content

ADR-0014 — Exhibit resource numbers come from Prometheus, not a bespoke agent

  • Status: accepted
  • Date: 2026-07-02
  • Domain: observability · reuse

Context

Exhibit 01's cost side needs per-container CPU and memory for the poller vs the streamer, rendered on the public page. Options range from reading cgroup files inside each container, to docker stats via the socket proxy, to querying the monitoring stack the lab already runs (CP5: Prometheus scraping cAdvisor).

Decision

lab-api queries the Prometheus HTTP API over the internal Docker network for the two containers' CPU/memory series and forwards the current values in the metrics response. Prometheus stays internal-only (no Traefik labels); the public page sees numbers, never the metrics endpoint. Fields are nullable in the contract — if Prometheus is briefly unavailable, the exhibit renders — and the freshness comparison still works.

Consequences

  • Zero new agents, zero new privileges: cAdvisor already collects this; the exhibit reuses the CP5 investment, which is itself the story ("the monitoring stack is load-bearing, not decorative").
  • One query hop per metrics poll — bounded by the page's polling cadence, negligible load.
  • The same figures shown to a recruiter on the page are inspectable in Grafana, closing another claim-to-evidence loop.

Alternatives considered

  • docker stats via socket proxy from lab-api — rejected: extends Docker-API reach to a public-facing service; CP8 exists to prevent exactly this.
  • Self-reporting from inside each container (cgroup reads) — rejected: per-service code for data the platform already has; another thing to test and to drift.