Earlier quoted context omitted.
hadn't thought of this like DTrace. Thx for that!
Anytime! eBPF is Linux’s equivalent of DTrace
New Relic to open-source Pixie’s eBPF observability platform
51–60 of 66 posts
Re: New Relic to open-source Pixie’s eBPF observability platform
#52Earlier 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…
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.
Re: New Relic to open-source Pixie’s eBPF observability platform
#53Earlier 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).
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
#54For 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/
Re: New Relic to open-source Pixie’s eBPF observability platform
#55I'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...
Re: New Relic to open-source Pixie’s eBPF observability platform
#56What does signing a definitive agreement mean?
Pixie agreed to be acquired by NewRelic
Re: New Relic to open-source Pixie’s eBPF observability platform
#57Earlier 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 :-)
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
#58I 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.
Re: New Relic to open-source Pixie’s eBPF observability platform
#59Re: New Relic to open-source Pixie’s eBPF observability platform
#60Earlier 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…
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.