Hi folks! Éamon here. I’m a recent-ish addition to the Solutions Engineering team and just getting my feet wet on the blogging side so bear with me. :) Back in March, we introduced the Grafana Cloud Agent, a remote_write-focused Prometheus agent. The Grafana Cloud Agent is a subset of Prometheus without any querying or local storage, using the same service discovery, relabeling, WAL, and remote_write code found in Prometheus.
The classic debate when running a software as a service (SaaS) business is between release frequency vs. stability and availability. In other words, are you Team MTTR (mean time to recovery) or Team MTBF (mean time between failure)? In this blog post, I argue for MTTR, which encourages you to push more frequently, embrace the instability this may introduce, and invest in training and tooling to deal with the pursuing outages.
When Kibana 4.0 was created back in 2015, it only had three apps: Dashboard, Visualize, and Discover. Fast forward five years, Kibana now consists of 100+ plugins, millions of lines of code, thousands of dependencies, and dozens of frameworks. The architecture of Kibana that worked well with three apps had become a bottleneck that was hindering Kibana’s stability, scalability, performance, and development velocity.
We’re excited to share more details today about a long-running project that the Kibana team has been working on for the past couple of years: the Kibana development platform.
We all know that Prometheus is a popular system for collecting and querying metrics, especially in the cloud native world of Kubernetes and ephemeral instances. But people forget that Java has been running enterprise software since 1995, while Prometheus is a relative newcomer to the scene. It was only created in 2012! Even though Java has had its own metric collectors since before Prometheus was born, none of our new environments speak its (metric) language. How can you bridge that gap?
