Chapter 8

Monitoring and Supporting an ASP.NET MVC 4 Project on Windows Azure

EXERCISES AND EXAMPLES

IN THIS CHAPTER

• How to monitor and support an ASP.NET MVC 4 Web Site on Windows Azure
• How to monitor and support an ASP.NET MVC 4 Cloud Service on Windows Azure

Wrox.com Code Downloads for this Chapter

You can find the wrox.com code downloads for this chapter at www.wrox.com/go/azureaspmvcmigration on the Download Code tab. The code for this chapter is divided into the following major examples. It is recommended that you download the code and review it so that you have a good understanding of what is about to be discussed.

Now that you’re live in production with an ASP.NET MVC 4 Web Site or Cloud Service, you certainly want to keep it running and responding to the visitors to the site.

A number of problems can happen, each one requiring a different set of logs or information to resolve them. This chapter walks you through monitoring and troubleshooting, with exercises divided between the ASP.NET MVC 4 Web Site and Cloud Service.

MONITORING AND SUPPORTING AN ASP.NET MVC 4 WEB SITE ON WINDOWS AZURE

You have many monitoring capabilities available to you for both websites and Cloud Services on the Windows Azure platform. Features that are very useful for monitoring your website include:

• The performance and utilization graphs available via the Dashboard view in the Windows Azure management console
• The real-time streaming of diagnostic tracing into Visual Studio
• Capabilities you can extend to include additional metrics, such as Failed Requests, Requests per Second and Memory utilization.

For the last item, you can extend capabilities from the Windows Azure management console, from Visual Studio and, for a Cloud Service, through a Remote Desktop Connection. You can then capture performance data just as you would from any web server.

These monitoring and performance capabilities are critical for understanding how a website performs from a response, availability, and stability perspective because they provide the administrator with useful data for optimizing, scaling, or repairing the system. Most inefficiencies that exist in a website would go unnoticed without monitoring performance, capturing performance data and reviewing the captured performance metrics.

Accessing the Graph and Usage Overview

One of the most useful tools for monitoring the usage, stability, and availability of your Windows Azure Web Site is the graph and usage overview features available through the Web Site Dashboard. You can access the Dashboard by clicking Web Sites ⇒ mvc-4 (the website you created) ⇒ Dashboard (default selection). Figure 8-1 represents how this may look.

FIGURE 8-1

Pay special attention to the HTTP Server Errors attribute. If you receive any number of these errors, you may want to check the log files to identify the error and to determine from which request it originates. Information on how to download and analyze the log files are discussed in the section titled “Downloading and Analyzing Diagnostic Logs,” later in this chapter.

A review and logging of the other attributes, such as CPU Time, Data In, Data Out, and Requests are also useful because they identify trends related to your visitors accessing your website, and they give you a good understanding of how your system works and uses the available resources. By looking at these logs and charts over time, you gain an understanding of website’s normal behavior and can quickly spot when behavior is abnormal.

By default, only a number of parameters are tracked:

• CPU Time: The amount of time deducted from your allocated CPU usage
• Requests: The number of requests sent to the website
• Data Out: The amount of data sent from the server to the client
• Data In: The amount of data sent to the server from the client
• HTTP Server Errors: A count of the number of HTTP server errors

Adding Metrics to the List of Monitored Attributes

Besides the default metrics listed in the last section, you can add a number of other metrics to tracking your site. To enable additional metrics, perform the following steps:

1. Select the Add Metrics link at the bottom of the Monitor page, as shown in Figure 8-2.

FIGURE 8-2

A pop-up appears showing additional traceable properties, which are listed in Table 8-1. Figure 8-3 illustrates the window allowing the addition or modification of metrics to track.

FIGURE 8-3

---

NOTE For a detailed discussion of the properties in Table 8-1, see Chapter 7.

---

TABLE 8-1: Windows Azure Monitor Properties

