New Relic Dives Deeper Into Kubernetes Observability
At the KubeCon + CloudNativeCon Europe 2022 conference, New Relic revealed it has added a more streamlined approach to collecting metrics using the extended Berkeley Packet Filter (eBPF) in the Linux kernel. New Relic is also making a plugin available for the open source Pixie observability platform it previously donated to the Cloud Native Computing Foundation (CNCF).
Other enhancements include reduced memory footprint by avoiding data duplication while scraping kube-state-metrics (KSM) and control plane components, support for control planes such as Rancher Kubernetes Engine, an ability to adjust data ingestion rates, simpler configurations and overall performance improvements to how quickly log data is collected and processes are run.
The Pixie observability platform that New Relic gained with its acquisition of Pixie Labs in 2020 is now directly accessible from the user interface New Relic exposes on its core observability platform. That capability also makes it possible to store a subset of the data Pixie collects within the New Relic software-as-a-service (SaaS) platform.
At the same time, New Relic is also providing access to longer data retention and alerts directly within Pixie to allow for debugging applications in real-time.
New Relic has been making a case for a SaaS platform that unifies observability by aggregating metrics, traces and now log data. Pixie is an observability platform designed primarily for developers who need to debug applications while New Relic’s observability platform is employed primarily by IT operations teams.
Ishan Mukherjee, group vice president for product go-to-market at New Relic, said the overall goal is to shift more observability capabilities further left. This will enable developers to assume more responsibility for managing and maintaining applications after they have been deployed in production environments. Improving the way New Relic collects data from Kubernetes clusters using eBPF furthers that goal by improving the rate at which telemetry data can be consumed.
It’s not clear at what rate IT organizations are embracing Pixie to debug microservices-based applications running on Kubernetes clusters. But as the rate at which these applications are being created continues to increase, there is a clear need for more advanced tools.
Observability, of course, has always been a core tenet of DevOps. However, achieving observability has always been a challenge given that few applications are instrumented and a general lack of integrated access to metrics, traces and log data. The inherent complexity of microservices-based applications is leading to increased reliance on open source agent software for instrumentation which, in turn, makes more data available for observability platforms. It should then become easier for IT teams to query that data to uncover the root cause of any IT issue that might arise.
Competition among providers of observability platforms is, of course, already fierce. In many cases, the ability of the providers to succeed long-term will come down to how much visibility they can provide into Kubernetes environments. After all, it’s the transition to microservices running on Kubernetes clusters that is finally forcing the observability issue.
