Configuring SCOM 2007 R2 Performance Views and Dashboards for Monitoring Azure Applications

In previous blog posts I demonstrated how to setup your Azure performance counters, how to install SCOM 2007 R2 along with the Windows Azure Management Pack, and how to configure Azure Diagnostics performance counter monitoring in SCOM 2007 R2. In this post, I will pick up where I left off to demonstrate how to build customized views that provide tailored, useful views that will help you to quickly visualize and monitor your Azure applications. In the blog post where we created an Azure Management Pack, we would have yielded a SCOM console that looked similar to the screenshot below.

Above, we are looking at all of the performance counters for Windows Azure. In the case above, I am currently only monitoring one Azure application. Yet if there were multiple Azure applications that were being monitored, all of their counters would be shown in the default Windows Azure management pack. This would become unwieldy as well as frustrating very quickly, even when selecting the individual performance views, such as ASP.NET Performance and Processor Performance. The good news is that when we create our own management pack as a management unit, we can create our own performance views and dashboards for as many Azure applications as we desire under their own folders within the management pack. We will walk through that process now, using the management pack that was created in my blog post titled Configuring Azure Diagnostics Performance Counter Monitoring in SCOM 2007 R2 (as seen in the screenshot above, the name is “My Azure Management Pack”). Let’s first begin adding the Alert and State views just as we have in the default Azure management pack.

Let’s go ahead and select Alert View, which will yield the dialog below. Give the alert view the name “Active Alerts.”

We must now select the entity that will filter where the data will come from, which will be a Windows Azure role instance as seen below. This means that alerts within your management pack will be contextual only to Windows Azure role instances, so you won’t see, for example, general SCOM alerts within this management pack. This makes sense because, as we will see later, user roles that access this management pack in the Web Console won’t care about alerts that are only meant for operations folks.

Select the View all targets radio button, and then select the Windows Azure Role Instance target. Then select the OK button. Next we will select the conditions for this alert, which will mirror the Active Alerts node in the default Azure management pack. In the Select conditions: list, go ahead and select the with specific resolution state item. Click the specific link immediately below in the Criteria description list, which will present the Resolution State dialog, where you will then set the Resolution State as seen in the screenshot below. When you’re done, select the OK button in the Resolution State dialog and subsequently the OK button in the parent dialog.

Our management pack view should now look as seen below, with the Active Alerts node added.

Let’s now add the first State View, beginning with the hosted services, by right-clicking on your management pack and selecting New | State View in the context menu. Enter the name Hosted Service State, and then select the ellipsis (…) button next to the Show data related to label that is now set to Entity. You will see the Select Items to Target dialog where you can select the target of this view. For our purpose, we will select the Windows Azure Hosted Service item. Note that you have the option of selecting all hosted services you are monitoring, or you can select a specific subset of hosted services by hosted service name.

When you’re done, your console should look similar to below, and you should see your hosted services in the right-hand pane as well as its details immediately below.

From here you can simply add the other state views by simply using the properties on the existing views as a guide for your own, or performing a copy/paste operation for each and modifying to suit.

Let’s now create a folder for our desired Azure application by right-clicking on the management pack, selecting New | Folder… , and then providing a folder name, as seen finished below. Then we will create performance views to target our specific hosted service inside that folder. Note that even though the console will allow you to copy a performance view from the default Azure management pack, you will get a very ugly error dialog when you try to paste it into your management pack, and then it will notify you that copy/paste functionality is “not available between management groups.” Performance views are easy to create anyway, so it’s not a huge issue. Now you can perform the copy in the management pack XML, but you will have to make sure everything is referenced properly, probably making it more trouble than what it is worth.

Before you create the performance view, let me first introduce the concept of groups, as this will be very important for giving you flexibility to create various types of views by grouping together logical collections of objects. You can also use groups to secure views by user role. In our case, we will simply create a group that will be mapped to a particular hosted service. Click on the Authoring view, and then right-click on the Groups node. Select Create a new Group… from the context menu, which will bring up the Create Group Wizard. Enter a name and description for the group that corresponds to your desired hosted service, and then select the management pack you created previously, as seen below.

Select the Next button, where you will select explicit group members. Leave Entity selected in the Search for: dropdown at the top of the dialog, and select the Search button. Note that you will have a number of objects from which to select for your collection, but we will simply select the web and worker role levels and add each to the Selected objects list at the bottom of the dialog, as seen below. Select OK when you’re done to return to the parent wizard dialog. Note that we could have selected at the host service, deployment, role, or instance levels depending on our needs.

Select the Next button for this dialog and the remaining dialogs in the wizard. Note that you have great flexibility to use formulas for populating group membership, you can add subgroups, or even exclude objects from this group. Not all will necessarily apply to your Windows Azure applications. On the last dialog, select the Create button. Your console should now look similar to the following screenshot.

Now that we have created our group, we can now go back to the Monitoring view to create a Performance View. Navigate to the folder that you create previously, perform a right-click, and select New |Performance View as seen below.

Enter Processor Performance for the name of your performance view. Under the now visible Criteria tab, select the ellipsis (…) button next to the Show data related to: label that is now set to Entity. On the dialog now presented, select Windows Azure Role, as seen below. Then select the OK button.

Now we will select the group that we created previously, by selecting the ellipsis (…) button next to the Show data contained in a specific group: label. Select the group, and then select the OK button, as seen below.

The next step is to select the conditions for display of the desired performance counters. Select the collected by specific rules in the Select conditions: list. You will then see the criteria description list populated, similar to below. Select the checkbox collected by specific rules. We select this because we will next select from the performance counter rules we have previously created.

From here, select the specific link in the criteria description, where you will scroll down to the desired performance counter that you created earlier, as seen below.

