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
Operations teams use Prometheus to track the health of their services in real time. Dashboards (usually in Grafana) show whether systems are overloaded, error rates are rising, or latency is increasing -- before users notice.
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
Prometheus uses labels to add dimensions to metrics: `http_requests_total{method='POST', status='500'}`. PromQL (Prometheus Query Language) allows powerful aggregations: rate, sum by label, percentile calculations from histograms. Recording rules pre-compute expensive queries; alerting rules fire when conditions are met for a specified duration.
At home
Prometheus's pull model means it initiates connections to scrape targets. This works well inside a cluster but requires additional components (Pushgateway) for short-lived jobs that can't be scraped. The TSDB (time-series database) uses a local, efficient format with 2-hour blocks compacted into longer chunks.
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 became the second project (after Kubernetes) to graduate from the CNCF (Cloud Native Computing Foundation) in 2016. 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.