The third use case here is around our SQL-Server workloads and in workloads in general. So earlier we were talking about and this, it is probably the most common thing that we see is you’re in Azure Cloud, you’re using as you’re using as your cloud provider, and you’re using some different services. But, you’re running things on top of those services and you don’t have any visibility into those services. So I took a number of examples there, starting with our SQL-server dashboards. We do have a number of different SQL-server dashboards that are available, but I think this workload one shows something that the rest of them don’t. This is something that I haven’t had a chance to talk about deeply yet. We’ll look at things, again, like CPU utilization, memory utilization on these SQL server instances. What’s IOPs looking like on these different databases that I’m monitoring. But then we’ll also relate it to the virtual machine. So this is something that we haven’t got into much detail yet here, so these are virtual machines just related to our SQL instances. Here we can see things like CPU. What is our CPU looking like, what’s our memory, what’s our total network looking like. We’re only showing the virtual machines that are related to our SQL Server instances here. For example, we have 3 SQL Server instances, only one of them here is necessarily running inside our Azure environment, and that Azure one is running on in Azure VM. We’re pulling some of those Azure VM metrics to show CPU ready, memory and network. And the way we do this is by using something we call relationships.
Automatically BindPlane will find these relationships and putting that into Microsoft Azure, where one service is relating to another service. If you’re running an Oracle database inside of VMware it’s going to find that that database, which VM that database is running on. Another example might be if you’re running a Tomcat server, web server, inside of a Hyper-v. It’s going to, again, make that relationship. So we do that even in hardware, like in a FlexPod environmental. We’ll find all those different hardware pieces and create that relationship together, but it doesn’t end there. The example I’m looking at today, we’re not only doing it between our own software but between your Azure resources you’re looking at here as well.
As I mentioned, one of these databases is running inside our Azure environment and that’s how we’re getting these related Azure piece of the metrics. This is important because it allows us to see we have an issue with our database, and we look at our database metrics and see everything is fine, sometimes it can be the underlying infrastructure it’s running on whether that in the cloud or on-prem or in our private clouds. We want to be able to see these pieces of data together, so that when you’re trying to troubleshoot you’re not running blindly and trying to figure out what’s going on because all of the metrics look good. Sometimes it can be that next level. So with this, we’re able to combine these dashboards and be able to troubleshoot things like that.