Live data from Hacker News

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

blog.pixielabs.ai

51–60 of 66 posts

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

#51
post #37

Earlier quoted context omitted.

hadn't thought of this like DTrace. Thx for that!

Anytime! eBPF is Linux’s equivalent of DTrace

Strictly speaking, one of the uses of eBPF is a DTrace-like tracing tool but it's also used in quite a few other places (for instance it's also used for devices cgroup policy in cgroupv2).

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

#52
post #49

Earlier quoted context omitted.

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 ne…

Take a look at Pixie dynamic logging [1].

Deploys eBPF kprobes (based on bpftrace) and uprobe (based a custom front-end language) and instantly get rich data (arts, return value, latency), query data in a Pandas-like scripting language and visual dashboard.

[1] https://docs.pixielabs.ai/using-pixie/code-tracing/

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

#53
post #51
post #37

Earlier quoted context omitted.

Anytime! eBPF is Linux’s equivalent of DTrace

Strictly speaking, one of the uses of eBPF is a DTrace-like tracing tool but it's also used in quite a few other places (for instance it's also used for devices cgroup policy in cgroupv2).

And filtering syscalls for seccomp or literally packet filtering. I believe Jens Axboe and team were looking at using eBPF for some of the low level IO subsystems.

But I was explaining the most common and obvious (for a user) use of eBPF.

They should just look at the io visor project to see some of the stuff that can be done with it (disclaimer, I work with one of the io visor maintainers)

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

#54
post #44

For those who want to play with eBPF on kubernetes using an open source tool there is cilium & hubble[1], plug-and-play CNI & Network Observability tool. [1]: https://docs.cilium.io/en/v1.9/intro/

These iovisor guys write some cool stuff that uses bpf, like: https://github.com/iovisor/kubectl-trace

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

#55

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...

It's extremely quick to do it there as well. Originally, bpf was created to replace tcpdump with a quicker less impactful alternative. People saw that it was a pretty neat alternative so they started extending it (the e in eBPF). Think they might have finally come round again and just call it BPF now again.

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

#56
post #12

What does signing a definitive agreement mean?

Pixie agreed to be acquired by NewRelic

Yea, the deal is not yet closed, but assuming no regulatory hold up (think new relic is public, so if pixie is worth enough, they'll need to go through HSR) or similar stuff, they agree that the acquisition will go through.

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

#57
post #48
post #6

Earlier quoted context omitted.

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 :-)

Thanks for attending the talk:

Slides: https://www2.slideshare.net/ZainAsgar/no-instrumentation-gol...

Write up: https://blog.pixielabs.ai/ebpf-http-tracing/ https://blog.pixielabs.ai/ebpf-function-tracing/post/

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

#58

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.

Any plans to bring this to Cloud Foundry?

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

#59

Earlier quoted context omitted.

APM? /s

/s noted (but point also taken). For those unfamiliar: APM = application performance monitoring. Essentially, figuring out why your application is slow or broken.

Couldn't this just be called 'monitoring'?

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

#60
post #6

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…

Hi,

Why do you need the kernel support if you modify the binaries, why not insert a function to write your logs and then insert a call to that function rather than relying on kernel support via an int 3?

Curious really.

Post reply on HN