Exploring Grafana Dashboards

Before we start exploring this specific setup of Grafana and Kiali, there are a couple of things that you should know. First of all, the default setup that we are using is not creating Ingress Gateways for those tools. Typically, you would create them so that there is proper access to those tools through a domain (or a subdomain). But, in the interest of brevity, we are going to skip that. This is not really a course about Istio, nor about monitoring. Instead, we’re going to use the istioctl dashboard grafana command that will create a temporary tunnel through which we’ll be able to access the UI.

Opening up the Grafana dashboard#

So, let’s open the tunnel to the dashboard.

If, in your case, the dashboard doesn’t open automatically, copy the address from the output and paste it into your favorite browser.

You should see the Grafana home page on your screen. Select the dashboards icon from the left-hand menu and select the Manage item. You should see the directory istio. Open it, and you will observe quite a few Istio-specific dashboards available.

Exploring the Istio Mesh dashboard#

Again, we will not go through all the dashboards because monitoring and Istio are not the subjects of this course. Instead, we’ll have a rapid overview of one of the dashboards. Please select the Istio Mesh Dashboard.

What we can see in front of us is a high-level overview of the services controlled by Istio. There aren’t many since we’re running only two applications. The database is excluded since it doesn’t have Istio VirtualService associated with it.

That dashboard provides an overview of some basic metrics. In the top part, we have Global Request Volume, Global Request Rate (non-5xx responses), and so on. Everything seems to be OK. For example, 100% of the requests are successful. More importantly, there is no data for 4xx and 5xx responses. If our application would start generating errors, then we would see data in those boxes. In the bottom part, there is a list of services; go-demo-8 and repeater. They are accompanied by additional information like, for example, latency and success rate.

If there were something wrong with the network traffic, we would like to be able to see that through a dashboard like that one. Actually, we would likely be able to detect other anomalies not directly related to networking. For example, if an application is unavailable, it would not be able to process requests, and that would result in 5xx responses. Quite a few other things can be deduced through networking, no matter whether issues are directly related, or not.

If we’d detect an anomaly, we could select one of those services and gather more information.

I’ll let you explore the dashboards yourself. For our purposes, that main screen on the dashboard should be enough.

In the next lesson, we will be exploring the Kiali dashboards.