NAME	UNIT	DESCRIPTION
CPU Time	Milliseconds	Amount of time the CPU is used
Data In	Bytes	Amount of data from client to server
Data Out	Bytes	Amount of data from server to client
HTTP 401 errors	Count	Authentication errors
HTTP 403 errors	Count	Forbidden errors
HTTP 404 errors	Count	Not Found errors
HTTP 406 errors	Count	Not Acceptable errors
HTTP Client errors	Count	Client resets or failures
HTTP Redirects	Count	300 HTTP status codes
HTTP Server Errors	Count	500 HTTP status codes
HTTP Successes	Count	100–200 status codes
Requests	Count	The numbers of requests sent to the server

2. Select the options you want to view on the Monitor graph, and click the check mark at the bottom of the pop-up window.

3. After focus returns to the Monitor Dashboard, scroll down to view the values of the selected metrics.

Configuring Diagnostics for the Website

Another very interesting set of website capabilities are the features located on the Configure console. These features include the items — such as application diagnostics, site diagnostics, and deployment settings — that all provide useful information for troubleshooting and monitoring your website. To configure diagnostics for your website, perform the following:

1. Click the Configure link at the top of the Windows Azure management console for the given website.

2. Scroll down the page until you come to the site diagnostics section, as shown in Figure 8-4.

FIGURE 8-4

The following diagnostic logs, provided in Table 8-2, are available for logging and are off by default.

TABLE 8-2: Site Diagnostic Features

NAME	DESCRIPTION
Web Server Logging	IIS logs containing requests and HTTP status codes
Detailed Error Messages	Requests resulting in an error saved as an HTM file
Failed Request Tracing	Detailed report of the HTTP requests flowing through the request pipeline

3. For this example, turn all the logging on, as shown in Figure 8-5, then select the Save button at the bottom of the page.

FIGURE 8-5

4. When successfully configured and saved, access the website so that some traffic is logged and let it run for some minutes.

5. Proceed to the next exercise, which walks you through downloading and reviewing the captured logs.

Downloading and Analyzing Diagnostic Logs

Now that the website is configured to begin logging web server, detailed error, and failed request logs, you need to download these logs so you can analyze them and take actions to prevent errors or to improve website performance, if required. To download and analyze the just-configured diagnostic logs, perform the following steps:

1. Scroll down on the Dashboard console. On the right side of the page in the Quick Glance section, locate the Diagnostics Log heading. Under that heading is an FTP address that you can use to download the log files.

2. Obtain a download tool, such as FileZilla, which you can download here: http://filezilla-project.org/download.php.

3. Once you download and install an FTP client, use the FTP address and the UID/Password you created previously in Chapter 6 to access the FTP site.

---

NOTE An example of how the FileZilla client may look when connected to the LogFiles directory of the Windows Azure Web Site is shown in Figure 8-6.

---

FIGURE 8-6

4. Locate two directories in Figure 8-6: DetailedErrors and W3SVC*, where * is the website ID.

5. Click the DetailedErrors directory. This will open a file called ErrorPage****.htm. Download one or all of the Error Pages and view them. For example, at first glance, Figure 8-7 shows that a visitor attempted to access a file that was not found, that is, a 404.0 Not Found error.

FIGURE 8-7

6. Look at the Requested URL value in the Detailed Error Information section. The requested file is robot.txt. There is a lot of valuable information on the page to read.

7. If the error is preventable based on some action, execute that action.

---

NOTE The error page is the same that you receive when an error occurs on a normal instance of IIS 7+.

---

In this example, there was a request to a robots.txt file that does not exist on the website. The robot.txt file tells compliant web robots which files or directories it should exclude from being categorized or archived into a search engine. If there is no robots.txt file, then all contents of the website is crawled and cataloged. If there is a section of your public website that shouldn’t render in any search engine or be archived, you must place a text file in the root directory of the website.

• If you do not want anything in the Images directory cataloged or archived, the robot.txt file would resemble Listing 8-1.

LISTING 8-1: Restricting Access to All Robots and Crawlers to the Images Directory

User-agent: *
Disallow: /Images/

• Listing 8-2 is an example of a robot.txt file that restricts access to a specific file if you prefer to restrict access on a file basis.