Select the OK button to dismiss the Select Rules dialog, where the parent dialog should now look similar to below.

You can now select OK, and will see the performance view. Select the performance counters in the Legend pane, and your console should look similar to below.

My final set of performance views look as follows below for my Logging Service.

Following is a set of useful counters for monitoring Azure applications (mapped into the views above):

Now that we have our performance views, the next thing to do is to create a nice dashboard view that brings together performance and monitoring information in one glance. To create the dashboard view, we right click on the folder where we just created our performance views, and select New | Dashboard View, as seen below.

You are then presented with a dialog where you can enter a name for the dashboard view and the format of the display. I have selected a four view dashboard, as seen below.

I next select the OK button, which then takes me to the dashboard view, ready for configuration, as seen below.

You can now just click on each view to add virtually any view desired. Since this dashboard view is specific to the Logging Service, I will add three performance counters as well as the hosted service state, beginning with the Processor Performance view as seen below.

Once you have selected a performance view, you can then select which performance counters you want displayed inside that view in the Legend/Detail view at the bottom.

To change the time range of your performance views, you can right-click on the desired performance view as seen below and select the desired time range.

So now we have a nice dashboard, but this dashboard won’t be useful if it cannot be viewed by the community of operations, test, and developer users that need to monitor Azure applications and respond to performance or application health issues. We can use the Web Console to provide this information apart from the Operations console, which we can secure by user role in a flexible manner that allows users to only see information that is specifically targeted towards their role.

Let’s first setup the user roles, and then we will turn our attention to the Web Console itself. Navigate to the Administration view and select the User Roles node under Security. Note there are a number of user profiles. For our purposes, we will create a Read-Only Operator role, and only give that user role rights to view the Logging Service dashboard. Below, you can see how creating a new user role is created by right-clicking any profile selecting New, and then selecting the desired role type.

After select the Read-Only Operator… menu option, we are presented with the Create User Role Wizard, as seen below. In the User role name textbox, I entered a name for a user role that will only be allowed to view the Logging Service dashboard. We now add a user as a member, and select the Next button.

The next page of the dialog is the Group Scope page, where we select the groups this user role can monitor. Recall that we create the Logging Service group, which we will select exclusively after deselecting the management group in the main node.

We then select the Next button, which takes us to the Views page. On this page, we will select the specific views allowed for this user role. We first select the Only the views selected below are approved radio button. We then scroll down to find our management pack, and select the desired dashboard as seen below including the individual views aggregated in the dashboard. If you wish to create a user role that can see all of the performance views as well as the state views, then you can select those also, or just select the management pack node for all views within the desired management pack.

When you select the Next button, you will see a dialog warning that if you change the views in the dashboard, you will need to grant permissions for the dashboard to the user role again. Go ahead and select the OK button. On the final page, select the Create button, as seen below.

Your user role is now created, as seen below.

Let’s now go the Web Console and see the difference between what an administrator sees as opposed to our Logging Service dashboard only user role. You can launch the Web Console on the SCOM server by navigating to the SCOM program group and selecting the Web Console, as seen below.

After you launch the Web Console, you will see that the only available major views are Monitoring and My Workspace as the Web Console is not intended for authoring, reporting, or administrative tasks. When you launch the console, you can navigate the Monitoring view in the same manner as in the SCOM console, based on user role. Below, you can see where I navigated to the Important Metrics node under the Logging Service folder within my Azure management pack. I then selected the Processor Performance view and selected the two performance counters available.

Now let’s see what our dashboard-only user role would see. The screenshot below verifies that the Logging Service dashboard only user can see only the allowed objects based on their user role. For each chart, you have simple filtering as follows:

1. All Items (the default view)
2. Items in the Chart
3. Items not in the Chart
4. Items by text search (this will search for your text anywhere in the counters)

One drawback to the Web Console is that the end user doesn’t have the ability to change the time range, which by default is 24 hours for performance views. This can only be changed in the web.config of the Web Console application, so it would apply to all Web Console users. It is not recommended that this be set to more than 72 hours due to the volume of data that has to be retrieved and rendered by the Web Console. For further information, please see Michael Pearson’s blog post on Web Console configuration settings.

Note that in a locked down environment, the port that SCOM generates on the server install may not work for users outside the server accessing the Web Console. Most likely port 80 will be open, so you will have to modify IIS7 to use this port instead. Let’s first take a look at where you can manage the settings in SCOM for the Web Console. From the Administration view, navigate to the Settings node. If you double-click on the Web Address item in the right-hand pane, you should see similar to below. Note that the SCOM installer selected port 51908 as the port for the Web Console application.

Below is a screenshot of the change that must be made in IIS7 to use port 80 (or any other port you would like). In my case, the server is dedicated to SCOM, so it was okay to modify the port of the default website.

Afterwards, we can go back to the SCOM console, change the port, and then test with port 80.

That completes this walkthrough. Stay tuned for the next walkthrough where we will cover event log alerting and monitoring.

Addendum

In this addendum, I will demonstrate how to change the time range of the performance views in the Web console. The first thing is to open IIS Manager, navigate to the Operations Manager 2007 Web Console website, and select the website. The default view is the Features View, so switch to the Content View. Right-click on the Web.Config file and choose the Edit Permissions… menu item. Look for the Location label, which will look similar to the following: C:\Program Files\System Center Operations Manager 2007\Web Console, as seen below.

Now that we have the path, we can find the file in Windows Explorer as seen below.

We will now open the file with Notepad, and add our modification to the time range in the appSettings section, as seen below. If there are other settings you would like to modify, please refer, again, to Michael Pearson’s blog post on Web Console configuration settings.

After modifying the Web.Config file, save it and launch the web console. Then navigate to one of your performance views. Your performance view should now look similar to below.