New Relic at re:Invent—Kubernetes observability use cases

If you missed New Relic’s sponsored Pixie presentation at AWS re:Invent, don’t worry. In this blog, we’ll cover some of the material from the presentation, including how to get past the “what” and uncover the “why” of your Kubernetes-based environment. You can also see a video recording, download a pdf of slides, and find a transcription of the Kubernetes observability use cases presentation, by visiting AWS re:Invent and searching for the presentation name. 

Using the New Relic integration with Pixie to gain visibility into Kubernetes clusters

“New Relic has a really great integration for Pixie," said Natalie Serrino, Principle Software Engineer. "It's a great way to take this data that Pixie is collecting in your Kubernetes cluster and use it as part of your New Relic experience. It can be really hard to get started with all this information, collecting all the telemetry data that we need in order to debug our applications. One cool thing about this integration is in one single Helm command, you can get really good baseline visibility into your Kubernetes cluster.” 

In her presentation, Serrino showed demo applications and data, walking through what you can discover with the Pixie integration with New Relic One. “In my Kubernetes cluster, I can see that we've already detected that there are various services running, and I can see information about that. And it has detected Kubernetes deployments and various Kubernetes pods."

"I have multiple demo applications running on this cluster actually," she continued. "So let's check out a pod for one of my services, the catalog service. After just running one helm command, I can see things like the CPU usage, the memory usage and things like throughput of my requests over time.”

She also discussed a scenario with debugging endpoints. “Another cool thing that it can do is it can actually tell me which of my endpoints are slow, which of my endpoints are being hit the most often," Serrino said. "A lot of times our endpoints have wildcards in the URL parameter, and we automatically collapse these into logical endpoints to make it easier to debug what's going on. Because I think a lot of us have seen that just because your service has a really low latency, it doesn't mean every single endpoint is behaving well.”

For more on what the Pixie integration with New Relic One can do, check out the Auto-telemetry with Pixie page. 

eBPF and Pixie

Omid Azizi, Principal Software Engineer, gave an overview and detailed use cases for eBPF, although we’ll just cover some highlights here. “In the observability world, eBPF is really taking off. It's really a powerful tool," he said. "First of all, I should say that eBPF is a very broad field, and it can be used for various different things. It can be used for observability. It can be used for security. It can be used for networking."

"I'm talking more about it in the context of observability today," Aziz continued. "And in that context, the analogy that I like to use is that it's like an automated debugger."

"So if anyone's ever used a debugger, you set a breakpoint on a certain function. And you say, when I reach this function, stop the execution of the program because I want to poke around and see what's going on, he said explaining that you want to see the value of a particular argument or a variable at that point when you set the breakpoint.

"An eBPF probe, as it's called, is very similar," Aziz said. "You specify a location in the code where you say, I want to put a trace point. So instead of a breakpoint, it's a trace point, but it's analogous. So it's kind of like a script. You say, 'Okay, now that you've reached this point in the code, go and read the argument and store it in a certain location, push it out, and then immediately resume the execution of the program.' This is what eBPF in the Linux kernel lets you do."