Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2021, 15 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Sponsored Session: New Relic - Flexible, Open and Easy Observability for Developers

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Sponsored Session: New Relic - Flexible, Open and Easy Observability for Developers

Speakers: Zain Asgar, Michelle Nguyen

At New Relic, we believe that observability will be open, painless, and a part of every developer’s workflow. Observability should work out-of-the-box, be on by default, and utilize open standards like Open Telemetry. As part of this vision, we are making a bold bet by Open Sourcing Pixie, a Kubernetes native in-cluster observability platform that uses eBPF to automatically capture service level requests and metrics without any manual instrumentation. Furthermore, Pixie includes a fully distributed data system allowing for unsampled visibility into all the data generated by your application. Pixie embraces OpenTelemetry for both ingress and egress, allowing easy vendor-agnostic integration.

A

Hi everyone today we'll talk about flexible, open and easy observability for developers, um I'm zane asgar, I'm the gm and gbp of pxe and open source at new relic, and I was a co-founder and ceo of pixie labs later today, you'll be hearing a demo from michelle and she's a principal engineer in new relic and a founding engineer at pixielabs.

A

So what is the landscape of durability today? uh What we typically are seeing is that software is getting more decoupled and you know this supports the high velocity, agility and scale of modern software development, and this is taking for this taking um various different forms. uh There's a move to multi-cloud, there's standardization around technologies like kubernetes, and that allows like easy deployment of microservices.

A

So these decoupled uh pieces of software are much easier to maintain and scale. However, you know they introduce a new problem right. We need to go analyze all the data that they're generating- and ultimately this turns into this data problem, where you have to wrangle, do data analysis and capture capture all this data in order to manage secure and debug your applications.

A

So where does time get wasted? The first area where time gets wasted is there's this rigid, predetermined data collection pipeline, um the you know the standard way to capture data is either to add a language specific agent or add a bunch of boiler language, specific instrumentation in your code base, and ultimately this actually is interesting, because it leads to the scenario where you end up with a lot more instrumentation code than actual business logic.

A

We aren't saying that manual instrumentation isn't helpful, but there are a lot of cases that can be done automatically, which will allow you to do this without having an instrumented code base and allow you to focus on cases where it is valuable to add manual instrumentation around business, specific use cases.

A

The second place is that you know lots of data gets generated by uh by monitoring back-ends and you can actually capture even more. If you have you know a debug ability like we'll talk about in a few minutes, but most of this data isn't actually actually useful right. um You know most most of the times your application is working as you're expecting, but uh you know there are a few cases like say, like two percent of the time when this data is invaluable and you want to have access to all of it.

A

So you know what if we actually change the way monitoring systems, work and run stuff within the cluster to capture what's interesting and then relay that information to the cloud as necessary.

A

So with that in mind, uh we'll talk about pixi and pixi is a new open source project uh that we're donating to cncf as part of new relic.

A

So um you know, pxe is an instant code, driven debugging um uh debugging observability platform and it sports use cases varying different use cases from apm to info metrics to network performance, monitoring and profiling.

A

And you know it comes like you know, fully fully fledged with a ui, a cli, and you know the complete experience around various different various different use cases. So, what's what's special and unique about about pixi right, so pxe actually moves observability. The entire observability stack really the platform to the edge right. So this allows us to actually run completely within the kubernetes cluster, which reduces the complexity and cost of maintaining the software while giving us a few different benefits.

A

So the first one is that we've moved from having rigid, predetermined manual collection to having like code driven on the fly, no instrumentation based collection, and a lot of this is actually enabled by utilizing new kernel technologies like ebpf, which are supported natively inside of pxe.

A

The second big bucket is that we move from a cloud only to storage and ai machine learning workloads to a system where you actually spread this out between the edge and the cloud. So you can do a lot of the heavy lifting on the edge where you have access to a you know large rich data source figure out what's interesting and then ship the interesting bits and pieces over to the cloud.

A

And, lastly, um you know there's a move away from all the manual and siloed user interfaces to making pixie completely api, driven and easily accessible from various different tools.

A

So you know, pixi does quite a few things. Our core team has actually been pretty focused on on building out what we call this like t, debugging experience where there's this focus on apm for performance debugging.

A

So the goal is once pixie is installed on your kubernetes cluster within you know, within a couple of minutes, you'll actually get access to all the baseline visibility, uh completely agnostic to the language tax and everything used, and you can use this information with you know, especially in certain languages, to actually dig really really deep and actually get code level insights.

A

So if you find out there's a slow request, you can actually go all the way down and figure out where, in the code the slow request is being made and will will help point you in the right direction.

A

Further, there are other use cases like npm build health appsack that are enabled by pixi, but aren't really our current focus right now, but they are being built out by the community by extending our pixel script interface, which is a python dialect for interacting with the pixie database.

A

One thing to keep in mind is that pxe runs entirely within your cluster, so no data actually leaves your cluster, but it does come with a limitation that we access mostly live data uh within the last last day.

A

