While every IT administrator intuitively accepts the idea that monitoring adds the value, the cost of instrumenting and monitoring every application has proven to be prohibitive. As a result, only a small percentage of applications running in the enterprise are monitored. But as IT organizations begin to embrace microservices based on containers, they are discovering that monitoring is indispensable primarily because of all the interdependencies that exist between microservices.
To address that issue, the Cloud Native Computing Foundation (CNCF) embraces an open-source Prometheus container monitoring project. This week the CNCF followed up on that effort with a 2.0 release of Prometheus that employs a new storage engine to improve performance by several orders of magnitude. Next up, the Prometheus team plans to solidify the application programming interface (API) for that storage engine to make Prometheus available as a service that can be called by third-party applications.
Brian Brazil, founder of Robust Perception and one of the original contributors to Prometheus, says Prometheus 2.0 is not only much faster, but it now consumes much less CPU capacity and disk usage.
Other new capabilities include the ability to track stateless events, snapshots that can be used to back up the Prometheus database and a more modern services-oriented approach to monitoring. That latter capability, he says, is critical to help DevOps teams cut through all the alerts that can be issued to focus on issues that specifically impact a specific microservice. Otherwise, Brazil notes that IT administrators will find themselves chasing down events that, by the time they discover their root cause, have either resolved themselves, such as CPU usage rates, or have little to no actual impact on a containerized application or microservice.
Brazil says most of the usage of Prometheus today occurs where container orchestration engines such as Kubernetes and Mesos are deployed. Trying to access Prometheus as a service generally results in too much latency for most DevOps teams to absorb, he notes.
Brazil says he is dubious of any uber-approach to monitoring. It’s simply too difficult to track all the relevant IT events via a single dashboard. Instead, he expects IT organizations to continue to employ a mix of monitoring and log management tools for the foreseeable future. The challenge will be correlating the data generated by those tools to create actionable intelligence.
The issue that many IT organizations will need to come to terms with, he says, is that modern cloud-native applications will require instrumentation by default. An open-source approach to container monitoring provides a mechanism through which that level of instrumentation becomes affordable.
There’s no shortage of options these days when it comes to container monitoring. Some organizations will want to have access to dedicated container monitoring tools. Others may opt for tools that can monitor a broader swath of applications. Regardless of the approach, it’s hard to think of having any level of sophistication when it comes to DevOps that is not grounded in the data generated by monitoring tools.