Prometheus
Also known as: PromQL, Prometheus TSDB, CNCF Prometheus
Prometheus is a monitoring and alerting tool.
It scrapes metrics (CPU usage, request counts, error rates, custom counters) from your services at regular intervals, stores them as time-series data, and lets you query and alert on them. It's the de facto monitoring standard in Kubernetes and cloud-native environments.
Prometheus, explained at three levels
At home
Prometheus is like a health monitor for your software. It regularly asks your servers and apps 'how are you doing?' and records the answers: CPU usage, how many requests per second, error counts. If something looks wrong, it can send an alert.
At work
Prometheus is an open-source monitoring system that regularly collects numeric measurements, called metrics, from servers and applications, stores them with timestamps, and raises alerts when rules are broken. Businesses care because operations teams can see rising error rates, slow responses, or overloaded machines in real time, usually on Grafana dashboards, and fix problems before customers notice. It's free and a standard part of Kubernetes setups.
At home
Prometheus works by 'scraping' HTTP endpoints that expose metrics. Your service runs an HTTP server at `/metrics` that Prometheus polls every 15 seconds. Metrics come in four types: Counter (cumulative count), Gauge (point-in-time value), Histogram (value distributions), and Summary. Alertmanager routes alerts to Slack, PagerDuty, email, etc.
At work
Each Prometheus time series is a metric name plus a set of labels, such as http_requests_total with method='POST' and status='500'. Every unique label combination is stored as its own series. PromQL queries slice these: rate() turns a growing counter into a per-second rate, sum by (status) groups series, and histogram_quantile() estimates percentiles. Recording rules precompute expensive queries, and alerting rules fire once a condition holds for a set duration.
At home
Prometheus pulls: it connects to each target on a schedule, which also tells it when a target is down. Short-lived batch jobs that finish before a scrape push to a Pushgateway instead. Its local time-series database writes incoming samples to a write-ahead log and memory, then flushes two-hour blocks to disk and compacts them into larger ones. In my view, pulling is the right default, but it ties each Prometheus server to the targets it can reach.
At work
At scale, single Prometheus instances struggle with thousands of targets and high cardinality metrics. Thanos or Cortex add global query views, long-term storage in S3, and high availability via multiple Prometheus replicas with deduplication. The OpenMetrics standard (extending Prometheus format) and OTLP (OpenTelemetry Protocol) are increasingly adopted for metric collection alongside Prometheus.
Real-world examples
At home
Marcus set up Prometheus on his home server to monitor CPU, memory, and disk usage across his machines. He queries it with PromQL in Grafana to see which process is spiking his CPU at night.
At work
Nadia's team runs Prometheus on Kubernetes with the kube-state-metrics and node-exporter exporters, giving them metrics on every pod, node, and container. AlertManager fires PagerDuty alerts when any pod restarts more than 5 times in 10 minutes.
Common confusions
- Prometheus stores metrics forever — By default, Prometheus keeps 15 days of data. For long-term retention, teams integrate Thanos, Cortex, or remote write to an external store like Victoria Metrics or Mimir.
- Prometheus and Grafana are the same tool — Prometheus collects and stores metrics; Grafana visualizes them. They're separate tools that work together: Prometheus is the data source, Grafana is the dashboarding layer.
For analysts
Business analysts can query Prometheus metrics through Grafana dashboards to track product KPIs like API response time, error rates, and throughput: without needing access to production logs or databases.
History & origin
Prometheus was built at SoundCloud in 2012, inspired by Google's internal Borgmon monitoring system. SoundCloud open-sourced it in 2015. It joined the CNCF (Cloud Native Computing Foundation) in 2016 and in 2018 became the second project, after Kubernetes, to graduate. Prometheus's pull-based model, multi-dimensional data model, and PromQL query language became the standard for cloud-native observability, spawning an ecosystem of exporters for every service imaginable.