So you know with that. I wanted to re-emphasize that at new rolex you know we love open source software and we're betting big on open source uh at new rally, both on on pixi and then other open source products that we'll talk about, um but in particular we're donating pixie to cncf to have the ability to make this a core part of the the ecosystem.

A

With that in mind, you know I'd like to hand it off to michelle to do a quick demo of pixi and we can wrap up with some more information.

B

Thanks zane, let's hop right into the demo. We've made pixi easy and painless to deploy to your cluster. You can deploy pixi using our cli, which you can download using the simple bash script that we feature on our main page. There's also other methods that you can use to download the cli. We offer the cli as debian and rpm images, or, if you don't want to deploy through the cli, you can also deploy pixi directly to your cluster, using our yaml or helm charts for the sake of this demo. Let's use our mesh script here.

B

When you run the command, it asks you to accept the terms and conditions. Ask you where you want to install the cli and downloads the cli to your system for you. It will then ask you to authenticate with pixi, and at this point you can create your account with pixi or login.

B

Okay, now that we've logged in let's jump back to the cli, to deploy a pixie to your cluster, all you have to do is run one simple command px deploy. So let's do that right now, pxe is going to run some checks to make sure that can actually deploy to your cluster confirm that this is the cluster that you want to deploy pxe to, and it will automatically start deploying all the resources necessary to start collecting your.

B

B

Within minutes with just one simple command, pixi is now deployed to your cluster and pixi has started automatically collecting data about your cluster pixi uses ebpf to collect telemetry data from the linux kernel level, and that allows us to provide a rich, instant out of the box visibility into your system. So this is just a demo cluster and there's actually nothing deployed. Yet so, let's use the pixi cli to deploy a demo to this.

B

B

So this is just a simple e-commerce application which features 11 micro services, which talk to each other through grpc.

B

So now that's deployed, let's hop into the pixie ui, to see what data we've already started. Collecting.

B

You can see here that, although we just deployed pixi in the demo, application to our cluster pixi has already started collecting a lot of interesting data about the cluster.

B

So if you open our script editor, you can see that the pixie ui is powered by what we call pixel scripts and pixel is our language, which is very similar to python's pandas, and it allows users programmatic access into our data, so they can explore their network, their application and infrastructure data that we've collected.

B

So you can see here. This is our px cluster script, and it gives you an overview into what your cluster looks, like pixi has figured out all the different nodes, namespaces services and pods running on your cluster and also found some interesting metrics about it, such as the cpu usage or information about the requests such as the latency and the throughput.

B

We also saw here at the top of the page that we've generated a service map using the network traffic that we've collected and now you're able to see which of your services talk to which hopping into our pxhtp http data script.

B

You can also see that we're able to collect data about what those requests actually look like using ebpf we're able to collect http, 2 and grpc, basically a lot of different protocols from your cluster, including database traffic, and you can see here that the http data script gives you all of the requests that have been flowing through your cluster because we use eppf and it collects data at the kernel level, we're also able to collect uh traffic that was originally encrypted. So you can see here when you look into this particular request.

B

You can see interesting metrics such as who is the requester the responder, and you can even see the http body if you want pixi also offers what we call deep links so scrolling to the right we see here. We have this blue text deep links. Allow you a way to navigate through our ui and look at specific resources in your cluster. So here you can see this pod column.

B

We want to look into say this cart spot clicking. It will take you to our pod view, which gives you an overview of what this pods health looks like. So here you can see that we've collected network traffic about this particular pod.

B

We've collected cpu, metrics and memory metrics about this particular pod, and this has all been done instantly by deploying pixi to your cluster and you're, able to see a lot of baseline level. Metrics, like we said before, but additionally pxe also offers you code level visibility into your application so scrolling down to the bottom of this pod view we see here, we have a flame graph.

B

Pixi is actually running a profiler on your system and by doing so we're able to generate this flame graph, which tells you in this particular pod how much time you're spending on each function. So the wider the bar is, is the more time that you're that your pod is actually spending executing this function, and that allows you to figure out where your problem spots are. So you can optimize your code and debug.

B

So, as you can see, pixi was quick, easy painless to deploy and right out of the box you're able to get a lot of interesting data about your system. This includes all the baseline level metrics, such as your network data, your infrastructure data, but also you're able to get a deeper look into your application data such as this profiler here all right. So, let's take it back to zane to wrap up this.

A

Talk: okay, thanks for the demo michelle. um The other thing I wanted to mention is you know at pixie we love open, telemetry, uh actually a new relic and, in general, we're betting, really big on open telemetry as the way to interact with various different data collectors.

A

um So with pixi, we support both ingress and egress of open telemetry data, and that means that you can actually collect data from various different sources that support open telemetry, in addition to pixi's native data collectors, but also you can export it to other open telemetry data syncs like new relic, where you can get access to long-term data retention, with pixi and visibility across many different clusters using their very scalable new relic one backend, we'd love for you to check out pixi's, github and um and try out our project, and in addition, you know we have a pretty active slack community that we that would be happy to have more people join.

A

In addition, please check out new relic one which comes with 100 gigabytes of data for free and allows like easy integration with open telemetry uh data sources and other open source projects. Thanks a lot.