LISTING 8-2: Restricting Access to All Robots and Crawlers to a Specific File

User-agent: *
Disallow: /Images/private.png

Even though a robot.txt exists that disallows access to some files and directories, it is up to the crawler to honor the instructions.

8. Click the W3SVC* directory (where * is the website ID IIS created when the site was configured). This will show the Failed Request Tracing logs.

9. Download all or a sample of the XML files and the freb.xsl file. The XSL file is required for formatting the output of the Failed Request Tracing XML file.

10. Open the XML file in a browser such as Internet Explorer, and you should see something similar to Figure 8-8.

FIGURE 8-8

11. You can find an abundant amount of information in this log. For example, click the Request Details tab ⇒ Performance View. As shown in Figure 8-9, you see the ASP.NET MVC 4 request pipeline events. On the right side are timings. If you were experiencing a performance issue, this would be a good place to determine what the problem is.

FIGURE 8-9

12. Click the Compact View tab, as shown in Figure 8-10. This tab shows a line-by-line breakdown of what happened from the beginning of your request to the final response. This is not only good for finding issues, but is also a great source for learning how an ASP.NET MVC 4 request flows through the IIS pipeline.

FIGURE 8-10

Streaming Diagnostic Logs

One of the newer capabilities supports streaming Windows Azure Web Site logs directly into Visual Studio. This information is useful for debugging the application in real-time while users are accessing and using the Site. To implement diagnostic log streaming, perform the following steps:

LISTING 8-3: Adding a Trace statement to the Index() method

using System.Diagnostics;
 
public ActionResult Index()
{
  Trace.TraceError("An error happened here is the message: Just testing! ");
}

3. Publish the changes. You have numerous ways to publish the code change to the Windows Azure Web Site. See Chapter 5 or 6 for information about these different deployment methods. Once the modified ControllerHomeController.cs file is deployed, continue to step 4.

4. Enable the application logging. To enable the logging, open the Server Explorer in Visual Studio as shown in Figure 8-11 and expand the Windows Azure Web Sites feature.

FIGURE 8-11

5. Open the website settings. Right-click the website to which the Trace statement was added in step 2. In this example, right-click the mvc-4 website and click View Settings.

6. View the settings. Clicking the View Settings menu item opens a properties page similar to that shown in Figure 8-12.

FIGURE 8-12

7. Change the settings. Set the Application Logging (File System) value to Error and click the Save link on the top left side of the properties page.

8. View the streaming logs in the output window. Once the setting has been saved, return to the Server Explorer and right-click the website similar to what was done in step 5.

9. View the streaming diagnostics. Right-clicking the website brings up a pop-up menu, where you must select the View Streaming Logs in Output Window. This opens an Output window where you can view the streaming diagnostics in almost real-time as illustrated in Figure 8-13. Note that there is about a two second delay.

FIGURE 8-13

10. Stop streaming the diagnostic logs. Once you have viewed enough of the streaming diagnostic data, turn it off by right-clicking the website and selecting the Stop Viewing Logs menu item.

Now that you know some details about configuring the monitoring for a website, you can move to the next section to check out what is available with a Cloud Service.

MONITORING AND SUPPORTING AN ASP.NET MVC 4 CLOUD SERVICE ON WINDOWS AZURE

As previously discussed, there are a number of differences between a website and a Cloud Server and Web Role. One is the ability to update diagnostics settings on a live service, and the other is to create a Remote Desktop Connection. The steps described in the following sections show you how to set up both these features.

Updating Diagnostic Settings on a Live Service

You can configure the metrics that track the performance and availability of a Web Role from the Windows Azure management console. In addition, the recent release of the Windows Azure SDK now allows you to perform that same configuration from Visual Studio. To update the diagnostic settings for a Cloud Service hosted on the Windows Azure platform using Visual Studio, perform the following steps:

1. Update the Diagnostic settings. Open the Server Explorer menu, expand the Windows Azure Compute feature, and right-click the Update Diagnostics Settings menu item as shown in Figure 8-14. Then click the Update Diagnostics Settings menu item to open the window shown in Figure 8-15.

