{"id":14056,"date":"2013-01-14T12:45:32","date_gmt":"2013-01-14T12:45:32","guid":{"rendered":"https:\/\/aidanfinn.com\/?p=14056"},"modified":"2013-01-14T12:45:32","modified_gmt":"2013-01-14T12:45:32","slug":"monitor-web-site-health-from-around-the-world-using-system-center-2012-sp1","status":"publish","type":"post","link":"https:\/\/aidanfinn.com\/?p=14056","title":{"rendered":"Monitor Web Site Health From Around The World Using System Center 2012 SP1"},"content":{"rendered":"

When I worked in the VM hosting business, we offered monitoring via System Center Operations Manager as a part of the service.  It was great for us as a service provider because we were aware of everything that was happening.  One of the things I tried to do for customers was website monitoring, using an agent to fire client perspective tests at the customers\u2019 website(s) to see if they were responsive.  On more than one occasion, a customer would upload new code, assume it was OK, and OpsMgr would see the code failure in the form of an offline website.  The customer (and us) got the alerts and they could quickly undo the change.<\/p>\n

When you work in hosting, you learn what a mess the Internet is.  Consider this example.  I worked for a hosting company in Dublin (that\u2019s on the east coast of Ireland).  Our helpdesk got a bunch of calls from customers saying that the services we were providing to them were \u201coffline\u201d.  That sent the networking engineers into a bit of a tizzy \u2013 oh, did I mention this was happening as 99% of the staff were leaving for our Christmas party?  Nice timing!  The strange thing was that not all customers were having a problem.  That suggested a routing issue and the networking folks started making calls.  In the end it turned out that only customers of a certain ISP were affected.  Their route sent packets to a router in Dublin, possibly only a kilometre away from our data centre (almost all of the major datacenters, including the Dublin \u201cAzure\u201d one, are on one glow-in-the-dark road in south-west Dublin).  From there, packets were routed to Germany.  They bounced around there, and normally, came back to Dublin to our data center.  Something went wrong in Germany and packets went in a loop before timing out.  From the customers\u2019 perspective, we were offline.  A simple traceroute<\/em> test would have highlighted the issue but most (not all) hosting customers are \u2026 hmm \u2026 how do I put this? \u2026 special \"Smile\"<\/p>\n

\"image\"<\/a><\/p>\n

Hosting (or as it\u2019s called now, the public cloud) customers typically sell services globally.  They need their product available everywhere.  That means you have routes all over the globe to contend with.  Take the above example, and turn it into a rats nest of ISPs and peering all over the world.  Those global;y available web services are typically not just simple websites placed in a single site, either.  Any service needing a responsive user experience must use content distribution.  That throws another variable into the mix.  Testing the availability of the website from a single location will not do.  You need to test globally.<\/p>\n

Using an older style tool, including client perspective website monitoring in OpsMgr 2007, you could do this by renting VMs in globally located data centres and installing agents on them.  The problems with this are:<\/p>\n