Chapter 9. Cloud Service Diagnostics, Debugging, and Configuration

In the previous chapter, we introduced cloud services and created a worker role for our production order processor. We're going to continue with cloud services in this chapter, taking a closer look at diagnostics, debugging, and configuration.

We'll be covering the following topics:

• Configuring diagnostics

• Remote debugging

• Debugging with IntelliTrace

• Remote desktop

• Configuration change

• Start-up tasks

We've already covered a lot about the fundamentals of application logging and diagnostics in Chapter 6, Azure Website Diagnostics and Debugging, which applies to cloud services too, so we'll go straight into taking a look at cloud service diagnostic configuration options here.

Configuring diagnostics

Cloud services can log application diagnostics using the Trace object in the code in worker and web roles and server diagnostics from the virtual machine instances that are hosting the roles.

We can configure a role's diagnostics in the role properties by double-clicking on the role in Visual Studio and looking at the Configuration tab:

We have options to enable and disable diagnostics with the Enable Diagnostics setting; then we have basic diagnostic levels of Errors only, which only logs errors, All information logs everything, and Custom plan gives us more fine-grained control over what we log with options for Application logs, Event logs, Performance counters, Infrastructure logs, and Log directories:

Adding local diagnostics

Cloud services have the facility to attach local storage, which can be used as a temporary data store, which is only available locally to the instance. Local diagnostics can be useful for development and debugging as we can access them easily...

Remote debugging

Worker roles support remote debugging, which is a really useful feature to help you debug a system deployed to the cloud. To get started with this, we need to publish our role in the Debug configuration so that we can successfully attach the debugger to it:

In the Advanced Settings tab, check Enable Remote Debugger for all roles. I've also checked Enable IntelliTrace, so we can look at this too:

We can debug an entire role or an individual instance from the Visual Studio Server Explorer window. If we choose to debug an entire role, the debugger will break on the first instance to run into the break point; debugging multiple instances is similar to debugging multithreaded applications, which can sometimes be a little confusing, so if you're not debugging a concurrency issue, it's probably easier to debug a single instance.

To start debugging in Visual Studio from the Server Explorer window, choose a role or an instance, right-click on it, and select Attach Debugger...:

Next,...

Debugging with IntelliTrace

IntelliTrace is a great tool to make the debugging process more efficient; it creates a stream of detailed application events from many framework components, which can be replayed after they've occurred, allowing us to go back in time and debug the application. IntelliTrace is only available in Ultimate versions of Visual Studio; if you don't have Visual Studio Ultimate, you can get a 3-month trial to try this feature if you like.

To get started, we need to enable IntelliTrace in the Advanced Settings tab during the publish step. We can adjust the IntelliTrace Settings by clicking on the Settings… link next to the Enable IntelliTrace checkbox:

Tip

As with all diagnostic data, we need to be careful while using IntelliTrace as we can quickly build up large amounts of data in storage, which we will be charged for. We can control the maximum amount of data stored by navigating to the IntelliTrace Settings | Advanced tab, and the default value is 250 MB.

To view the IntelliTrace...

Remote desktop connection

As cloud services run on dedicated virtual machines (per deployment environment), it's possible to remote desktop to them to perform advanced diagnostics and configuration, although generally, it's not the best practice to do manual modifications to the environment as these will not be applied to roles when they are initially created during a scale out or re-imaged on a guest-OS upgrade, which happens every few months (there's a great article about OS upgrades here: http://blogs.msdn.com/b/kwill/archive/2012/09/19/role-instance-restarts-due-to-os-upgrades.aspx). To implement environment customizations, it's recommended that you use start-up tasks, which we will be covering shortly.

In the previous chapter, we configured remote desktop during the publish step with a username and password. We can connect using a .rdp file downloaded from the portal, which is useful for system administrators or via the Visual Studio Server Explorer window, which can be more convenient...

Detecting configuration changes in code

When we use configuration settings in our roles, such as the AzureBakery.Production.Storage setting we created in the previous chapter, we can change these at runtime in the role's CONFIGURATION tab in the portal:

To detect config changes in code, we can attach event handlers to the RoleEnvironment.Changing event, which is fired before a config change is applied to the role and the RoleEnvironment.Changed event, which is fired after the change has been applied:

public override bool OnStart()
{
    Trace.TraceInformation("OrderProcessorRole.WorkerRole.OnStart - Begin");

    RoleEnvironment.Changing += RoleEnvironment_Changing;
    RoleEnvironment.Changed += RoleEnvironment_Changed;
}

Using the Changing event, we can set the e.Cancel flag to true, which will cause the role to recycle, and the new changes are applied on the next start:

private void RoleEnvironment_Changing(object sender, RoleEnvironmentChangingEventArgs e)
{
    // Implements the changes...

Start-up tasks

Start-up tasks are command-line scripts that can be added to a role in the ServiceDefinition.csdef file, allowing the role to perform activities before the role has started. These activities might be things such as installing a third-party package or making environmental or configuration changes. Start-up tasks are the best way of customizing a server rather than making manual changes using a remote desktop. We're going to have a very brief look at this area, so it's worth doing some additional reading around this area yourself.

Creating a batch script

To get started, we need to create a .cmd batch script to perform a task (you can also write PowerShell .ps1 scripts) called DemoTasks.cmd and put it in a solution folder called Tasks:

Before we write the script, we'll set the Build Action property of the file to Content so that the file along with the Tasks folder is copied to the output (bin) folder, and Copy to Output Directory to Copy if newer so that the file is copied if it...

Summary

We've now completed the cloud services topic we started in the previous chapter, and we've taken a closer look at using diagnostics, remote debugging, and IntelliTrace, to help us debug our applications that run in the cloud. We've also looked at detecting configuration change so that our cloud services can dynamically respond to changes without the need to redeploy or manually recycle. Finally, we looked at start-up tasks, which allow us to customize the cloud service environment before a role starts.

In the next chapter, we're going to look at building an ASP.NET Web API web service and a production management application, which we will integrate into our system using Azure Active Directory.

Questions

1. Which connection string is used for local storage?

2. What is the name of the storage table where diagnostic data is stored?

3. What publish settings must we apply to enable remote debugging?

4. What process do we attach to when remote debugging a worker role?

5. What happens if we debug a role rather than an instance?

6. Is it possible to use IntelliTrace on cloud services in Visual Studio Express?

7. Which is the default RDP port?

8. What is the difference between the RoleEnvironment.Changed and RoleEnvironment.Changing events?

9. Where are start-up tasks defined?

10. What properties must we apply to a task script so that it is copied when we publish?

11. What is the %TEMP% variable an example of and what does it do?

12. What is the difference between limited and elevated executionContext?

Answers

1. UseDevelopmentStorage should be set to true.

2. WADLogsTable.

3. The Debug configuration and Enable Remote Debugger for all roles in the Advanced Settings tab.

4. WaWorkerHost.exe.

5. We start debugging all role instances simultaneously.

6. No, unfortunately it's only available in Visual Studio Ultimate.

7. 3389.

8. The RoleEnvironment.Changed event allows us to detect when config has changed in code and deal with it accordingly at runtime. RoleEnvironment.Changing allows us to recycle the role if the config is changing using the e.Cancel flag so that new settings are applied on start.

9. They are defined on a per-role basis in the cloud service's ServiceDefinition.csdef file.

10. Build action is set to Content and Copy to Output Directory is set to Copy if newer.

11. It's a standard environmental variable, which gives us the path of the temp directory.

12. Limited runs the script with normal privileges while elevated runs the script with administrator privileges.