Prometheus is an open-source monitoring and alerting toolkit that has become the standard for cloud-native observability. Per CNCF (Cloud Native Computing Foundation), Prometheus is a graduated project alongside Kubernetes. It collects time-series metrics from targets via a pull model (HTTP scraping), stores them in a custom time-series database, and evaluates alerting rules using its query language, PromQL.
Key takeaways
- Prometheus is a CNCF graduated project for metrics monitoring and alerting.
- Pull-based: scrapes /metrics HTTP endpoints on a schedule.
- PromQL: powerful query language for time-series analysis and alerting rules.
- Kubernetes-native with built-in service discovery.
- Pair with Grafana for dashboards and Alertmanager for notifications.
Quick explanation
In simple terms
Prometheus is an open-source tool that monitors computer systems by collecting performance data (CPU, memory, request rates) and sending alerts when something goes wrong.
Technical definition
Prometheus is a CNCF graduated monitoring system that implements pull-based metric collection via HTTP, stores time-series data in a custom TSDB with a multi-dimensional data model (metric name + labels), queries via PromQL, and fires alerts through Alertmanager.
Analogy
Prometheus is like a health inspector who visits restaurants (services) on a regular schedule, checks vital signs (metrics), writes them in a logbook (TSDB), and calls the health department (Alertmanager) if something is wrong.
Definition
Prometheus is an open-source monitoring and alerting toolkit that collects time-series metrics via HTTP pull, stores them in a custom TSDB, queries them with PromQL, and fires alerts through Alertmanager. It's a CNCF graduated project.
Prometheus is an open-source systems monitoring and alerting toolkit originally built at SoundCloud in 2012 and now a CNCF graduated project. Per the official documentation, Prometheus collects metrics from configured targets at given intervals, evaluates rule expressions, displays results, and triggers alerts when conditions are met.
Prometheus uses a pull model: it scrapes HTTP endpoints (/metrics) exposed by applications and exporters. Metrics are stored as time series, identified by metric name and key-value labels. PromQL provides a query language for selecting, aggregating, and computing rates on this data. Alertmanager handles alert routing, deduplication, and notification.
Why it matters
Core concepts
Exporter
A component that exposes metrics in Prometheus format on an HTTP endpoint.
Exporters bridge between existing systems and Prometheus. They collect metrics from the target system and expose them in a text format that Prometheus can scrape. Hundreds of exporters exist for databases (MySQL, PostgreSQL), web servers (nginx, Apache), message queues (RabbitMQ, Kafka), and hardware.
Example
Node Exporter exposes Linux system metrics (CPU, memory, disk, network) on :9100/metrics.
Time series (metric + labels)
A unique combination of metric name and label set that represents a single measurable value over time.
Every metric in Prometheus is a time series identified by a metric name and key-value labels. Labels provide dimensionality: the same metric name can have different series for different instances, methods, or status codes.
Example
http_requests_total{method="GET", handler="/api/v1/query", status="200"} 1234
How it works
Target discovery
Prometheus discovers targets via static configuration or dynamic service discovery (Kubernetes, Consul, DNS). Each target exposes a /metrics HTTP endpoint.
Service discovery → Targets
Metric scraping (pull)
Prometheus sends HTTP GET requests to each target's /metrics endpoint on a configurable interval (default 15 seconds). Targets return metrics in Prometheus text format.
Prometheus → HTTP GET → /metrics
Storage in TSDB
Scraped metrics are stored in Prometheus's built-in time-series database (TSDB) with configurable retention.
TSDB storage
Alerting via PromQL rules
Prometheus evaluates alerting rules (written in PromQL) against stored metrics. Fired alerts are sent to Alertmanager for deduplication, grouping, and routing to Slack, PagerDuty, email, or webhooks.
PromQL rules → Alertmanager
Benefits
Pull-based metric collection
Prometheus scrapes metrics from targets via HTTP. No agents push data; Prometheus pulls on a schedule. This simplifies target configuration and NAT traversal.
PromQL query language
PromQL is a powerful query language for selecting, aggregating, and computing rates on time-series data. It drives both dashboards and alerting rules.
Cloud-native, Kubernetes-native
Per CNCF, Prometheus is a graduated project with wide adoption. It integrates natively with Kubernetes for auto-discovery of pods and services.
Limitations
Metrics only, not logs or traces
MediumPrometheus is designed for metrics (numerical time-series data). It doesn't handle logs or traces. Use Loki for logs and Jaeger/Tempo for traces.
Workaround — Deploy the full observability stack: Prometheus (metrics) + Loki (logs) + Tempo (traces) + Grafana (visualization).
Limited long-term storage by default
MediumBy default, Prometheus stores data locally with limited retention. It's not designed for multi-year metric storage.
Workaround — Use Thanos or Cortex for long-term storage with object storage backends (S3, GCS, Azure Blob).
Examples
Kubernetes cluster monitoring
A DevOps team deploys Prometheus with Grafana to monitor a Kubernetes cluster running 50 microservices.
Prometheus auto-discovers Kubernetes pods with specific annotations, scrapes their /metrics endpoints, and stores the metrics. Grafana dashboards visualize CPU, memory, request rates, and error rates. Alertmanager sends Slack or PagerDuty notifications when thresholds are exceeded.
Comparisons
Prometheus vs. Zabbix
Myths, corrected
Myth
Prometheus replaces all monitoring tools
Correction
Prometheus excels at metrics collection and alerting in cloud-native environments. It doesn't handle logs, traces, SNMP polling, or synthetic monitoring. A complete observability stack combines Prometheus with complementary tools.
Why it happens: Prometheus's popularity in the Kubernetes ecosystem creates the impression it's a complete monitoring solution.
Practical implications
For admins
Deploy kube-prometheus-stack (Helm chart) for a complete Kubernetes monitoring setup: Prometheus, Grafana, Alertmanager, and default dashboards.
For security
Monitor security-relevant metrics: authentication failure rates, certificate expiration, and network connection anomalies.
Related terms
PromQL
Prometheus's query language for selecting and computing on time-series data.
Grafana
An open-source visualization platform commonly paired with Prometheus.
Alertmanager
A Prometheus component that handles alert deduplication, grouping, and routing.
Frequently asked questions
How does Prometheus collect metrics?
Prometheus scrapes (pulls) metrics from targets via HTTP endpoints. This is different from push-based systems (like Graphite or StatsD) where applications push metrics to a collector.
What is PromQL?
PromQL (Prometheus Query Language) is used to query time-series data. Example: rate(http_requests_total[5m]) returns the per-second rate of HTTP requests over the last 5 minutes.
Does Prometheus support long-term storage?
Prometheus stores metrics locally with configurable retention (default 15 days). For long-term storage, use Thanos or Cortex, which extend Prometheus with object storage backends (S3, GCS).
Can Prometheus collect logs?
Prometheus handles metrics (time-series numerical data). For logs, use Loki (from Grafana Labs). For traces, use Jaeger or Tempo. Together, they form the observability stack: metrics, logs, and traces.
Conclusion
Prometheus is the standard monitoring toolkit for cloud-native and Kubernetes environments. It pulls metrics from exporters via HTTP, stores them in a custom TSDB, evaluates alerting rules using PromQL, and fires alerts through Alertmanager.
Per CNCF, Prometheus is a graduated project alongside Kubernetes. For visualization, pair with Grafana. For long-term storage, use Thanos or Cortex.
Main takeaway
