CloudReady Web & Network Monitoring

Bringing Crowd Powered™ performance monitoring to
all your cloud apps and services

Earlier this year we launched a new set of sensors that dramatically expand the breadth of cloud apps and services you can monitor with CloudReady^®.  You can read the official announcement here, but in this post I’m going to provide some examples and context for how these new sensors fit in to an overall cloud performance monitoring strategy.

Most CloudReady sensors (e.g.
for Microsoft Exchange Online & SharePoint, Gmail, ADFS, etc.) are application specific.  They are purpose built to transact against specific applications; they know the transaction semantics and syntax for the app, thus eliminating the need for the admin user to script or perform complex training of the sensor.  Usually the only information that’s captured during set-up is an URL and a set of login credentials.  This deployment simplicity is a key feature and we will continue to build these application specific sensors for a wide array of the more complex cloud apps and services.

These new sensors, while still very simple to deploy, are different in that they each support a wide array of apps and services accessible via common IP protocols.  These new sensors include:

• DNS Sensor – Tests DNS response times across multiple entries and locations
• Ping Sensor – Tests and compares server availability across multiple servers
• WGet Sensor – Tests web server responseness across multiple web servers
• WMon Sensor – Tests full web page delivery and rendering for virtually any website

As with all CloudReady sensors these new sensors leverage crowd data to enable IT to compare local performance measurements against the “crowd” – data aggregated across other sensors deployed by that organization, all sensors from all customers in a geographic region, or all globally deployed sensors.  This is useful both for benchmarking as well as detection and isolation of problem areas in the network connection between your locations and the services being monitored.

Broad analysis across multiple sites and access locations

There are a number of ways these new sensors can be used by themselves or in conjunction with our dedicated cloud app sensors.  To give you some ideas, though, here is how we are currently using them in our environment.

Obviously our team wants to make sure the various Exoprise.com websites (www, secure, help, etc.) are accessible globally.  We want to be notified whenever these sites become slow or unavailable and we want to monitor that from multiple locations around the globe.  To do this we leverage the DNS and WGet sensors.  We configured these sensors to test the main Exoprise sites and deployed them to several monitoring locations in North America, Europe, and Asia.

no images were found

Alarms notify us of any availability or performance issues and we can investigate from there.  Alarms indicate the specific exoprise.com site and monitoring location, so we can immediately focus our triage efforts appropriately.

As part of this, one of the first things we look at is the relative performance across all of our monitoring sites.  Here we can start to see if issues are localized to a particular region or are central to the hosted site.  In the example below you can see access times being reported from our Boston location fluctuating significantly (due to some local network configurations that needed to be adjusted).

no images were found

In this case we are monitoring multiple different web sites from each sensor, but you can also configure them to test individual web servers in a farm by point them to specific host URLs, giving you an easy way to detect and analyze issues within a farm you manage.

Deep analysis for critical sites and apps

In addition to our own sites, we also use these sensors to monitor the 3^rd party cloud apps and services that we depend on.  Two of these are Salesforce.com and Expensify.  For these, as well as Exoprise.com, we leverage the WMon sensors.

no images were found

We rely on these apps/sites for daily operations, so we want to have the deeper insight that is provided by the WMon sensor.  As with our app specific sensors, the WMon sensor captures both synthetic transaction data as well as end-to-end network path diagnostics.  We can compare performance trends across specific access locations to help see which of our locations and network configurations perform the best (or worst).  It’s pretty easy for us to quickly determine whether locally observed performance issues are a local problem, a problem with our ISP, or a general problem with Salesforce.com.

no images were found

As with our Email and SharePoint sensors, the WMon sensor also allows the admin to analyze the IP sub-transactions that happen during the full delivery and rendering of the page delivered by the monitored web site.  You’d be surprised how many web services you are waiting on for most sites.  A single slow service can bog down the entire app performance for your users.

no images were found

The Detailed Transaction Timings graphs make it pretty easy to spot the problem services. If it’s a site you control (e.g. a SharePoint site) this information can help you improve performance by restructuring your pages to avoid certain dependencies.  For sites you don’t control, like Salesforce.com or Expensify, this added information can help you get your support incident resolved as quickly as possible, which is the main thing your users care about.

A single pane of glass for your entire cloud app portfolio

With these new sensors CloudReady can provide you with Crowd Powered™ performance and availability insight for nearly every cloud based app and service available.  In less than 5 minutes you begin monitoring the performance you users will experience for the sites and apps you care about most.

If you are already a CloudReady user, you’ll be able to add these sensors in less than a minute.  Couldn’t be much easier.