FIGURE 8-14

FIGURE 8-15

2. Configure and Enable Performance Counters. Select the desired metrics from the numerous performance counters and click OK to immediately begin logging those metrics.

3. View the data stored in the Windows Azure Storage table. The performance data is stored in the linked Windows Azure Storage account. To access the table, open Server Explore in Visual Studio as shown in Figure 8-16.

FIGURE 8-16

4. Extract data. Double-click the highlighted table called WADPerformanceCountersTable. The table contents appears in the main window of Visual Studio. You can now make a data connection to the table for extracting and analysis offline.

The information logged in the WADPerformanceCountersTable is useful for forecasting and measuring resource usage. You can create action plans to scale and make code enhancements by analyzing this data.

Configuring a Remote Desktop Connection

You may find it useful to create a Remote Desktop Connection when you want to troubleshoot or monitor a Web Role hosted on the Windows Azure platform.

If you have not already published your ASP.NET MVC 4 project, you can configure the Remote Desktop configuration during the initial publishing of the Web Role. If you have already published your ASP.NET MVC 4 project and want to set up only the Remote Desktop Connection without republishing, go to the next section titled “Setting Up a Remote Desktop Connection for an Existing Cloud Service.”

To begin the configuration of a Remote Desktop Connection to a Web Role, perform the following:

1. Publish the Web Role with the Enable the Remote Desktop for All Roles option enabled. Right-click the project name, in this case csharp, and click Publish, as shown in Figure 8-17.

FIGURE 8-17

2. Click Publish to start the Navigation Wizard. This is shown in Figure 8-18. If you do not already have a credential file, click the Sign in to Download Credentials link to retrieve it.

FIGURE 8-18

3. Download the publish file. When you log into your Windows Azure account, a file with the extension .publishingsettings is downloaded. Save the file to a location on your computer; then click the Import button and navigate to and select the file just downloaded.

4. Open the Windows Azure Publish Settings Window. When the publishing settings file is successfully imported, click the Next button. The next window in the wizard displays, as shown in Figure 8-19.

FIGURE 8-19

5. Enable the Remote Desktop. By default, the Enable Remote Desktop for All Roles Settings is not selected. Select the check box to enable the feature.

6. Provide the User ID, Password, and certificate for making the connection. When you click the Enable Remote Desktop for All Roles check box, a pop-up window prompts you for a username, password, and an expiration date.

7. Choose a strong password that is not the same as the username, and set a reasonable account expiration date. Figure 8-20 illustrates this. The strength of the certificate you select for password encryption in the coming steps, as well as the complexity of your password, should dictate the duration of this accounts validity — that is, the expiration date. Like all account credentials, you should change this credential regularly to avoid a breach in security.

FIGURE 8-20

8. Enter in the other requested information in Figure 8-20. If you want to select or create a certificate to encrypt the user credentials, select the More Options button. Without selecting an encryption certificate, a certificate is automatically created and used. When complete, click OK.

9. View the Publish Summary. Select the Next button to view the Summary. Confirm that the Remote Desktop attribute has a value of Enabled, as shown in Figure 8-21.

FIGURE 8-21

11. Publish the Web Role. When confirmed, select the Publish button to publish the Web Role and to enable the Remote Desktop. A status window displays when the Role publishes. Figure 8-22 illustrates how the status appears during the publishing, and when it completes.

FIGURE 8-22

12. Connect the Web Role. When the publishing is complete, log in to the Windows Azure management console, and navigate to the Web Role that was just published. Click the Instances option as shown in Figure 8-23 and select the Connection link.

FIGURE 8-23

13. Download, save and open the RDP file for making the Remote Desktop Connection. The RDP file is a configuration file used with the Remote Desktop Connection application, which contains the information required to make the connection to the remote server. When you click the RDP file, a pop-up displays, as shown in Figure 8-24. Click the Open button to open the Remote Desktop Connection and connect immediately.

---

NOTE Alternatively, you can select the Save button and save the link to your desktop or any location on your computer. By saving the connection you have the option to make a connection again in the future without having to access the Windows Azure management console.

