Prometheus
The CNCF-graduated metrics collection and alerting system built around a pull model and its own query language, PromQL.
Last updated
What it is
Prometheus is an open-source systems monitoring and alerting toolkit originally built at SoundCloud in 2012 and released publicly in 2015. It joined the Cloud Native Computing Foundation in 2016 as the second project accepted (after Kubernetes) and reached the “graduated” maturity tier in 2018, which today remains the strongest signal of long-term viability a CNCF project can carry. Prometheus scrapes metrics from instrumented targets over HTTP on a defined interval (the “pull” model), stores them in its own on-disk time series database, and exposes PromQL, a purpose-built query language, for slicing, aggregating, and alerting on that data. It ships with a built-in Alertmanager for routing and deduplicating alerts, and a service discovery layer that integrates natively with Kubernetes, Consul, and similar systems.
Prometheus is not a single company’s product — it is maintained by a broad community of contributors under CNCF governance, which is part of why its data model (labeled time series) and exposition format have become a de facto standard that most other metrics tools, including commercial ones, know how to ingest or scrape from.
Why teams choose it
- The de facto standard exposition format. Nearly every piece of infrastructure software — databases, load balancers, Kubernetes itself — exposes a
/metricsendpoint in Prometheus format, so adopting Prometheus (or a compatible remote-write target) usually requires zero custom instrumentation for off-the-shelf components. - PromQL is powerful but has a real learning curve. Rate calculations, subqueries, and vector matching are genuinely useful once understood, but new users regularly get tripped up by counter resets,
rate()vsirate(), and label cardinality explosions. - Single-node storage is a deliberate limitation. Vanilla Prometheus is not horizontally scalable or built for long-term retention out of the box — teams needing multi-year retention or global query views typically pair it with Thanos, Cortex, or Grafana Mimir, or migrate to a Prometheus-compatible remote-write backend like VictoriaMetrics.
- Pull-based scraping fits dynamic infrastructure well, since service discovery keeps the scrape target list current as pods and instances come and go, but it’s a poorer fit for short-lived batch jobs or environments where firewalls block inbound scraping (Prometheus offers a Pushgateway as a workaround, with its own caveats).
Pricing model
Prometheus itself is free, open-source software licensed under Apache 2.0, with no paid tier, hosted offering, or company behind it selling support directly. Costs come from self-hosting the infrastructure (compute and storage for the TSDB) and from whichever long-term-storage or scaling layer a team pairs it with, several of which do have commercial or usage-based pricing.
Alternatives
Within the pull-based, PromQL-compatible ecosystem, the main alternatives are VictoriaMetrics and Grafana Mimir, both of which speak the Prometheus data model but add horizontal scalability and longer retention. Outside that ecosystem, InfluxDB offers a different time-series storage and query model, and commercial platforms like Datadog and New Relic provide managed metrics collection without the operational burden of running Prometheus yourself.