Skip to main content
In this article we explain the Prometheus architecture, how metrics are collected and stored, and how Prometheus integrates with exporters, Pushgateway, service discovery, and Alertmanager. Diagrams are included to show how the components fit together.

​
Core Prometheus server components

The main Prometheus server consists of three internal components:
  • Data retrieval worker: scrapes metrics from targets by making HTTP requests (commonly to the /metrics endpoint).
  • Time Series Database (TSDB): stores collected metrics as time series.
  • HTTP server: exposes APIs to query stored metrics using PromQL and to serve data to visualization tools.
These pieces form the Prometheus server core; the full Prometheus ecosystem also includes exporters, client libraries, Pushgateway, service discovery integrations, and Alertmanager. The diagram below shows the entire system in context.
A Prometheus architecture diagram showing exporters and a Pushgateway feeding into a Prometheus server (retrieval, TSDB, HTTP) with service discovery for Kubernetes and EC2. Alertmanager and the Prometheus web UI are shown with notification integrations (Slack, email, chat).

​
How Prometheus collects metrics

Prometheus collects metrics by scraping configured targets. Each scrape is an HTTP GET to a target endpoint — the default path is /metrics, but you can configure a different path per target in prometheus.yml. Example scrape_config (YAML):
Prometheus executes PromQL queries against the TSDB via its HTTP API and built-in web UI. For dashboards and long-term visualization, Grafana is commonly used to query Prometheus. See the Prometheus HTTP API docs for query examples: https://prometheus.io/docs/prometheus/latest/querying/api/

​
Exporters

Exporters translate system, service, or application data into the Prometheus exposition format and expose it on an HTTP endpoint for Prometheus to scrape. Many systems do not natively expose metrics, so exporters act as adapters.
A slide-style diagram titled "Collecting Metrics" showing Prometheus (red flame icon) sending HTTP requests to the /metrics endpoints of multiple target servers. The right side shows stacked server icons labeled /metrics inside a "Targets" box.
Typical exporter workflow:
  • Exporter collects metrics from the target system (OS, database, or application).
  • It exposes metrics on an HTTP endpoint using the Prometheus exposition format.
  • Prometheus scrapes the exporter endpoint and writes the results into the TSDB.
A slide-style diagram titled "Exporters" showing how exporters collect metrics from services and expose them on an HTTP endpoint for Prometheus. It depicts an exporter box in the center with arrows labeled "http request" pointing to server targets on the right.
Common native exporters:
  • Node Exporter — Linux system metrics
  • Windows exporter — Windows system metrics
  • MySQL exporter — MySQL server metrics
  • Apache exporter — Apache HTTP Server metrics
  • HAProxy exporter — HAProxy metrics
A presentation slide titled "Exporters" that says "Prometheus has several native exporters." It lists examples: Node exporters (Linux servers), Windows, MySQL, Apache, and HAProxy.

​
Client libraries

Instrument your applications with Prometheus client libraries to expose custom metrics (error counts, request latency, job durations, etc.). Prometheus provides libraries for multiple languages: Go, Java, Python, Ruby, Rust, and more.
A presentation slide titled "Client libraries" asking "Can we monitor application metrics" and listing examples (number of errors/exceptions, request latency, job execution time). It also notes Prometheus client libraries and language support such as Go, Java, Python, Ruby and Rust.

​
Pull vs. push model

Prometheus uses a pull-based model: it actively scrapes a list of known targets. This has several operational advantages, but there are scenarios where pushing metrics is more appropriate.
A presentation slide titled "Pull Based Model" showing the Prometheus icon pulling metrics from a "target" box with arrows, and text saying Prometheus needs a list of targets it should scrape. It also lists other pull-based monitoring solutions like Zabbix and Nagios.
Other pull-based systems: Zabbix, Nagios. Push-based systems (examples): StatsD/Graphite (in some setups), OpenTSDB.
A slide titled "Push Based Model" showing a diagram where a "Push Based monitoring" box sends data to two "target" boxes, alongside text explaining that targets push metric data to a metrics server and listing pushed-based systems like Logstash, Graphite, and OpenTSDB.
Benefits of pull-based monitoring:
  • Easier detection of target failure (no scrape = target likely down).
  • Avoids traffic storms where many targets concurrently push to a single server.
  • Centralized list of targets simplifies monitoring configuration and control.
A presentation slide titled "Why Pull?" that lists benefits of a pull-based monitoring system. It notes that pull systems make it easier to tell if a target is down, avoid overloads from many incoming push connections, and provide a definitive list of targets.

​
When to use push

Push is appropriate for short-lived or event-driven jobs that might finish before Prometheus scrapes them. For these cases, Prometheus provides Pushgateway.
Pushgateway should only be used for ephemeral batch jobs. It is not a long-term metrics aggregation service. Pushed metrics can become stale and misrepresent current state if used for long-running services.
Short-lived jobs and Pushgateway:
  • Short-lived job pushes metrics to Pushgateway before exiting.
  • Prometheus scrapes the Pushgateway like any other target and captures the metrics.
  • See Prometheus guidance on pushing metrics: https://prometheus.io/docs/practices/pushing/

​
Service discovery

Static target lists are impractical in dynamic environments (Kubernetes, cloud auto-scaling). Prometheus integrates with service discovery mechanisms (Kubernetes, Amazon EC2, Consul, etc.) to automatically discover and update scrape targets. Useful links:

​
Alerting and Alertmanager

Prometheus evaluates alerting rules and generates alerts, but does not send notifications itself. Alerts are sent to Alertmanager, which handles routing, deduplication, grouping, silencing, and delivering notifications (Slack, email, PagerDuty, etc.). Alertmanager docs: https://prometheus.io/docs/alerting/latest/alertmanager/

​
Querying and visualization

  • Query the TSDB with PromQL through the Prometheus HTTP API or the built-in web UI.
  • For dashboards and advanced visualizations, Grafana is the common front-end that queries Prometheus.
Grafana: https://grafana.com/ Grafana Assistant (course reference): https://learn.kodekloud.com/user/courses/grafana-assistant

​
Quick reference tables

​
Summary

  • Prometheus server = scraper + TSDB + HTTP API (PromQL).
  • Exporters and client libraries make systems and applications consumable by Prometheus.
  • Pull model centralizes target management and simplifies failure detection.
  • Pushgateway solves short-lived job scraping gaps — but use it only for ephemeral metrics.
  • Alertmanager handles notification routing and silencing of alerts.
  • Service discovery keeps Prometheus aware of dynamic targets in environments like Kubernetes and cloud providers.
Further reading and references:

Watch Video