---

FIGURE 8-24

14. Enter your credientials. Whether you open or download and save the file, double-click the icon, and enter the credentials you provided in Figure 8-20. Then select OK. Figure 8-25 provides an example of this window.

FIGURE 8-25

15. Connect to the Web Role, make some changes, and disconnect from the Web Role. After logging in. you are given control of the server; for example, if the server is Windows Server 2012, you see a desktop similar to that shown in Figure 8-26.

FIGURE 8-26

On the desktop, you can view files and modify the server or IIS configuration as you would with any server. To end the session, simply log out like you would on any server and you are disconnected.

Setting Up a Remote Desktop Connection for an Existing Cloud Service

If you have already published your Web Role and do not want or need to do a republish to set up a Remote Desktop Connection, you can achieve the same connection by performing the steps in this section. The steps to configure a Remote Desktop Connection previously required that you publish the configuration file to the Windows Azure platform. Using the following approach, no publishing is required and you can perform the configuration either directly in Visual Studio or the Windows Azure management console.

1. Right-click the project (not the Web Role) and then click Configure Remote Desktop, as shown in Figure 8-27. The Remote Desktop Configuration window appears, as shown in Figure 8-28.

FIGURE 8-27

FIGURE 8-28

2. Select the Enable Connections for All Roles check box. Then select a certificate to use for the encryption of the user credentials (or leave at <Automatic>).

3. Enter the username, password, and expiration date.

4. Click OK after entering the required information.

5. Log in to the Windows Azure management console. Then select Web Sites ⇒ mvc-4 (your Web Role) ⇒ Instances. Notice that the Connect icon is enabled, as shown in Figure 8-29.

FIGURE 8-29

6. Click the Connect link, and you are prompted to open or save the RDP file, as shown in Figure 8-30.

FIGURE 8-30

7. Click the Open button, and the pop-up window shown in Figure 8-31 displays.

FIGURE 8-31

8. Click the Connect button to continue.

9. Enter your credentials in the Windows Security pop-up, and select OK. You may receive an additional pop-up window, as shown in Figure 8-32. Click Yes to continue.

FIGURE 8-32

10. Read through the details and select Yes. Your connection to the Web Role is completed.

---

NOTE After you have a Remote Desktop Connection to your Cloud Server, the door is open for you to make almost any change, and look at almost any configuration, log, or performance counter. It’s the same as if you were managing your own Windows Server running IIS.

---

11. Right-click the task bar to get a pop-up menu, and select Task Manager, as shown in Figure 8-33.

FIGURE 8-33

12. Navigate through the Task Manager looking on the Performance tab, as shown in Figure 8-34. You can see the utilization of CPU, Memory, and Network. There is a link to open the Resource Monitor as well.

FIGURE 8-34

13. Click the Details tab, shown in Figure 8-35. Here, you see the W3WP worker process IIS uses to manage the requests being made to that Web Role. If you need to perform some debugging of a hung, crashed, or failing website/Web Role, you can right-click the W3WP worker process and select Create Memory Dump. Then you can download the memory dump and analyze it using WinDbg or Visual Studio at a later time. Figure 8-36 shows this pop-up window and the resulting message after the memory dump is created. Take note of the path so that you know where to copy it from.

FIGURE 8-35

FIGURE 8-36

14. Open the IIS management console by selecting Tools from the Server Manager Dashboard ⇒ Internet Information Services (IIS) Manager, as shown in Figure 8-37.

FIGURE 8-37

15. Many other tools are available for access, usage, and review. For example, after IIS is open, if you click the Worker Processes icon (shown in Figure 8-38), this displays the requests currently executed on your Cloud Service in real time.

FIGURE 8-38

---

NOTE A worker process is the W3WP.exe windows process. It handles requests sent to a web server for a specific application pool.

---

Figure 8-39 represents a view of the currently executing processes. The information provided is the amount of CPU utilization, memory utilization, and the process ID handling the given request.

FIGURE 8-39

