 Good morning, I'm Bart Robertson. I'm a software engineering manager at Microsoft, and we're here today to talk about the log changes between using the Docker Shum and using container D or cryo as your communities runtime. And I'm Joseph Fultz. I'm one of the engineering leads at Microsoft. And I'm going to open with talking a little bit about our repo. You'll see it posted up there. You can find it with a short link of aka.ms slash fb dash cri. In that repo, you can find some examples and a walkthrough of what we've done. The problem is that when we switched from container, from Docker runtime to container D, the log formats didn't match up. And so we had to do a little work there. And you'll see all that in this repo as well as some additional mappings where we lift values out of Kubernetes and Kubernetes labels. So with that being said, let's take a look at our setup here. On the left, we've got a Docker runtime running. You can see in the terminal window there, there's a describe and you can see it's the Docker runtime version. And in the top window, you see that we've got the parser step as Docker as a configuration for it's pretty bland. There's nothing special there, no rex or anything like that. So let's take a look at how that log output looks as it did initially prior to us changing to container D as a runtime. So if you look at our app, this is the log output from the app. You can see there's a few fields there, dates, task codes, and so forth. And we want to see how that maps out without any other special mappings from the Docker runtime with the Docker parser. So when that gets picked up by Fluentbit, you can see there at the top line, there's the container log. And in fact, there's a log field there to which our information is mapped. You can see it as a string with the different fields differentiated there. And followed by that, you see the stream output type, which is standard out. And then you see the Kubernetes log information, pod name, so on and so forth mapped to there as well. With that being said, I'm gonna hand it over to Bart to walk through what we've done on the cry parser side to get everything matched up and looking good before we add additional lifts and such. Bart? Awesome, thanks Joseph. So the first thing you'll see is that we're running container D as our container runtime. And let's just go ahead and take a look at our logs real quick. And I actually have two instances of Fluentbit running. One that just runs the standard out of the box, exact same configuration that we have on the left side. And the other one that runs, that fixes it. And so the first thing that you'll see is that our log format is a little bit different. And so here we have a log field, but you'll notice that unlike over here where our log field just contains our JSON that was written by our app, we actually have additional fields in here. And so we have the daytime stamp, we have the standard out. This is a full log, which is, this is the log tag field, which is new in the CRI format. And then we have our content. And obviously this doesn't parse. And so our back end parsing system broke because it wasn't getting what it was expecting. And so let me show you how we fix that. It's a really easy fix. But just realize it does break your logs. And so here's our new version that we have a little bit of change to. And you'll notice that now it looks more like this one. So we have the stream just like we do over here. We have this new feature called log tag. And the F just tells you this is a full log. So it's not a multi-line. If it's a multi-line log, this will actually have a different value. And then the logs will be written out on multiple different lines. One of the reasons we chose to log with JSON is to avoid the multi-line logs because it makes parsing so much easier. And then here we're back to our log format and you can see it looks exactly like it does over here. And then here's our Kubernetes map. And so it was really pretty easy to fix this. And so let me just walk you through the two changes that we had to make. So the first thing is you will see these files are pretty much identical with two exceptions. So this input section is where we made our first change. And over here you can see we're using our parser, which is the Docker parser. And this is probably how you have yours configured today if you're using the Docker shim or you're using Docker D as the runtime. The change that we made is we actually use this CRI parser. And this is a new parser that we added. It's available on the FlintBit website. And if you go down to the bottom, you'll see this parser is defined down here. And all it is is a regex that pulls out that time, the stream, the log tag and the log value. And so those are the only two changes that we had to do to make this work. The other thing you'll see is that we have our merge logs turned off right now. If you turn these on, it will lift the individual log item to top level. And you can also lift the Kubernetes to the top level as well. So it's a really simple change, but if you don't make this change, your log processing is most likely going to break because the CRI log format is different than the Docker format. And so with that, that concludes today's Lightning Talk. And thanks for joining us. Thanks everyone.