 Thank you very much for joining this session. And let's get started because it's only five minutes talk. So for this session, we will go over very quickly one of the observability blind spots on the telco edge nodes and how we solve that problem. One quick intro. My name is James Zhang. I'm a software engineer at Red Hat. And currently I'm focused on the telco edge node solution. So when we're working on the telco edge solution, and very often running DBDK application is very common, and we notice a telemetry blind spot when we try to monitor the DBDK workload. So here, for example, this DBDK path is taking 25 gig traffic in and out. But the kernel-based monitoring tool does not give anything, not at all. So it has no visibility to the DBDK traffic. So that's the problem. We try to address. So we have one extra requirement when we try to solve this problem. And we do not want to instrument the DBDK application or change their source code. So our solution is to build a DBDK telemetry agent. So this agent actually leverage the Intel telemetry socket to get the DBDK traffic matrix. And you can follow the link on this page to get more information to see how the Intel telemetry socket works. So but once we have the agent build out, and we're using the agent as a sidecar fashion and run it along with the DBDK application. And so basically, the premises will point the configuration towards the agent service. And the agent will use the premises client API to talk him to the premises. And on the back end, it gets the metric data from the DBDK container. And from the YAML file, you can see that the agent is running as a sidecar in the same part as the DBDK container. So with that, we now have the visibility to the DBDK traffic in our console. But that's not end of the story. So we also wanted to connect into open telemetry. Yeah, so there are two way the agents can connect into an hotel. So the first way is through the premises scripting. So from the agent perspective, so this works just like how to talk into the premises server. So basically, the hotel collector will use the premises as its receiver. And on the collector, you can see that the debug console, we can see the DBDK traffic metrics are collected. So the second approach is through the OTLP. And that's a push model. And basically, the agent will use the OTLP API to push the metrics into the collector. And the collector will use the OTLP as its receiver. And in this picture, in the collected debug console, we can see that the collector actually received the DBDK metrics. So both approach works for us. And this is how we test the agents. So in this diagram, basically, we're using the agent as a sidecar in the same part with the test PMD container. And the traffic jam basically will blast the traffic. And then we can get metrics from the agent and use that information against what we show from the traffic jam. Because traffic jam also report how much traffic is sending and receiving. So we can line the reading. So for more information, please check out our data repository and give us some feedbacks. Thank you very much. And I hope this information is useful. Thank you.