Prometheus

What Prometheus actually is

Prometheus is an open-source systems monitoring and alerting toolkit built around a time series database, written in Go and licensed under Apache 2.0. It started at SoundCloud in 2012, when the company's StatsD-and-Graphite stack stopped coping with its containerized infrastructure, and its design borrowed a key idea from Google's internal Borgmon: treat time series data as the source for generating alerts, not just for drawing graphs. The project was public from the start but only formally announced in January 2015. It joined the CNCF in May 2016 as the foundation's second project after Kubernetes, and graduated from incubation in August 2018 — the graduation criteria covering governance, adoption, and community health, not marketing spend.

The architecture is deliberately plain. Exporters and client libraries expose metrics on an HTTP endpoint (typically /metrics); the Prometheus server scrapes those endpoints on a schedule over HTTP, stores the samples locally, and evaluates alerting rules against them. Alertmanager takes the firing alerts and handles grouping, deduplication, silencing, and routing to email, Slack, PagerDuty, or whatever receiver you configure. Grafana reads the same data for dashboards. Targets come from static configuration or service discovery — Kubernetes, Consul, and friends — which is what makes the system tolerable at container scale, where hand-maintaining a target list is a losing game.

The data model is the part worth understanding before you commit. Every time series is identified by a metric name plus a set of key-value labels (job, instance, method, status code), so you can slice a single metric along any dimension you chose to record. PromQL queries that model — it supports filtering, aggregation, rate calculations, and arithmetic across series, and it is expressive enough that most "can Prometheus answer this?" questions resolve to "yes, if you instrumented the right labels." That power is also the main foot-gun, which we come back to below.

Other components round out the ecosystem: a Pushgateway for metrics from short-lived or batch jobs that would die before the next scrape, client libraries for the usual languages, and exporters for everything from node hardware to databases to message queues. Notably absent from the core: distributed storage. The project's own overview states "no reliance on distributed storage; single server nodes are autonomous," which is a design stance, not an oversight — but it shapes every operational decision you will make.

Pricing: what you really pay

The license cost is zero and always has been. Apache 2.0, free for commercial use, no per-node or per-metric charge, no registration. For teams watching their observability bill climb with headcount and host count, that is not a rounding difference — it is the entire reason many of them are here.

The real cost is the infrastructure and the operator. Prometheus stores everything on the machine it runs on, so retention is bounded by your disk and your willingness to manage it. The storage docs are refreshingly blunt: use a local filesystem (NFS and non-POSIX filesystems are explicitly unsupported because of corruption risk), and when you cap retention by size, budget it at no more than 80-85% of your allocated disk so compaction always has headroom. Those are numbers from the project's own documentation, and in our view they are the right starting point — a Prometheus server that fills its disk is a monitoring outage at the worst possible time.

The second cost is cardinality. Every unique label combination is a separate time series consuming RAM and disk. A high-cardinality label (user IDs, request IDs, container hashes) can multiply your series count by orders of magnitude, and the bill for that arrives as hardware, not as an invoice line. Our /benchmarks program exists in part so you can pick a server that fits a workload like this; for monitoring stacks we would prioritize disk IOPS and memory headroom over raw vCPU count.

If you want someone else to run it, the managed route exists — Grafana Cloud, Amazon Managed Service for Prometheus, and similar offerings run Prometheus-compatible backends with commercial SLAs. Those are separate products with their own pricing, and they reintroduce exactly the per-series billing that running Prometheus yourself avoids. We would call that the honest trade rather than a contradiction: you are choosing between ops time and metered spend.

Performance & infrastructure

There is no provider network to review here — you bring the hardware, and our standard /benchmarks test results for specific hosts do not apply to software we did not benchmark. What the architecture tells us: scraping is cheap per target and scales horizontally in target count; the limits are single-node write throughput and query cost over long windows. Retention is configurable by time or by size, and the local TSDB uses a write-ahead log (128MB segments per the docs) with periodic compaction into blocks.

For high availability and long-term storage, the ecosystem has standardized on add-ons rather than core features: Prometheus servers run in pairs scraping the same targets (doubling collection, not sharing it), while Thanos, Cortex, or Grafana Mimir handle long retention, global query views, and object-storage-backed history via remote write. This is the one area where "free" becomes "assemble it yourself," and the assembly is non-trivial.

Reliability of the software itself is well established. Ten-plus years in production, a governance model independent of any single vendor, and CNCF graduation status. The security posture is documented with unusual candor: the project's security model states that Prometheus HTTP endpoints should not be exposed to public networks and are easy to overload — there is no built-in exposure-safe posture, so a reverse proxy, network policy, or VPN boundary is your job. We would treat that as trust-building honesty rather than a flaw, but it does mean a naive deployment can leak internal metrics to the internet.

Where it falls short

Long-term storage and horizontal scale are the structural gaps. If you need two years of retention or a single query view across a fleet of Prometheus servers, you are deploying Thanos or Mimir and operating a distributed system after all. The core project's "single nodes are autonomous" stance keeps the base simple and pushes complexity to the edges you add.

Multi-tenancy and access control are effectively absent from the core. Fine for one platform team; a problem when product teams want self-service dashboards without seeing each other's metrics. Authentication and encryption are likewise perimeter concerns per the project's own security guidance.

Cardinality management deserves its own warning paragraph. Nothing in the product stops you from attaching a unique label to millions of series; you find out when scrape cycles stretch and queries time out. Teams new to PromQL also face a real learning curve — rate(), histogram_quantile(), and label joins are powerful and not intuitive on day one. Budget training time.

Finally, support is community-shaped: mailing lists, IRC, GitHub, and a very active contributor base, but no vendor response-time contract attached to the open-source download. Organizations that need a support SLA buy a managed offering or a support vendor — and should plan for that from the start rather than treating it as an upgrade they will never need.

Who should pick this

Our pick for DevOps and platform teams that want the industry-standard metrics stack and are willing to run it. The combination of free licensing, Kubernetes-native service discovery, PromQL, and an exporter ecosystem covering most of the software you already run is why Prometheus is the default answer in this category. If your team already runs Grafana dashboards and Kubernetes, the path of least resistance is also the good one here.

It is a poor fit for teams that need long retention and global queries out of the box (evaluate the Thanos/Mimir family or a managed backend), for multi-tenant organizations that need per-team access control in the monitoring layer, and for anyone who wants a phone number to call when dashboards go blank. Tracing and logs are separate problems — pair with Tempo/Loki or commercial equivalents rather than expecting Prometheus to cover them.

Key takeaways

• Free, Apache 2.0, CNCF-graduated since 2018 — the open-source standard for metrics and alerting, originating at SoundCloud in 2012.
• Pull-based scraping over HTTP with service discovery (Kubernetes, Consul), a multi-dimensional label model, and PromQL on top.
• Local-filesystem TSDB only in the core: NFS is explicitly unsupported, and retention-by-size should be capped at 80-85% of disk per the project's docs.
• Long-term storage and global HA are add-ons (Thanos, Cortex/Mimir) — budget ops effort there, not licensing fees.
• Cost is hardware and operator time: unbounded label cardinality is the classic way this stack gets expensive.
• No built-in auth or public-network safety — the project tells you to keep its endpoints behind a perimeter; support SLAs only come with managed offerings.

Sources

• https://prometheus.io
• https://prometheus.io/docs/introduction/overview/
• https://prometheus.io/docs/prometheus/latest/storage/
• https://prometheus.io/docs/operating/security/
• https://en.wikipedia.org/wiki/Prometheus_(software)
• https://prometheus.io/docs/operating/integrations/
• https://thanos.io/tip/thanos/storage.md/