Pull-based monitoring isn’t elegant—it’s necessary when your containers vanish faster than your agents can register them.
Prometheus is a pull-based, label-driven time-series monitoring system built by SoundCloud in 2012 to replace StatsD/Graphite for containerised infrastructure. It works well for short-lived services and dimensional querying—but requires operational discipline around scrape targets and lacks native horizontal scaling or logging integration.
Prometheus was built at SoundCloud in 2012 because StatsD and Graphite failed under containerisation.
2:30
How it works
It scrapes metrics over HTTP, stores them in a bespoke database, and queries them with PromQL—all in Go.
4:02
When it shipped
It ran in production at SoundCloud by 2013 and went public in January 2015.
5:28
Where it landed
CNCF adopted it as its second incubated project in May 2016—after Kubernetes.
Worth your time?
Yes. Study the whole thing.
4.5/ 5
What works
HTTP pull scraping
high-cardinality label filtering
real-time alerting with PromQL
production use at SoundCloud by 2013
What does not
replace logging
support horizontal scaling natively
handle distributed tracing
support push-based metrics without adapters
Study it if
teams running containerised microservices
SREs needing label-driven alerting
organisations adopting CNCF toolchains
Skip it if
teams relying on StatsD push patterns
those without Go toolchain familiarity
environments requiring multi-tenant, shared TSDB
The written brief1 min read
What it is and the problem it solves
Prometheus is a free, open-source time-series monitoring and alerting system. It solves SoundCloud’s inability to monitor containerised infrastructure using StatsD and Graphite.
How it works
Prometheus pulls metrics over HTTP. It stores them in its own time-series database. It labels metrics with key-value pairs. It queries them with PromQL. It triggers alerts in real time.
What works
The HTTP pull model works for ephemeral containers. Label-based metrics work for service discovery and multi-tenant filtering. PromQL works for ad hoc slicing across dimensions. The Go implementation works for low-latency ingestion and reliability in production.
What does not
It does not solve distributed tracing. It does not replace logging. It does not scale horizontally out of the box—its storage is single-node. It does not support StatsD-style aggregation natively.
What it changes
It replaces StatsD/Graphite for container-native monitoring. It shifts observability from push to pull. It makes metric dimensionality explicit via labels—not nested hierarchies. It establishes label-based slicing as standard for cloud-native alerting.
Is it worth your time
Yes—if you run containerised infrastructure and need high-dimensional, label-driven monitoring without a central agent push model. No—if your stack relies on push-based metrics or you lack Go tooling expertise.
