 The move from monolith to microservice architecture has greatly increased the volume of inner service traffic. Pixi makes debugging this communication between services easy by providing immediate and deep full body visibility into requests flowing through your cluster. HTTP requests are featured in this tutorial, but Pixi can automatically trace a number of different protocols, including DNS, Postgres SQL, and MySQL. See the video description for the full list of supported protocols. In this video, I'll show you how to use Pixi to inspect full body HTTP requests, see HTTP error rate per service, and error rate per pod. If you're interested in troubleshooting HTTP latency, check out the service performance tutorial next. Installing Pixi takes less than five minutes. You'll also need to install the demo microservices application in order to follow along with this video. You can find directions for both in the tutorial link below. A developer on your team has reported that the demo applications cart service is reporting errors. Let's use Pixi to look at HTTP requests with specific types of errors. I have the live UI open with my cluster selected in the cluster dropdown menu at the top. I'm going to select the script dropdown menu and type the word HTTP, and select the HTTP data filtered script. The HTTP data filtered script shows the most recent HTTP requests in your cluster, filtered by service, pod, request path, and response status code. Select the dropdown arrow next to the status code argument, type 500, and press Enter to rerun the script. This filters the HTTP request to just those with the 500 status code. Select the dropdown arrow next to the service argument, and type px-soc-shop-carts, and press Enter to rerun the script. Pixi displays service names in the UI in the namesplace-service format. So now we've filtered all the HTTP requests flowing through our cluster to just those made by the cart service. For requests with longer message bodies, it's often easier to view the data in JSON form. Click on a table row to see the row data in JSON form. Scroll through the JSON data to find the response body key. We can see that an HTTP post request to the cart service has returned an error with the message cannot find item in cart. Once we have identified a specific error coming from the cart service, we want to go up a level to see how often these errors occur at the service level. Close the sidebar by clicking the row again. Pixi's UI makes it easy to quickly navigate between Kubernetes resources. Clicking on any pod, node, service, or namespace name in the UI will open a script showing a high level overview for that entity. From the service column, click on the px-soc-shop-carts service name. This will open the px-service script with the service argument prefilled with the name of the service that we selected. The service script shows the error rate over time for all inbound HTTP requests. We can see that the cart service has a low but consistent error rate over the selected time window. Scroll down to the inbound traffic by requesting service table. This table shows the services making requests to the cart service. We can see from the error rate column the requests with errors are only coming from the front-end service. If services are backed by multiple pods, it is worth inspecting the individual pods to see if a single pod is the source of the service's errors. Scroll up to the pod list table. In this case, the cart service is backed by a single pod. If the service had multiple pods, they would be listed here. Let's click on the pod name in the pod list table. This will open the pod script with the pod argument prefilled with the name of the pod that we selected. The pod script shows HTTP error rate alongside high-level resource metrics. We can see that there is no resource pressure on this pod and that the HTTP request throughput has been constant over the selected time window. Resolving this bug requires further insight into the application logic. For Go, C, or C++ applications, you might want to try Pixie's continuous profiling feature, seen here at the bottom of the PX pod script. Pixie also offers dynamic logging for Go applications. This video featured HTTP requests. To use Pixie to monitor a different protocol, check out the related script section of the request tracing tutorial linked below.