Resources

Video: Introduction to Critical Path Monitoring

 

Here's a short video that introduces the SAS Critical Path Monitoring tool.

We offer Critical Path Monitoring to IT Managed Service customers who want to manage the performance of their critical applications.  If you're a new customer, new to this service or just curious about how SAS services work, this video will give you a heads-up. Enjoy!

 

 

Here's the transcript...

Hi, I’m Greg Duffy from SAS.

I’d like to introduce you to the Critical Path Monitoring tool within the SAS Unified Dashboard.

Critical Path Monitoring aims to overcome the problem, that with application performance, sometimes we can be overwhelmed with data, but we can’t see how it relates to the performance of the application. 

Critical Path Monitoring involves monitoring of all the devices and application components along the IP path of the application. 

It provides a traffic light to alert you to the overall health of each application, and it allows drill-down into a topology map that we dynamically colour, so that you can quickly see where problems lie. 

You can see here the SAS Unified Dashboard.   

Now, if you have asked us to monitor one or more of your critical applications, you will see them listed on the left hand side within the ‘Critical Applications’ box.

Generally, the health and performance of each application will be summarised into one of three states:

Green – which indicates all good

Amber – which indicates a warning

Red – which indicates a critical problem

As you can see here, there is a warning on the Exchange platform.

Generally, on the Unified Dashboard, you can drill-down to further detail by clicking on an item of interest. In this case, let’s click on the Exchange traffic light to see what’s going on.

We can now see a topology map of the Exchange environment and its IP path. This map shows us several things:

First, we see that we have a Microsoft Exchange application. And we can see from its amber colour that there is a problem with it.

Next, we can see that the application is hosted on a server, called Server 117. And we can see from the fact that it’s shown in green, that the server is healthy and performing well.

The server is connected to a switch, which in turn is connected to a stack switch in our disaster recovery site at Redhill Data Centre. 

That switch is then connected to a further server (Server 317), and finally the backup Exchange Application.

The two horizontal lines represent LAN cabling. If you pulled a LAN cable out, the relevant link would appear red on this map.  The vertical line represents an SHDS, or Short Haul Data Services circuit, which is a point to point fibre Ethernet circuit. It that link went down then the line would go red.  

Now, in our case, we’re using an SHDS circuit because the two sites are within the range limit for a point to point circuit….Typically 35km. 

In many cases, the sites won’t be that close, in which case this topology map would also be showing the wide area network …perhaps a pair of routers and a WAN circuit.

So let’s click on this amber application to find out what’s happening.

We can see here, more detailed information about the Exchange Application. To start with, the status is showing as a Warning.

Now, no applications were harmed in making this video. We’ve engineered the warning by changing the thresholds.

So let’s scroll down the page to see where the error is. 

And here it is. The threshold for failures in Remote Procedure Call requests has been breached.

Incidentally, these measures that we’re looking at are called ‘Performance Counters’. Let’s drill down further into this one.

Here we can see the performance counter for failed RPC requests in more detail. It’s immediately clear from the chart in the middle of the screen that the failure rate has breached the critical threshold…remembering, of course, what we’ve artificially lowered that threshold for this demo.

If we look a little higher, we can see a panel labelled ‘Expert Knowledge’. This provides insight into the nature of the issue, the likely causes, and potential remediations, or fixes.

So you might next open a ticket, which would show up on the Unified Dashboard. Actually, in reality, our proactive monitoring spots 95% of problems and raises the ticket for you.

If you had asked us to be the Resolver group for Exchange then our qualified Exchange expert would investigate and resolve the issue. Or alternatively, if you were the resolver group, and let’s say you were troubleshooting a database issue, you might call in one of our DBAs to assist.

 

Thanks for watching!

Now that you've seen this video, you may like to download our Application Performance brochure here >   

Get my free brochure

Can we help?