Jay Shaughnessy
Mar 27 · 3 min read

A nice little feature is included in sprint 20 for the Kiali project. Kiali is a project for observing your Istio service mesh on OpenShift or Kubernetes. Kiali is observability for Istio, and we try hard to give you the very best graph visualization of your service topology. The graph helps you confirm that your mesh is behaving well, or to quickly identify areas that may need attention. For example, using the common bookinfo example, we can see below that requests from productpage to the details service are having issues:

Bookinfo Namespace Graph

The red edge indicates failures and the summary panel on the right reflects failures as well. Currently the summary is for the entire bookinfo namespace because we have not selected any graph element. Let’s focus on the problem edge by zooming in and clicking it:

Select the Problem Edge

Now the side panel summarizes the edge from the productpage app to the details service. We pause the graph and see that for the current time period we’re making about 1 request per second and that about 17% of the requests are failing. We can also see that the details service is decorated with an Istio virtual service (the “fork” badge on the node label shows this). But we still don’t know exactly why the requests are failing. To find out we can turn to the new Response Flags tab in the side panel. You’ll notice that there are now two tabs in the edge summary panel: Traffic and Response Codes. The default Traffic tab provides the familiar table and bar chart summary of the request traffic. Now let’s click on the new Response Codes tab:

Response Codes Tab

This new table provides the actual response codes reported for the current time period, broken down by any provided response flags. By hovering we can get a description of the code. We can now see that the failures are being generated by fault injection (FI) due to the virtual service. There are several response flags to help understand your traffic, here are a just a few that can be very useful:

  • DC (downstream connection failure)
  • FI (fault injection)
  • UO (overflow/open circuit breaker)
  • UT (upstream request timeout)

From here we can do more cool stuff, all inside Kiali, like navigate to the service detail, edit the virtual service yaml and change the FI rate, or get lots of more detailed charts about historical performance, etc. We push a new docker release at the end of every sprint, and update the latest tag on every merge to master, so keep an eye out for this new feature.


Service Mesh Observability

Jay Shaughnessy

Written by

Software Developer @ Red Hat located in the greater Philadelphia area.



Service Mesh Observability

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade