The open-source standard for metrics, in plain English, and where it stops.

If you have ever looked at a graph of your system's CPU or request rate, there is a good chance Prometheus drew it. It is the open-source standard for metrics, and since version 3.0 it speaks OpenTelemetry natively. Here is what it is, and the honest limits.

Prometheus is an open-source monitoring system and time-series database built for metrics: numbers sampled over time, like request rate, error count or memory use. It scrapes those numbers from your services on a schedule, stores them efficiently, and lets you query them with its own language, PromQL. It came out of SoundCloud in 2012, and in 2018 became the second project after Kubernetes to graduate from the CNCF. That lineage is why it is effectively the default for cloud-native metrics.

Worth knowing if your last look was a while ago. Prometheus 3.0, released in November 2024, added native OpenTelemetry ingestion, so applications instrumented with any OTel SDK can push metrics straight to Prometheus with no collector in between, plus UTF-8 support so metric names keep their dots, a faster remote-write protocol, and a new UI. Prometheus and OpenTelemetry now work together rather than around each other.

Ask anyone running Prometheus at scale what actually bit them and you get one answer before all others: cardinality, and the memory wall it drives you into. Each active series costs roughly one to three kilobytes of memory, so a sixteen-gigabyte instance is comfortable at a few million series and struggling well beyond that. The labels that blow the budget are the tempting ones: user IDs, session tokens, raw URL paths, container IDs, commit SHAs. Every unique value is a brand new series.

The quieter trap is churn. Pods that recreate on every deploy, autoscaling, and short-lived jobs all retire old label sets and mint new ones, so your series count climbs even when traffic is flat. And a sharp edge worth knowing: if you ship data to a long-term store with remote-write and that store goes unavailable, each endpoint can consume hundreds of megabytes of memory on its own. None of this is a reason to avoid Prometheus. It is a reason to treat labels as a budget, not a free-text field.

If you run modern infrastructure and you need metrics, the answer is almost certainly yes, and you are probably already using it through something else. Pair it with Grafana for dashboards, mind your cardinality, and reach for Thanos or Mimir when one instance is not enough.

What is the highest-cardinality mistake you have made in Prometheus? I collect these. Reply, or book a slot and tell me what you found.