Prometheus

Key features

• Pull-based scraping with service discovery Prometheus scrapes metric endpoints over HTTP on a configured interval and discovers Kubernetes pods and other cloud resources continuously, so ephemeral targets stay covered without static target lists.[1][2]

• PromQL query language PromQL queries, correlates, and transforms time-series data for visualizations and alerts, using labels to filter, group, and match series such as error counts broken down by method and status code.[1][2]

• Alerting rules with Alertmanager Alerting rules written in PromQL are evaluated inside the server, and the separate Alertmanager component handles notification delivery and silencing so the core loop stays focused on evaluation.[1][2]

• Dimensional data model Every series is identified by a metric name plus key-value labels, an explicit model that replaces implicit dot-separated naming and keeps drill-downs from an aggregate to a single failing instance.[1][2]

• Client libraries for major languages Official and community-contributed instrumentation libraries cover most major languages, so teams emit whitebox metrics from inside their own services.[1]

• Exporter ecosystem Hundreds of official and community-contributed exporters and integrations extract metrics from existing systems such as databases, hardware, and queues that cannot be re-instrumented.[1]

• Independent single-binary operation Developed in Go as statically linked binaries that are easy to deploy, each server scrapes, evaluates, and alerts from its own local storage with no distributed dependency in the core loop.[1][2]

• Local storage with federation The block-based local TSDB is optimized for monitoring workloads, federation aggregates series upward across servers, and remote read and write APIs connect long-term stores.[1][2]

Who will love it

• Kubernetes platform teams Teams standardizing metrics on Kubernetes get discovery, scraping, alerting, and storage in one Apache-licensed project, with continuous discovery matching exactly how ephemeral container estates change.[1]

• SRE teams writing alert logic Teams that author their own alerting get a real query language behind every alert, expressing burn rates, aggregations, and multi-signal conditions that check-script systems cannot.[1][2]

• Own-infrastructure organizations Organizations that must keep telemetry on their own infrastructure get local storage and independent servers, holding every sample inside infrastructure they control under a permissive license.[1][2]

Who should avoid it

• No query or configuration capacity Teams with nobody to write PromQL and YAML should expect to stall, since every panel and alert rule is written configuration; a product with managed ingestion and point-and-click setup fits better.[1][2]

• Clustered long-term storage needs Estates needing a built-in storage cluster will outgrow single-server retention, because scaling means sharding servers along explicit boundaries such as product, service, or datacenter.[1]

• Event and log-centric observability Buyers centered on events and logs will find the storage model mismatched: the block TSDB targets monitoring series, while hybrid metrics-plus-events pipelines suit stream-oriented tooling.[1]

Alternatives and compatibility