TL;DR: Prometheus is a pull-based monitoring system that collects and stores time-series metrics, while PromQL provides a powerful way to query and analyze those metrics.
Prometheus is an open-source monitoring and alerting system designed around time-series data. The core concept is relatively simple: applications and infrastructure expose metrics, and Prometheus regularly scrapes those metrics and stores them with timestamps and labels.
This makes Prometheus a vital-signs monitor for infrastructure. If Kubernetes is the environment where our workloads live, Prometheus continuously measures what those workloads are doing.
When combined with Backstage, the tools serve distinct yet complementary roles:
- Kubernetes runs the workload.
- Prometheus monitors its vital signs.
- Backstage provides the portal where engineers discover the service and inspect its context.
┌────────────────────────────────────────────────────────┐
│ KUBERNETES CLUSTER │
│ │
│ ┌────────────────────┐ ┌────────────────────┐ │
│ │ User Service │ │ Prometheus │ │
│ │ Pods & Containers │─────►│ Scrapes Metrics │ │
│ └────────────────────┘ └─────────┬──────────┘ │
│ │ │
└─────────────────────────────────────────┼──────────────┘
│
Prometheus API
│
▼
┌────────────────────────────────────────────────────────┐
│ BACKSTAGE PORTAL │
│ │
│ Service Catalog Entry: "User Service" │
│ ├── Owner: Team Alpha │
│ ├── Documentation & Repository │
│ └── Monitoring Information │
│ ├── Kubernetes status │
│ └── Metrics / Alerts from Prometheus │
└────────────────────────────────────────────────────────┘
Kubernetes hosts and executes actual workloads: Pods, Deployments, Containers, and other resources. Prometheus does not manage or control those workloads; instead, it observes them by collecting metrics such as request rates, CPU usage, memory usage, latency, and error counts.
Backstage does not replace Prometheus either. It acts as a developer portal that aggregates information from disparate systems and presents it within the context of a particular service. This separation of responsibilities is fundamental in a platform-engineering environment.
How Prometheus Collects Metrics
The default Prometheus operational model is pull-based. An application exposes a metrics endpoint, commonly at:
GET /metrics
Prometheus periodically sends an HTTP request to that endpoint and collects the exposed metrics. For example:
http_requests_total{method="GET",status="200"} 15234
http_requests_total{method="GET",status="500"} 42
Prometheus attaches timestamps to the samples as they are collected and stores them as time-series data. While Prometheus can accommodate pushed metrics via a Pushgateway in specific architectures, its standard operating model is target auto-discovery and scraping.
Prometheus Data and PromQL
It is important to distinguish the exposition format from the query language:
Exposition Format: The plain-text format used by applications to expose raw metrics.
PromQL (Prometheus Query Language): The functional query language used to calculate, aggregate, and analyze time-series data.
PromQL operates on four main data types:
1. Instant vector: A set of time series containing a single sample for each series at a specific point in time.
2. Range vector: A set of time series containing a range of data points over a specified time window.
3. Scalar: A numeric floating-point value.
4. String: A literal string value (rarely used in PromQL).
PromQL Examples
Calculate the per-second rate of HTTP request growth over the past 5 minutes: rate(http_requests_total[5m])
Calculate the aggregate per-second rate of HTTP 5xx server errors over the past 5 minutes: sum(rate(http_requests_total{status=~"5.."}[5m]))
Prometheus and Kubernetes
Prometheus is particularly well-suited for Kubernetes due to the ephemeral nature of container workloads. Pods are routinely created, destroyed, rescheduled, or scaled horizontally.
Instead of requiring static target configurations, Prometheus uses Kubernetes Service Discovery to dynamically discover scrapable endpoints across the cluster.
Kubernetes
│
├── Applications expose metrics
│
├── Kubernetes / Node system metrics
│
└── Service Discovery
│
▼
Prometheus
│
├── Time-Series Database (TSDB)
├── PromQL Engine
└── Alerting Rules
This pipeline provides platform engineering teams with an updated, real-time view of the operational state of both the cluster and its underlying workloads.
Prometheus and Backstage
This is where the developer portal analogy applies.
The Backstage Software Catalog describes what a service is:
payment-service:
owner: team-payments
repository: [github.com/org/payment-service](https://github.com/org/payment-service)
documentation: techdocs
api: OpenAPI spec
kubernetes: deployment/payment-service
Prometheus describes how a service behaves:
payment-service:
├── Request rate
├── Error rate
├── Latency
├── CPU usage
└── Memory usage
Integrating Backstage with Prometheus surface operational metrics directly on the service page inside the portal. Engineers inspect service status without having to switch contexts or manually locate external dashboards.
Developer Portal (Backstage)
│
"payment-service"
│
┌────────────┼────────────┐
▼ ▼ ▼
Repository Kubernetes Prometheus
│ │ │
Source Runtime Metrics
│
PromQL
Dashboard Component
Application (/metrics) > Prometheus (TSDB) > PromQL (HTTP REST API) > Backstage Plugin > UI Dashboard Component
Back to Certified Cloud Native Platform Engineering Associate Preparation