Cloud Parts

Prometheus

The standard open-source metrics system: it pulls numbers from your services over HTTP, stores them as labelled time series and alerts on PromQL queries.

What it is
Metrics,Time-series databases
Used for
Alerting,Observability
Type
Open source
Made by
Cloud Native Computing Foundation
License
Apache 2.0
Facts checked
5 October 2026
Website Source code

What it is

Most metrics systems wait for apps to push data to them. Prometheus does the opposite: every scrape interval (one minute by default, often set to 15 seconds) it sends an HTTP request to each target’s /metrics endpoint, which answers with the current values as plain text. Targets come from service discovery, such as the Kubernetes API, cloud APIs, DNS or a file, so new pods are picked up without config changes. Because Prometheus does the asking, it notices when a target stops answering: the built-in up series drops to 0.

Each series is a metric name plus labels, such as http_requests_total{route="/login", status="500"}, kept in a local time-series database on disk. You query it with PromQL, and alerting rules are PromQL expressions evaluated on a schedule; firing alerts go to the separate Alertmanager, which groups them and routes them to email, Slack or a pager. Prometheus started at SoundCloud in 2012 and graduated from the CNCF in 2018. Prometheus 3.0, released in November 2024, added a new UI, UTF-8 metric names and a built-in receiver for OpenTelemetry’s OTLP.

Why teams pick it

  • Service discovery finds and scrapes new targets automatically, and a dead target is visible straight away
  • PromQL handles rates, percentiles and label joins in one expression, and Thanos, Grafana Mimir and others speak it too
  • One Go binary with no external database to run
  • Kubernetes components and a large ecosystem of exporters already publish metrics in its text format

Watch out for

  • Local storage is neither clustered nor replicated; long retention or high availability needs remote write to Thanos, Mimir or a managed service
  • Default retention is only 15 days
  • Labels with many distinct values (user IDs, request IDs) multiply the number of series and the memory needed
  • Metrics only, and not exact: its own docs say not to use it for per-request billing

Alternatives

What all metrics have in common →
TelegrafOpen sourceInfluxData’s plugin-driven Go agent that collects metrics from systems, services and devices and writes them to InfluxDB, Prometheus, Kafka and hundreds of other targets.

How it fits with other technologies

What uses Prometheus

prometheus.yml: scrape every pod in a Kubernetes cluster · yaml

global:
  scrape_interval: 15s          # the default is 1m
rule_files: [alerts.yml]
alerting:
  alertmanagers:
    - static_configs: [{ targets: ["alertmanager:9093"] }]
scrape_configs:
  - job_name: kubernetes-pods
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_namespace]
        target_label: namespace
# PromQL: sum by (namespace) (rate(http_requests_total{status=~"5.."}[5m]))

See it in a real stack

No architecture uses Prometheus yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2012–2024

In 2012 SoundCloud was breaking its site into services: soon it had hundreds of them, with many thousands of instances started and moved around by its own in-house cluster scheduler, years before Kubernetes. Its monitoring, mostly StatsD and Graphite, had what the team later called “serious limitations”. Metrics were flat dotted names, and there was no clean way to slice them by instance, service or endpoint, or to run monitoring without a central storage backend.

Julius Volz, a former Google site reliability engineer, and Matt T. Proud, another ex-Googler, had both just joined SoundCloud. They took their inspiration from Borgmon, the system Google used to monitor services on its Borg clusters. They started building Prometheus in their free time, brought it into SoundCloud after a couple of months, and then worked on it properly on company time. SoundCloud announced it publicly in January 2015, and in May 2016 it became the second project hosted by the Cloud Native Computing Foundation, after Kubernetes.

Its labelled data and pull model suited containers that come and go. Today Kubernetes components and a large ecosystem of exporters publish metrics in its text format, and long-term stores such as Thanos and Grafana Mimir answer PromQL queries.

Why it’s built this way

Pull metrics over HTTP instead of receiving pushes
The server asks each target for its numbers, so a missing answer immediately shows that a target is down. Anyone can also start an extra Prometheus, even on a laptop, and scrape the same targets without changing them.
Labels instead of dotted metric names
SoundCloud needed to break the same metric down by instance, service, endpoint or method. Key-value labels make every dimension queryable, where a Graphite-style name fixes one hierarchy in advance.
One standalone server with no distributed storage
Each server is a single binary that stores data on its own disk, so you can rely on it when the rest of your infrastructure is broken. The price is that long retention and high availability need extra systems.
Alerts are just queries
Borrowed from Borgmon, which treated time-series data as the source for alerts: an alerting rule is a PromQL expression evaluated on a schedule, so the same language serves graphs and alerts.

Timeline

  1. 2012

    Matt T. Proud and Julius Volz start Prometheus at SoundCloud

  2. 2015

    Announced publicly in January

  3. 2016

    Joins the CNCF as its second project in May; 1.0 in July

  4. 2017

    Prometheus 2.0 ships a rewritten storage engine in November

  5. 2018

    Graduates from the CNCF in August

  6. 2024

    Prometheus 3.0: new UI and native OpenTelemetry (OTLP) ingestion

Sources15 · facts checked 5 October 2026

Improve this page on GitHub