You can double-click the specific request for even more information:

• Website ID: A unique identification number given to the website
• URL: The Internet address of the request
• Verb: Example: GET, POST, PUT, HEAD, and so on
• Client IP: The IP address of the client that sent the request to the server
• State: ExecuteRequestHandler, BeginRequest, and more
• Module Name: ManagedPipelineHandler, IsapiModule, and such
• Time Elapsed: The amount of time required to execute the request

These features provide some very useful information for troubleshooting and for learning how your system works on the Windows Azure and IIS platform.

Another tool available to monitor and administer your Web Role in IIS on the Windows Azure platform is the PowerShell WebAdministration module. This provides the administrator with, among others, the ability to:

• Add, modify, and delete websites and application pools
• Enable and disable global modules
• Back-up and restore a web configuration

Using the WebAdministration PowerShell Cmdlets

To use the WebAdministration components of PowerShell that are useful for administering and monitoring IIS, perform the following steps. PowerShell uses cmdlets, which are small programs that perform a specific actions; for example, Get-WebRequest is a cmdlet.

1. To Start PowerShell click the PowerShell icon on the left side of the task bar, as shown in Figure 8-40.

FIGURE 8-40

2. After the command window opens, enter the command import-module WebAdministration ⇒ cd IIS: ⇒ cd sites ⇒ dir to get a list of the websites running on this instance of IIS. Figure 8-41 illustrates how this may appear.

FIGURE 8-41

3. You can see if the website is in a started or stopped state. You can also check the same for application pools running on the server. Enter cd ⇒ cd AppPools ⇒ dir to get a list and status of the application pools, as shown in Figure 8-42.

FIGURE 8-42

4. You can also gain some information about currently executing requests by entering GeT ⇒ WebRequest ⇒ AppPool GUID, as shown in Figure 8-43.

FIGURE 8-43

The result of the command provides you information about a request that the Web Server is currently responding to. Information includes an ID, the requested page, the verb, the hostname, and so on, and is useful for obtaining a real-time snapshot of what is happening on the system. For example, if users are complaining about some performance problems, you can execute this command to see if anything looks suspicious, like a large timeElapsed value.

Changing IIS Settings Using the IIS Management Console

You can change IIS settings to improve the performance and stability of the website using the IIS management console. To do so, follow these steps:

1. Open the IIS management console, and click the Logging feature, as shown in Figure 8-44, to view where the IIS logs are stored.

FIGURE 8-44

2. The path in the Directory text box, shown in Figure 8-45, is the location to which the IIS logs are written. Open Windows Explorer and navigate to that path to view the IIS Log files.

FIGURE 8-45

3. Review the ISS logs. You use these Log files to troubleshoot any other IIS issue and draw a lot of conclusions and actions by reviewing them.

---

NOTE You can find additional resources for troubleshooting IIS issues using IIS Logs in an article the author wrote about troubleshooting IIS issues using LogParser here: http://www.iis.net/learn/troubleshoot/performance-issues/troubleshooting-iis-performance-issues-or-application-errors-using-logparser.

---

To illustrate how to use log files to troubleshoot, I use Listing 8-4 as an example. After downloading and installing LogParser, open a command prompt and execute the query using LogParser, as shown in Listing 8-4.

LISTING 8-4: LogParser Query — General Activity

logparser.exe "SELECT sc-status, sc-substatus, COUNT(*) 
               FROM *.log 
               GROUP BY sc-status, sc-substatus 
               ORDER BY sc-status" -i:w3c

This query renders results similar to those shown in Table 8-3. The query and its output provide some insight into what is happening on the website. The large majority of requests handled by the website/Web Role are successful, that is, a request with a sc-status of 200 is considered successful. 300 and 400 HTTP Status codes can be “generally” assumed to be okay, unless you have an authentication problem. Otherwise, the most important HTTP Status codes to analyze further are requests that result in an HTTP Status code of 500.

TABLE 8-3: Results of an example LogParser query executed on IIS Logs by Status

