Prometheus Joins the CNCF as Its Second Hosted Project

The Cloud Native Computing Foundation accepted Prometheus as its second hosted project on May 9, 2016 — a significant early signal, less than a year after Kubernetes’ own 1.0 release and CNCF donation, that the CNCF intended to be a home for a broader cloud-native ecosystem rather than a single-project foundation built around Kubernetes alone.

What Prometheus brought to the table

Prometheus is an open-source monitoring and alerting system built specifically around the needs of dynamic, frequently-changing cloud-native environments — integrating naturally with Kubernetes’ own service discovery to monitor workloads that are constantly being scheduled, rescheduled, and scaled, rather than assuming a fixed, unchanging inventory of servers to watch the way older monitoring tools often did.

Its model combines multidimensional time series, pull-based scraping, service discovery, PromQL, recording and alerting rules, and Alertmanager integration. Prometheus deliberately favors reliable local operation and actionable recent data over pretending that one server is an infinitely durable global analytics warehouse. Federation, remote write, and complementary systems address broader retention and scale requirements.

Why being second mattered symbolically

A foundation’s second hosted project says a lot about its intended scope. By choosing an observability tool as the very next project after Kubernetes itself, the CNCF signaled early that monitoring and observability were considered core, foundational concerns of the cloud-native stack — not an afterthought layered on top once orchestration was solved, but a first-class peer concern from nearly the start.

The path to graduation

Prometheus continued through the CNCF’s project maturity levels over the following years, reaching graduated status — the foundation’s highest maturity tier — in August 2018, at the same event where it was noted as joining Kubernetes on the graduation stage, underscoring the pairing between the two projects that had been implicit since Prometheus’s initial acceptance.

Graduation reflected project maturity and adoption under CNCF criteria, not a guarantee that every Prometheus deployment is reliable. Operators still need cardinality controls, retention sizing, persistent storage, high-availability design where required, rule testing, alert ownership, and tested notification paths.

Prometheus shaped cloud-native interfaces

Exporters and applications increasingly exposed Prometheus-style metrics, Kubernetes operators used ServiceMonitor and PrometheusRule custom resources, and projects published dashboards and alerts with their releases. This created a shared operational vocabulary: labels for dimensions, counters for cumulative events, histograms for distributions, and PromQL for rate and aggregation.

The success also created failure modes. Unbounded labels can overwhelm memory and storage; an alert without a runbook or route is not operational readiness; dashboards can hide missing targets. Prometheus made instrumentation accessible, but disciplined metric design and SLO-driven alerting determine whether that instrumentation helps during an incident.

More than the “three pillars” slogan

Metrics, logs, and traces are often called three observability pillars, but Prometheus itself is primarily a metrics and alerting system. It does not automatically make a system observable, and it does not replace logs, profiles, traces, events, or domain knowledge. Its CNCF acceptance mattered because it established a strong, open metrics foundation that other signals could complement.

Why this early pairing shaped the ecosystem’s direction

Prometheus’s central role in what became known as observability’s “three pillars” (metrics, logs, and traces, covered in more depth elsewhere on this blog) traces directly back to this early, deliberate CNCF endorsement — cementing metrics-based monitoring built around Prometheus’s specific data model and query language (PromQL) as the de facto standard approach across the cloud-native ecosystem, well before most competing tools had a chance to establish similar ecosystem-wide reach.

Related:

Sources: