Prometheus

Visit Website

Introduction

Prometheus, a Cloud Native Computing Foundation project, is a systems and service monitoring system. It collects metrics from configured targets at given intervals, evaluates rule expressions, displays results and can trigger alerts when specified conditions are observed. It is Apache-2.0 with about 67,600 GitHub stars.

The README lists what sets it apart: a multi-dimensional data model (time series identified by metric name and key/value labels), PromQL as a flexible query language, no dependency on distributed storage (single server nodes are autonomous), an HTTP pull model for collection, a push gateway for batch jobs, service discovery or static target configuration, and multiple graphing and dashboarding options.

Prometheus has become the default metrics format for cloud-native software. Many applications expose a /metrics endpoint, and a large ecosystem of exporters covers databases, hosts, queues and hardware.

In the quality loop, Prometheus serves two roles: production monitoring and alerting, and measuring system behaviour during load and chaos tests so you can compare runs against SLOs.

Features

1. Dimensional data model: Labels on every series for flexible slicing.
2. PromQL: Query, aggregate and compute rates and percentiles.
3. Pull-based scraping: Prometheus scrapes HTTP endpoints at intervals.
4. Pushgateway: For short-lived batch jobs.
5. Service discovery: Kubernetes, cloud and file-based discovery, or static config.
6. Alerting rules: Evaluate conditions and send alerts to Alertmanager.
7. Recording rules: Precompute expensive queries.
8. Exporters ecosystem: Exporters for hosts, databases and many services.

Pros

1. Industry standard: Huge ecosystem and community.
2. Free: Apache-2.0, CNCF governance.
3. Powerful queries: PromQL is expressive.
4. Simple to run: Single binary, autonomous nodes.
5. Active: Commits on the day of review.

Cons

1. Long-term storage: Local storage is not designed for very long retention or global views; use Mimir, Thanos or VictoriaMetrics.
2. High cardinality hurts: Too many label combinations strain memory.
3. Metrics only: Logs and traces need other tools.
4. Pull model friction: Some network setups make scraping harder.
5. Basic UI: Most teams add Grafana for dashboards.

Usage and Links (Example)

A minimal prometheus.yml:

global:
  scrape_interval: 15s
scrape_configs:
  - job_name: app
    static_configs:
      - targets: ["app:8080"]

Run it with Docker:

docker run -p 9090:9090 -v $PWD/prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus

Example PromQL for p95 latency from a histogram:

histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

Tips: keep label cardinality under control, alert on symptoms users feel (error rate, latency), and capture metrics during load tests to compare against production baselines.

Resources:

• Prometheus website
• Documentation
• GitHub repository

Pricing

Prometheus is free and open source under Apache-2.0. Managed Prometheus services exist from several vendors; see their sites.

Recommended for?

1. SRE and platform teams running cloud-native systems.
2. Performance testers collecting server metrics during load tests.
3. Teams building SLO alerting.
4. Not a fit on its own for logs, traces or multi-year retention.

Conclusion

Prometheus is the standard for metrics and alerting in cloud-native systems, with PromQL and a vast exporter ecosystem.

Pair it with Grafana for dashboards and a long-term store if you need global views or long retention.