An HTTP Status code of 500 means there was some kind of error on the server that prevented the successful response to the request. To investigate the 500 HTTP Status codes further, you execute the LogParser query shown in Listing 8-5.

LISTING 8-5: LogParser Query — 500 HTTP Status Error Deep Dive

logparser.exe "SELECT cs-uri-stem, COUNT(*) 
               FROM *.log 
               WHERE sc-status=500 
               GROUP BY cs-uri-stem 
               ORDER BY COUNT(*) DESC" -i:w3c

The LogParser query renders the requested file that resulted in a 500 HTTP Request and the number of time it happened for that file. Table 8-4 illustrates an example of what the results may look like.

TABLE 8-4: Results of an example LogParser query executed on IIS Logs by File

The result of the query clearly shows that the file with the most failures is the Default.aspx file. Therefore, you need to look into the contents of the file to determine what it is doing and the dependencies it has, and then take some actions to make it more fault-tolerant. Using this information together with other available logs, you can compose a good theory of what is happening; for example, viewing the Application event logs existing in the Event Viewer, as discussed next.

Viewing the Event Logs in a Windows Azure Cloud Service

You can also view and configure event logs via the Event Viewer window. The event logs contain system and application errors and warnings that are very useful in troubleshooting and preventing system issues. To view the logs, perform the following:

1. Select Event Viewer, as shown in the previous figure, and the Event Viewer window displays, as shown in Figure 8-46.

FIGURE 8-46

---

NOTE In most cases, IIS, ASP.NET, and ASP.NET MVC logs are logged to the Application Event log located in the Event Viewer (local) ⇒ Windows Logs ⇒ Application log path.

---

2. Set a Filter to view only Errors or Warnings and see if you find any troubles with your system or the platform.

The Event Viewer offers many additional options for logging and troubleshooting a problem. For example, if you have some problems with a certificate, enable the CAPI2 Application Log, as shown in Figure 8-47, to log Errors, Warnings, and Information pertaining to SSL certificate issues.

FIGURE 8-47

Viewing the Cloud Service Usage Dashboard

Moving back to the Windows Azure management console, a useful Dashboard can help you track the CPU utilization and a number of other metrics, as shown in Figure 8-48. Tracking these metrics is important for setting baselines and forecasting future resource requirements.

FIGURE 8-48

To get a good overview understanding of how use these monitoring features, perform the following steps:

1. Click the Monitor link at the top of the management console to access the page shown in Figure 8-49. Notice the Add Metrics link at the bottom of the page.

FIGURE 8-49

2. Click the Add Metrics link and the pop-up shown in Figure 8-50 displays.

FIGURE 8-50

3. Select the properties you want to monitor; then click the check on the lower-right of the window. The metrics you selected in Figure 8-50 are added.

4. In the Windows Azure management console for the csharp Web Role, select the Configure link at the top of the page. Figure 8-51 shows this page.

FIGURE 8-51

5. Configure the monitoring level to Verbose and keep the Retention Days as the default value. When selected, the menu items at the bottom of the page change, as represented in Figure 8-52. A warning appears.

FIGURE 8-52

---

WARNING Regarding the warning shown in Figure 8-52: Changing the level of monitoring to Verbose can have an impact on the costs, so make sure you take this into consideration when making the change.

---

7. Select the Save button to apply the changes.

SUMMARY

In this chapter you learned that there are some large differences in the monitoring and support capabilities between a website and a Cloud Service. The biggest difference is that a Windows Azure Cloud Service supports Remote Desktop Connection, something not possible with a Windows Azure Web Site.

Using a Remote Desktop Connection, you can administer the Web Role just like you would any website hosted on IIS. All the tools for monitoring the behavior of the website and operating system, such as Performance Monitor, Event Viewer, Task Manager, and so on are at your fingertips.

Nonetheless, plenty of capabilities and features are available for applications hosted as a website, such as usage statistics on the Dashboard, the capability to add metrics to the Dashboard, and the quick availability of download log files, such as the IIS logs and Failed Request Tracing logs. All these features can provide you with enough information to understand and resolve most issues experienced on a Windows Azure Web Site.