Prometheus 3.14: Pull-Based Monitoring with a Query Language That Carries the Load

What Prometheus Actually Solves

Prometheus solves the problem of collecting and querying time series metrics from services and systems that expose them over HTTP. It is for operators who run fleets of servers, containers, or applications and need to answer questions like 'what was the request rate for the last hour' or 'which hosts have high CPU'. The project is a CNCF project, which means it sits in a well-trodden ecosystem of Kubernetes and cloud-native tools. The README is explicit about its distinguishing features: a multi-dimensional data model where each time series is defined by a metric name and key/value labels, a query language called PromQL that exploits that dimensionality, and no dependency on distributed storage. That last point is the core of its identity. Each Prometheus server is autonomous, which simplifies operations but also sets a hard boundary on scale.

The Pull Model and the Gateway for Push

The collection mechanism is an HTTP pull model. Prometheus scrapes metrics from configured targets at regular intervals, rather than waiting for agents to push data. This is a deliberate design choice. The README lists the pull model as a distinguishing feature, and it has consequences. Targets must be reachable from the Prometheus server, which is fine for most data center setups but problematic for ephemeral or firewalled workloads. For batch jobs that finish before a scrape can happen, the project offers an intermediary gateway. The README mentions 'pushing time series is supported via an intermediary gateway for batch jobs', but it does not name the gateway or show its configuration. That is a gap. If you need push-based collection for long-running agents, Prometheus is not the natural fit; you would be fighting the pull model rather than using it.

PromQL: The Query Language as the Main Interface

The query language is PromQL, and the README calls it 'powerful and flexible'. That is promotional language, but the underlying point stands. PromQL lets you select time series by metric name and label matchers, then apply functions, aggregations, and binary operators. The multi-dimensional model means a single query can aggregate across all instances of a service by grouping on labels. The README does not provide examples of PromQL syntax, so I cannot show you a specific query. What is clear is that PromQL is the primary way to interact with the stored data. The evaluation engine runs rule expressions at intervals, and those rules can trigger alerts when conditions are met. That is the whole control loop: scrape, store, evaluate, alert. The power of PromQL is also its cost. Writing efficient queries requires understanding how label matchers map to index lookups, and the documentation on prometheus.io is where you would learn that.

Getting It Running: Binaries, Containers, and Source

Installation has three paths, and the README covers them clearly. Precompiled binaries are the recommended route, available from the download section on prometheus.io. Docker images exist on Quay.io and Docker Hub, and the README gives a one-liner: `docker run --name prometheus -d -p 127.0.0.1:9090:9090 prom/prometheus`. That brings up a server on localhost:9090. Building from source requires Go, NodeJS, and npm. The README warns about a subtlety: if you use `go install`, the binary expects to read web assets from local filesystem directories under `web/ui/static`, and you must run it from the root of the cloned repository. The React UI is not included unless you build it explicitly with `make assets` or `make build`. The `make build` target compiles the web assets into the binary, so the resulting `prometheus` can run from anywhere. The Makefile also offers `test`, `test-short`, `format`, and `vet` targets, which are standard Go project hygiene.

Service Discovery and Build Tags

Service discovery is a first-class feature. The README lists it as one of the distinguishing features, and the project bundles many plugins. You can customize which service discoveries are included using Go build tags. The example in the README shows a `.promu.yml` file with `remove_all_sd` to exclude all optional SDs, then `enable_kubernetes_sd` to re-enable only Kubernetes. The same effect is achievable with `go build -tags "remove_all_sd,enable_kubernetes_sd" ./cmd/prometheus`. The available tags are `remove_all_sd`, which keeps only file_sd, static_sd, and http_sd, and `enable_<name>_sd` for each specific plugin. This is a practical way to shrink the binary and reduce attack surface. But it is a build-time decision. If you change your mind later, you must rebuild and redeploy the binary. That is a maintenance cost that the README does not sugarcoat.

The Library Problem and Remote Write

The README is unusually candid about a limitation: the prometheus/prometheus repository builds a stand-alone program and is not designed for use as a library. The maintainers acknowledge that people do use parts of it as a library, but they state plainly that no care has been taken to make it work well that way. You may encounter errors that only surface when used as a library. This is a genuine constraint. If your plan is to embed Prometheus into your own Go application, you should look at prometheus/client-golang or prometheus/common instead. The README also mentions Remote Write, and the protobuf definitions are published independently on buf.build. You can fetch them with `go get buf.build/gen/go/prometheus/prometheus/protocolbuffers/go@latest`, but the README labels this as experimental. That is a warning. Remote Write is a way to send data to another system, but the experimental label means the API may change.

Operational Trade-Offs and When It Is the Wrong Tool

The single-node autonomy is both a strength and a ceiling. Without distributed storage, a single Prometheus server has finite disk, memory, and CPU. If your metric cardinality grows, or your retention period extends, you will hit a wall. The README does not give numbers for scale limits, so I cannot quantify them. Federation is listed as a feature, and that is the escape hatch for horizontal scaling. You can have hierarchical federation, where a higher-level server scrapes aggregated results from lower-level servers. That is a real mechanism, but it adds operational complexity. The wrong tool cases are clear. If you need to collect metrics from processes that do not expose HTTP endpoints, or from jobs that finish before the next scrape, you need a push gateway or a different system. If you need to store months of high-cardinality data on a single node, Prometheus will force you into federation or a remote storage backend, which is not the default experience.

Maintenance and Upgrade Path

The release cadence is active. The most recent releases are v3.14.0 from August 2026, with a release candidate v3.14.0-rc.0 a week earlier, and v3.13.2 from late July. That is roughly monthly minor releases, which means you should expect regular upgrades. The README does not describe an upgrade procedure, but the existence of release candidates suggests a structured process. The license is Apache-2.0, which is permissive and allows commercial use, modification, and redistribution. The repo is not archived, and the default branch is main, with the last push on 2026-08-18. The maintenance cost is mostly operational: you must keep up with releases, test PromQL changes, and manage storage growth. The build tags for service discovery mean that a security fix in a bundled SD plugin requires a rebuild with your custom tags, which is a small but real burden. The README's warning about out-of-tree plugins, which the project does not endorse, adds another layer of caution if you go that route.

Editorial conclusion

Adopt Prometheus if you need a self-contained monitoring stack that scrapes metrics over HTTP, supports multi-dimensional queries, and can run on a single server without external storage. Skip it if you require native push-based collection for long-lived agents, or if you expect to use the prometheus/prometheus repository as a Go library, since the README explicitly states it is not designed for that. Before adopting, verify that your targets expose metrics over HTTP and that your retention and query load fit within a single node's disk and memory, then test PromQL expressions against your own data to confirm they scale.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes