Keeping Cloud Service Providers Honest with the Foglight Transaction Recorder

vanillaoliveInternet and Web Development

Nov 3, 2013 (3 years and 7 months ago)

69 views

S


Quest Software,
11/3/2013




1

Internal Partner Win Story


Keeping Cloud Service Providers Honest with the Foglight
Transaction Recorder





Hello Foglight Folks,


I’m Robert Statsinger, one of the Foglight Solution Architects here at Quest Software.
I’d like to talk with you for a few minutes about Cloud Computing and how Quest can
help you monitor Cloud based Services.


I don’t need to tell you how popular Cloud
-
ba
sed services are becoming. Chances are
you probably have at least one Cloud Service Provider (CSP) in your life already; and if
so you’ve probably already come across the question of how to make sure that your
CSPs are providing good service. You may have
Service Level Agreements (SLAs) with
your providers; this becomes especially crucial if you are employing CSPs such as
Amazon Web Services or Google App Engine who are hosting your production
applications for you, because then it’s not just about providing

service to you, but to
your customers as well. But how can you make sure that those SLA’s are being met?


The Foglight Transaction Recorder/Player (FTR in this article) provides the ability to
record transactions against cloud based services. These transa
ctions are saved as
scripts which can then be periodically executed. Each execution of the transaction is
logged, providing detailed response time information, and the information is collected
and aggregated over time to provide a measure of service availa
bility. In this article I
will show you a brief example involving Gmail.



S


Quest Software,
11/3/2013




2

Internal Partner Win Story




The above picture is the starting point in the Transaction Recorder tool. It looks very
much like


and acts very much like


a web browser with a record button. Here I’ve
point
ed FTR at the Gmail login page, where I’ve entered my username and password
(note how FTR acts just like your browser would, masking out sensitive information).
From here I can log in, check my email, and interact with other features provided by
this servi
ce.


S


Quest Software,
11/3/2013




3

Internal Partner Win Story



When I’ve completed the transaction, I can log out, or simply close my browser.
Remember that the point here is to track the availability of the service over time, not
to perform deep functional testing of all of the service’s features, so it’s ok
to keep the
interaction short and simple. Next, FTR allows me to do an initial playback of the script
for baselining purposes. This sets up an initial expected end to end response time of
the transaction. Note that we can re
-
baseline this script at any tim
e or we can add
multipliers or fudge factors to this baseline value, or override it altogether. As the
script plays, the response time of each step is recorded, and at the conclusion of script
execution, the player provides a nice breakdown of the results:



S


Quest Software,
11/3/2013




4

Internal Partner Win Story




Clearly the longest step of this transaction was the lookup of our credentials against
the service’s backend datastore and the retrieval of the information returned as a
result of a successful login, all of which took nearly 12 seconds.


Now I could

use the Windows ‘At’ command or scheduling tools such as CRON for
Windows to execute this transaction on a periodic basis, invisibly, from this machine,
giving me a great feel for Gmail’s availability as seen from this machine’s location. But
what if I wa
nt to monitor Gmail’s availability as seen by users in other locations? To do
that, I can use the Foglight Management Server to distribute this script to other FTR
agents anywhere that Foglight can reach. Bringing the FMS to the party also lets me
monitor
Gmail’s service levels directly from the Foglight dashboards, lets me take
advantage of Foglight’s flexible Services Management framework, and provides alarms
and alerts when there are SLA violations or transaction playback failures.


The
Publish
button on

FTR’s toolbar lets me publish the successfully run transaction


along with the initial timing results and baseline


to the FMS. Then I can simply create
FTR agents in locations from which I want to assess Gmail’s availability. So let’s
assume we have a
local Corporate Office, and a remote field office in Sidney Australia,
where we know we have a lot of people who also need to access Gmail. Our Cloud
Services Management in Foglight might start with a view like this:



S


Quest Software,
11/3/2013




5

Internal Partner Win Story



This view tells me at a glance all

of the locations from which I am monitoring Cloud
Services, the specific service or services monitored from each location, and the status
of the SLA for that service. As we can see we have an issue with Gmail’s response time
as seen from the Sidney locati
on, but the service’s status from our Corporate Office
shows status green. We can drill down on the Gmail Sidney service by clicking on the
Service Name:



S


Quest Software,
11/3/2013




6

Internal Partner Win Story



The first thing we notice is that although the service has been available, Gmail has not
met our
SLA. Our end to end response time has averaged 21.95 seconds while our SLA
as currently set up calls for a 15 second response time for Gmail from Sidney (this is
the baseline expected response time we set up in FTR). Clearly we need to get on the
phone to
the Gmail folks and clarify our Sidney SLA with them. Based on the results of
that conversation, we can modify the expected response time, and we can do this for
each transaction that each FTR agent executes. So we can easily establish individual
SLA’s for

each Cloud Service for each location from which we monitor that service.


Notice as before, the longest leg of this transaction is the hitting of the enter key after
entering our password. Notice also that FTR gives us a breakdown of the response time
com
ponents attributed to the server in the Cloud, the network time, and the client
processing time (which in this case forms the majority of the response time as the
information sent back from the server is collected and assembled in the end user’s
browser).


Now let’s examine our Gmail SLA as seen from our local Corporate Office:


S


Quest Software,
11/3/2013




7

Internal Partner Win Story




Clearly the si
tuation locally is much better. Gmail is meeting the 15 second SLA 100%
of the time with an average response time of 10.92 seconds, and the dominant
component of the response time for the authentication of our credentials is attributed
to network latency.
So Gmail is doing a great job for us locally, while comparatively
speaking, the Internet is not.


Note that we’re able to provide this proactive monitoring of Cloud
-
based service levels
without any access to the cloud resident infrastructure. If you are pa
ying a web service
provider such as Amazon Web Services to rent a portion of their cloud, you might have
such access and if so you could consider instrumenting your cloud
-
resident application
itself with Foglight.


I hope this has given you a feel for how

Foglight can help you keep your CSP’s honest.
Please feel free to post questions about this in the forum.


Regards,


Robert Statsinger