Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New Relic to open-source Pixie’s eBPF observability platform

blog.pixielabs.ai

Post reply on HN
Print view View original

41–50 of 66 posts

Re: New Relic to open-source Pixie’s eBPF observability platform

#41

Post by jeffbee »

seneca wrote: post #17
morelisp wrote: post #7

Earlier quoted context omitted.

For hardware management maybe but so much of "observability" in general is at the application layer I can't see BPF displacing anything more than a tiny corner of it. On the other hand - it already is overhauling service meshes, VPNs and firewalls and network security policies, etc. The stuff fly.io is debuting now is probably going to be standard in few years.

Strongly disagree. BPF uprobes allow extremely fine grained tracing of userspace applications, and allow you to programmatically correlate them with kernel level information.

Sure but it's also terribly expensive. Are you trying to give up 5-10% of your CPU time to observability?

Re: New Relic to open-source Pixie’s eBPF observability platform

#42

Post by 0xEFF »

SEJeff wrote: post #11
throwaway894345 wrote: post #5

Earlier quoted context omitted.

What's the advantage of monitoring from the kernel layer? It's not jumping out at me...

Tracing from user to kernel back to userspace in one single pane of glass. Have you never heard anyone hype about DTrace on Solaris? This allows building similar things on production systems with little to no impact on running production applications.

dtrace has also been on macOS since 10.5, with a pretty nice GUI app as well. I’ve used it to trace ruby and python code to isolate slow API requests from the end user’s perspective.

Re: New Relic to open-source Pixie’s eBPF observability platform

#43

Post by paulie_a »

jeffbee wrote: post #41
seneca wrote: post #17

Earlier quoted context omitted.

Strongly disagree. BPF uprobes allow extremely fine grained tracing of userspace applications, and allow you to programmatically correlate them with kernel level information.

Sure but it's also terribly expensive. Are you trying to give up 5-10% of your CPU time to observability?

Most CPUs are not hitting 100 percent anyways so what's a 10 percent loss?

Re: New Relic to open-source Pixie’s eBPF observability platform

#45

Post by krab »

jeffbee wrote: post #41
seneca wrote: post #17

Earlier quoted context omitted.

Strongly disagree. BPF uprobes allow extremely fine grained tracing of userspace applications, and allow you to programmatically correlate them with kernel level information.

Sure but it's also terribly expensive. Are you trying to give up 5-10% of your CPU time to observability?

Gladly, if it doesn't influence latency much and it is presented intelligently in terms of my high level code.

Re: New Relic to open-source Pixie’s eBPF observability platform

#46

Post by eatmyshorts »

nserrino wrote: post #36
alfanick wrote: post #35

I know what eBPF is, but what is Pixie? A single sentence describing Pixie wouid be useful. In general, academic rule applies: Never write an article without defining terms beforehand.

Engineer from Pixie here. Pixie is an APM tool for Kubernetes leveraging eBPF for automatic data collection. You can use it to monitor and debug your application performance, without code or configuration changes.

You're being too modest. Pixie is a general purpose observability and monitoring tool, with especially strong attributes around APM.

Re: New Relic to open-source Pixie’s eBPF observability platform

#47

Post by colechristensen »

0xEFF wrote: post #42
SEJeff wrote: post #11

Earlier quoted context omitted.

Tracing from user to kernel back to userspace in one single pane of glass. Have you never heard anyone hype about DTrace on Solaris? This allows building similar things on production systems with little to no impact on running production applications.

dtrace has also been on macOS since 10.5, with a pretty nice GUI app as well. I’ve used it to trace ruby and python code to isolate slow API requests from the end user’s perspective.

That sounds really interesting, do you have any references to share about macOS gui dtrace?

Re: New Relic to open-source Pixie’s eBPF observability platform

#48

Post by pstuart »

zasgar wrote: post #6
dan-buzzkill wrote: post #4

Earlier quoted context omitted.

eBPF is great but it only works for linux and access to the kernel layer doesn't work for serverless environments, so it's definitely a piece of the puzzle but not a silver bullet IMO.

Co-founder/CEO of Pixie here. eBPF is indeed a part of the puzzle. It allows us to access telemetry data without any manual instrumentation when running on Linux machines. Pixie itself is extendable and currently ingests data from many other sources as well. Joining forces with New Relic will allow us to focus on expanding the open-source project, but also expand our capabilities by plugging into other open APIs and…

I caught your presentation to GoSF a couple weeks ago -- it was very impressive and I'm looking forward to the opportunity to apply lessons learned from that.

https://github.com/pixie-labs/pixie/tree/main/demos/simple-g...

p.s. The slides would be nice to have too :-)

Re: New Relic to open-source Pixie’s eBPF observability platform

#49

Post by lbotos »

throwaway894345 wrote: post #5
thejonanshow wrote: post #3

I'm curious to hear people's thoughts on eBPF generally, it seems likely that this is where observability companies are headed. It's non-trivial to implement but monitoring from the kernel layer makes so much sense that I expect the tooling will come along quickly.

What's the advantage of monitoring from the kernel layer? It's not jumping out at me...

At GitLab we've built and used strace-parser to help us get to quick and deep debugging, but running strace is EXPENSIVE: https://gitlab.com/gitlab-com/support/toolbox/strace-parser

We've been eagerly awaiting some customers to adopt newer kernels so we can start leveraging eBPF because of the performance gains in these type of scenarios.

Getting down the the kernel often can help find problems with disk access or network issues.

One of our staff engineers is exploring it now for NFS stats: https://gitlab.com/wchandler/tracing-tools/-/blob/master/nfs...

In Support Engineering we often straddle the line of 'SRE style stare at graphs and configuration as code' and 'log on to the box and look at syscalls'. We are very very excited about eBPF.

Re: New Relic to open-source Pixie’s eBPF observability platform

#50

Post by xiphias2 »

yjftsjthsd-h wrote: post #34
xiphias2 wrote: post #26

Earlier quoted context omitted.

Is there any technical reason why it couldn't work with serverless?

Because serverless still needs to run on a machine, and that machine is typically at least one of 1. shared with other users, in which case giving you kernel access would be a security issue, or 2. ephemeral (firecracker VM or such) in which case eBPF is... technically possible, but not nearly as useful (you go from "this server has had X events of type Y over the last 24 hours" to "this VM had X events happen in the…

I see, I thought it could be used for some simple thing, like a load balancer / proxy with a bit of logic in it, but I guess it's too constrainted to do something useful as a server
Post reply on HN