Prometheus Basics

In this guide you’ll learn the fundamentals of Prometheus: what it is, how it collects metrics, where it fits in an observability stack, and a few concrete configuration and exposition examples to get started. Prometheus is an open-source monitoring and alerting toolkit that:

Collects numeric time-series metrics from configured targets.
Stores metrics in a local time-series database (TSDB) optimized for high-write, high-query workloads.
Provides a powerful query language, PromQL, for aggregating and analyzing time-series data.
Integrates with an alerting pipeline (Alertmanager) to route notifications when metrics cross thresholds.

Prometheus uses a pull-based scrape model: it periodically sends HTTP GET requests to configured targets that expose metrics (commonly at the /metrics HTTP path). Scraped samples are persisted in the local TSDB and can be queried with PromQL or visualized in tools like Grafana.

The image provides a description of Prometheus, an open-source monitoring tool that collects metrics data, enables alert generation, scrapes metrics from targets via HTTP, and stores them in a time series database for querying with PromQL.

What you can query with PromQL Prometheus focuses on numeric time-series data. Common queries include rates, aggregates, and quantiles over sliding time windows. Use PromQL to compute things like request rates, error ratios, or p95 latency across services. What kinds of metrics can Prometheus monitor? Prometheus is flexible and commonly collects:

Host and OS metrics: CPU, memory, disk, and network statistics.
Service metrics: uptime, request/sec, error rates, and latency percentiles (p50/p95/p99).
Application/business metrics: exceptions, queue depth, job counts, revenue metrics.

Because Prometheus stores numeric time series, you can compute derivative metrics (e.g., per-second rates), windowed aggregates, and quantiles using PromQL.

The image lists metrics that Prometheus can monitor, including CPU/memory utilization, disk space, service uptime, and application-specific data like exceptions, latency, and pending requests.

Common metric ingestion patterns

Instrument code directly using a Prometheus client library (Go, Java, Python, Ruby, etc.).
Use exporters for systems that cannot be instrumented natively (for example, node_exporter for host metrics, blackbox_exporter for probing endpoints, or database exporters).
Use Pushgateway for short-lived batch jobs that cannot be scraped periodically.

Prometheus is purpose-built for numeric time-series monitoring. It is not a replacement for log management or distributed tracing—use specialized tools for logs/traces and integrate them into your observability pipeline.

The image is an informative slide discussing Prometheus, which monitors numeric time-series data and lists types of data it should not monitor: events, system logs, and traces.

Prometheus includes an Alertmanager component for routing notifications (email, PagerDuty, Slack, etc.). For long-term metric retention beyond Prometheus’ local TSDB retention window, integrate remote storage solutions using Prometheus’ remote_write/remote_read APIs.

Quick example: Prometheus scrape configuration

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']
  - job_name: 'my-app'
    static_configs:
      - targets: ['my-app:8080']

Example: Prometheus text exposition format

# HELP http_requests_total Total number of HTTP requests
# TYPE http_requests_total counter
http_requests_total{method="GET",handler="/api"} 1027

# HELP cpu_seconds_total Total user and system CPU time spent in seconds
# TYPE cpu_seconds_total counter
cpu_seconds_total{cpu="0"} 12345.67

Metric types and when to use them

Metric type	Purpose	Typical use cases
Counter	Monotonically increasing value; only increases (or resets)	Total requests served: `http_requests_total`
Gauge	Value that can go up or down	Current memory usage or temperature
Histogram	Buckets observations and counts/sums for quantiles	Request latency distributions
Summary	Client-side quantiles and counts over sliding time windows	Percentile latency at the client side

Prometheus components at a glance

Component	Role	Notes / Links
Prometheus server	Scrapes targets and stores metrics in the TSDB	Query with PromQL
Alertmanager	Receives alerts from Prometheus and routes notifications	See Alertmanager docs
Exporters	Translate non-Prometheus data into metrics	Examples: `node_exporter`, `blackbox_exporter`
Pushgateway	Accepts push metrics for short-lived jobs	Not intended for service metrics

A few additional technical notes

Service discovery: Prometheus supports multiple discovery mechanisms (Kubernetes, Consul, EC2, DNS) so targets can be discovered dynamically.
Alerting rules: Define rules in Prometheus to evaluate conditions and send alerts to Alertmanager for notification and silencing.
Retention and remote storage: Prometheus’ local TSDB is optimized for recent data. For long-term retention, use compatible remote storage backends via remote_write/remote_read.
Choosing metric types: Use counters for totals, gauges for instantaneous values, histograms/summaries for latency distributions.

Background and further reading Prometheus originated at SoundCloud and joined the Cloud Native Computing Foundation (CNCF) in 2016. It is implemented primarily in Go. For full documentation, client libraries, and exporter examples, see the official Prometheus docs: https://prometheus.io/docs/. Links and references

Introduction

Observability Fundamentals

Prometheus Fundamentals

PromQL

Dashboarding & Visualization

Application Instrumentation

Service Discovery

Push Gateway

Alerting

Monitoring Kubernetes

Conclusion

Scaling & Long Term Storage

Watch Video