Today we extend our appreciation to the teams who created Prometheus, the cloud native monitoring project, and look ahead to reflect on the future of the project.
For a broad history, Prometheus is an open source project that has made significant traction in the cloud native industry and Kubernetes ecosystem. It was started at SoundCloud in 2012 by development teams that needed a tool designed to monitor and provide alerts in microservice infrastructures. Prometheus was inspired by the internal Borgmon monitoring tool at Google, similar to how Kubernetes was inspired by the internal orchestration tool Borg.
Fast forward to 2016, and the project was donated to the Cloud Native Computing Foundation (CNCF) for the benefit of the cloud native community. It reached version 1.0 in 2016, and version 2.0 in 2017.
The CoreOS team, now part of Red Hat, has invested in the project since 2016, and today, we have continued to work with Prometheus through a dedicated team of developers in order to make it consumable for the enterprise. You may recall the dedicated attention the CoreOS team has given the project over the years including upstream development, enabling it in Tectonic, and dedication to the latest v2 release. We have kept up our investment as a key part of the future of cloud native computing with Red Hat OpenShift.
Let’s walk through some of the ways we see Prometheus being very useful today in the Kubernetes ecosystem, and where we see it making an impact moving forward.
Stars are an imperfect metric, but they do give a good coarse grained measurement for the popularity of an open source project. Over the years Prometheus has grown in popularity and this metric reflects that popularity. Within the last two years it grew from 4,000 stars to 18,000 stars on GitHub; even though this is a popularity metric, it does show the rising interest in the project.
Prometheus is easy to set up as a single, statically linked binary that can be downloaded and started with a single command. In tandem with this simplicity, it scales to hundreds of thousands of samples per second ingested on modern commodity hardware. Prometheus’ architecture is well suited for dynamic environments in which containers start and stop frequently, instead of requiring manual re-configuration. We specifically re-implemented the time-series database to accommodate high churn use cases with short lived time-series, while retaining and improving query latency and resource usage.
Nearly as important as the software itself is Prometheus’ low barrier to entry into monitoring, helping to define a new era of monitoring culture. Multiple books have been written by both users as well as maintainers of Prometheus highlighting this shift towards usability, and even the new Google SRE workbook uses Prometheus in its example queries and alerts.
Moving forward, Prometheus is poised to continue widespread community development as well as at Red Hat as we seek to bring enhanced container monitoring capabilities to more users. Looking at the Kubernetes and OpenShift ecosystem, we believe Prometheus is already the de facto default solution to perform monitoring. Standardizing the efforts that have made Prometheus successful, such as the metrics format formalized through the OpenMetrics project, highlights the importance of this project in the industry.
Going forward, we believe that this standardization will be key for organizations as they seek to develop the next generation of operational tooling and culture - the bulk of which will be likely driven by Prometheus.