Testing Windows Azure Web Apps with Synthetic Transactions in SCOM 2007 R2

Synthetic transactions with SCOM are one way you can automate a set of web requests to test various aspects of your Windows Azure web applications. The SCOM 2007 R2 Operations User Guide defines synthetic transactions in the following manner (I mashed up the text below a bit to read better):

“In Operations Manager 2007, synthetic transactions are actions, run in real time, that are performed on monitored objects. You can use synthetic transactions to perform HTTP requests to check availability and to measure performance of a Web page, Web site, or Web application.

For example, for a Web site, you can create a synthetic transaction that performs the actions of a customer connecting to the site and browsing through its pages. For databases, you can create transactions that connect to the database. You can then schedule these actions to occur at regular intervals to see how the database or Web site reacts and to see whether your monitoring settings, such as alerts and notifications, also react as expected.”

This is a powerful feature that should not be overlooked when monitoring your Windows Azure applications with SCOM. In this article, we will walk through a simple scenario of creating a synthetic transaction that records a few web requests. We will then verify operation by looking at the generated events in the Cerebrata™ Azure Diagnostics Manager tool, as well as looking at performance counters in the Operations Console along a short timeline.

To create a synthetic transaction, launch the Operations Console and select the Authoring pane. Select the Web Application node, as seen below. Right-click the node and select the Add Monitoring Wizard… option from the popup menu, as seen below.

You will now see the Add Monitoring Wizard dialog, where you will now select Web Application in the list, and select the Next button.

In the General Properties wizard page, enter a friendly name for your test, a description, and be sure to select your management pack at the bottom. Select the Next button.

Next, you will come to the Web Address wizard page. Here, enter the address of your Windows Azure web application, sans the http(s) protocol suffix. Select the Test button to verify access. The test results will appear immediately below. Everything looks good here, so we will proceed.

In the Choose Watcher Nodes wizard page, you will select the agent managed computers that will access your web application. By default, I just selected the current server as I have a single managed agent computer, but notice that you can have multiple managed agent computers sending load to your web application, which is a very nice feature. Next, I set the synthetic transactions to run every 10 minutes, as seen below. Select the Next button.

In the Summary wizard page, you will see a summary, and will be given the option to record your browser session so you can test desired functionality.

Once you select the Create button, you will be taken to the Web Application Editor. The Web Application Editor allows you to capture navigation through your website, interactively recording a sequence of actions that you take. When you get here, go ahead and delete the web request that it populates, and then select the Start Capture button to capture your sequence of requests.

You will now see the Web Recorder has been launched and the Record button is pressed in the left-hand pane. Go ahead and enter the URL of your web application in the Address box, as SCOM doesn’t do this for you. In the right-hand pane you will then see your Windows Azure web application. The application I’m testing is a variant of the logging sample from Mike Kelly’s great article Take Control of Logging and Tracing in Windows Azure. You can my variant of the sample code at my blog here.

Basically, my actions are to switch to the Event Log page, and then send five events to the event log, as you can see below in the recording. Once done with the recording, I press the Stop button, which will close the recorder and return us to the Web Application Editor.

Now that we’re back at the Web Application Editor, as seen below, we can set flexible criteria that will generate an error or warning health state for each web request. When done setting your criteria for any given request in the list, use the Verify button to verify your criteria first, and if everything checks out, select the Apply button, and then close the editor.

Now you’re back at the Operations Console with your synthetic transaction setup. It may be up to 15-20 minutes before you will be able to see the results of your synthetic transaction.

If you want to make any changes, such as your criteria or the frequency of the transitions, double-click on the synthetic transaction you just created to launch the Web Application Editor again. You can make changes to criteria directly, or, for example, you can launch the Web Application Properties dialog by selecting the Configure settings button in order to modify the frequency of your web requests (as seen below). In this dialog, you can specify performance criteria by transaction response time, and you can even set performance counters to be collected against your web application when requests are sent.

In order to verify that your synthetic transaction is working, you have a number of options. First, you can view the synthetic transactions that monitor Web applications listed in the Web Applications folder of the Monitoring pane, as seen below.

You can use any number of third-party tools that will allow you to view the logs from Windows Azure diagnostics. Below is a screen shot from the Cerebrata™ Azure Diagnostics Manager tool, verifying that I am producing the five events every ten minutes as specified previously in the Web Application Editor.

Next, we will return to the Operations Console to verify that our test application is experiencing the load we are placing on it with the synthetic transaction we created. I selected the ASP.NET Requests/Sec performance counter, which verifies that I have performance “spikes” every ten minutes. This opens up interesting scenarios for load testing and generating alerts based on performance counters.

Hopefully you can see the power in SCOM 2007 R2 to test functionality of your Windows Azure web applications, and measure performance as well with the ability to leverage multiple agent managed computers. One thing I didn’t show is the ability to run the tests manually in the Web Application Editor and see full results of the web requests in a highly detailed manner. This article only scratches the surface, so be sure to dig in and see all of the great functionality that SCOM provides.