76 karma · joined December 7, 2015
Pixie will remain licensed under Apache 2.0. We are also working on moving Pixie over to the CNCF, to maintain this guarantee. This is being tracked here: https://github.com/cncf/toc/issues/651
In addition, we will likely move to a DCO (Developer Certificate of Origin). We are still trying to figure out the exact logistics, but this will allow commits to happen without signing a CLA.
Happy to answer any questions here!
Sharing our thoughts on why we are open sourcing Pixie: https://blog.px.dev/open-source-release/.
Too much of open source today is just vendors using it to promote paid services, without a community approach. Open-source should be vendor neutral and accessible to all.
We used Apache 2.0 as our license and are committed to keep it that way. As part of this we are working on contributing the project to CNCF (Cloud native compute foundation, a part of the linux foundation) to guarantee its vendor neutrality.
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/
We are preparing to open source early next year, so stay tuned. The code will be posted on our repository, that currently hosts our community scripts: https://github.com/pixie-labs/pixie.
In the current form Pixie Cloud is required since it's a freemium product.
We are planning to open-source a self-managed version of Pixie early next year, and it can be used completely self-hosted.
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 frameworks such as OpenTelemetry, Grafana, Prometheus.
Thanks for the feedback. In general we try to keep the footprint of services on customer environments small. Since Pixie is mostly an ephemeral system our storage requirements are relatively modest. What this does allow us to do is process enough of the data on the customer machines locally that we only have to send back and store summaries. The long term goal is to build a cloud + edge based system where we can efficiently process data by having data locality.
Kubernetes gives us a substrate where these types of systems are manageable without too many complications. In the longer run we will likely have VPC hosted services as well for people who just don’t want to deal with it.
At Pixie, we are building a new type of data system that can deal with the data volume that we collect and process. We have AI/ML models to help classify traffic and make analysis easier. Over the next few weeks, we will release some blog posts that will discuss how this works.
EBPF allows you to access static tracepoints that are defined in many runtime, and can be used to capture information about the state of the runtime.
Since most VM’s/runtimes allow monkey patching you can usually get to the same level of information without using EBPF. We plan to add support for this in Pixie in the future and provide a seamless experience regardless of what underlying tracing technology is used.
Lots of good stuff from Brendan Gregg here: http://www.brendangregg.com/Slides/Velocity2017_BPF_superpow...