Deploying and Monitoring Applications in Windows Azure



Hands-On LabWindows Azure: Deploying and Monitoring Applications in Windows AzureLab version:1.0.0Last updated: DATE \@ "M/d/yyyy" 12/22/2009Contents TOC \h \z \t "Heading 3,2,pp Topic,1,PP Procedure start,3" Overview PAGEREF _Toc249252651 \h 3Exercise 1 - Deploying an Application Using the Windows Azure Developer Portal PAGEREF _Toc249252652 \h 7Task 1 – Creating a Windows Azure Account PAGEREF _Toc249252653 \h 7Task 2 – Creating a Storage Account and a Hosted Service Component PAGEREF _Toc249252654 \h 9Task 3 – Deploying the Application to the Windows Azure Developer Portal PAGEREF _Toc249252655 \h 15Task 4 – Configuring the Application to Use the Storage Account PAGEREF _Toc249252656 \h 19Task 5 – Testing the Application in the Staging Environment PAGEREF _Toc249252657 \h 22Task 6 – Promoting the Application to Production PAGEREF _Toc249252658 \h 26Exercise 2 - Using PowerShell to Manage Windows Azure Applications PAGEREF _Toc249252659 \h 28Task 1 – Generating a Self-Signed Certificate (Optional) PAGEREF _Toc249252660 \h 29Task 2 – Preparing the Windows Azure Account PAGEREF _Toc249252661 \h 29Task 3 – Uploading a Service Package Using Windows PowerShell PAGEREF _Toc249252662 \h 33Task 4 – Upgrading a Deployment Using Windows PowerShell PAGEREF _Toc249252663 \h 37Verification PAGEREF _Toc249252664 \h 40Exercise 3 - Monitoring Applications in Windows Azure PAGEREF _Toc249252665 \h 41Task 1 – Configuring Azure Storage for Persisting Diagnostics Data PAGEREF _Toc249252666 \h 42Task 2 – Enabling Failed Request Tracing PAGEREF _Toc249252667 \h 43Task 3 – Instrumenting a Web Role PAGEREF _Toc249252668 \h 50Task 4 – Monitoring Azure Services Remotely PAGEREF _Toc249252669 \h 57Verification PAGEREF _Toc249252670 \h 62Summary PAGEREF _Toc249252671 \h 67OverviewIn this hands-on lab, you will learn how to deploy your first application in Windows Azure. The lab walks through the process using a simple application named myTODO, which is a simple list creation and management application built using MVC. The lab shows the steps required for provisioning the required components in the Windows Azure Developer Portal, uploading the service package, and configuring the service. You will see how you can test your application in a staging environment and then promote it to production once you are satisfied that it is operating according to your expectations.Figure 1The myTODO application running in Windows AzureIn the course of the lab, you will also examine how to deploy, upgrade, and configure Windows Azure applications programmatically using the Service Management API. You will use the Windows Azure Service Management Tools, which wrap the management API, to execute Windows PowerShell scripts that perform these operations.Finally, you will explore the Diagnostics Management API to monitor applications and gather diagnostics information. You will instrument the myTODO application, adding performance counters and trace messages. You will then configure the diagnostics infrastructure to store this information in an Azure Storage account and examine the information it produces.ObjectivesIn this Hands-On Lab, you will learn how to:Use the Windows Azure Developer Portal to create storage accounts and hosted service componentsDeploy service component packages using the Windows Azure Developer Portal user interfaceChange configuration settings for a deployed applicationTest deployments in a separate staging environment before deployment to final productionUse Windows PowerShell to deploy, upgrade, and configure Windows Azure services programmaticallyMonitor applications and gather diagnostics information using Windows Azure DiagnosticsPrerequisitesThe following is required to complete this hands-on lab:Microsoft .NET Framework 3.5 SP1Microsoft Visual Studio 2008 SP1 (or above)Windows Azure Tools for Microsoft Visual Studio (November 2009) MVC 1.0IIS 7 (with , WCF HTTP Activation, Tracing)Windows Azure Service Management CmdLets 1.1Note: The source code for the Windows Azure Service Management CmdLets is included in the Assets folder and built during setup.SetupFor convenience, much of the code used in this hands-on lab is available as Visual Studio code snippets. To check the prerequisites of the lab and install the code snippets:Run the SetupLab.cmd script located in the lab's Source\Setup folder to check dependencies and install any missing prerequisites.Once you have verified every prerequisite, follow the instructions to install the code snippets. Using the Code SnippetsWith code snippets, you have all the code you need at your fingertips. The lab document will tell you exactly when you can use them. For example, To add this code snippet in Visual Studio, you simply place the cursor where you would like the code to be inserted, start typing the snippet name (without spaces or hyphens), in this case LabNameEx01RunmethodCS, watch as Intellisense picks up the snippet name, and then hit the TAB key twice once the snippet you want is selected. The code will be inserted at the cursor location. Figure 1Hit TAB to select the highlighted snippet.Figure 2Hit TAB again and the snippet will expandTo insert a code snippet using the mouse rather than the keyboard, right-click where you want the code snippet to be inserted, select Insert Snippet followed by My Code Snippets and then pick the relevant snippet from the list.To learn more about Visual Studio IntelliSense Code Snippets, including how to create your own, please see . ExercisesThis hands-on lab comprises the following exercises:Deploying an Application Using the Windows Azure Developer PortalUsing PowerShell to Manage Windows Azure ApplicationsMonitoring Applications in Windows AzureEstimated time to complete this lab: 60 minutes.Exercise 1 - Deploying an Application Using the Windows Azure Developer PortalIn this exercise, you deploy the myTODO application to Windows Azure using the Windows Azure Developer Portal. To do this, you register a Windows Azure developer account and provision the required service components. Next, you upload the application package to the staging area and configure it. You then execute the application in this staging area to verify its operation. Finally, you promote the application to production.Task 1 – Creating a Windows Azure AccountIn this task, you create a new Windows Azure account and redeem an invitation token to enable the creation of hosted services.Navigate to using a Web browser and sign in using your Windows Live ID.Figure 2Signing in to the Windows Azure portalIf this is your first visit to the Windows Azure Developer Portal, create a new account associated to your Windows Live ID. Review the Privacy Statement and click I Agree to proceed.Figure 3Creating a new Windows Azure Developer Portal accountAfter creating the account, click Continue to proceed.Figure 4Successful creation of the accountEnter your invitation token and click Next to redeem it.Note: Invitation tokens are required to enable services at the Windows Azure Developer Portal. To obtain an invitation token, you will need to register at to obtain a product key for the Windows Azure Platform.Figure 5Redeeming an invitation token to enable the creation of hosted servicesTask 2 – Creating a Storage Account and a Hosted Service ComponentThe application you deploy in this exercise requires both compute and storage services. In this task, you create a new Windows Azure storage account to allow the application to persist its data. In addition, you define a hosted service component to execute application code.In My Projects, locate the project where you will deploy the application and click the Project Name link to view the list of services under it.Note: The items in this list are projects associated with your Windows Live ID. Following commercial launch, you will see every project that you have purchased listed here.Figure 6Available projects in your Windows Azure accountFirst, you create the storage account that the application will use to store its data. In the Windows Azure Summary page, click New Service.Figure 7Creating a new Windows Azure serviceIn the Windows Azure Summary page, click Storage Account. Figure 8Creating a new Windows Azure storage accountEnter the Service Component Label and Service Component Description and click Next to proceed. The values you enter here allow you to identify the account storage component in the portal user interface.Figure 9Configuring the service component propertiesIn the Storage Account Name section, enter the name for your storage account, for example, <yourname>todo, where <yourname> is a unique name. Windows Azure uses this value to generate the endpoint URLs for the storage account services. To ensure that the name is valid, click Check Availability to verify that the name satisfies the naming rules and is currently available.Note: The name used for the storage account corresponds to a DNS name and is subject to standard DNS naming rules. Moreover, the name is publicly visible and must therefore be unique.In the Storage Account Affinity Group section, click "Yes, this service is related to some of my other hosted services or storage accounts and needs to be stored in the same region." and then select the "Create a new Affinity Group Region" option. Set the value of the affinity group to the label mytodo and choose the region where you wish your service to run, most likely, the one that is closest to your current location.Figure 10Configuring the storage account URL and affinity groupNote: The reason that you are creating a new affinity group is to deploy both the hosted service and storage account to the same location, thus ensuring high bandwidth and low latency between the application and the data it depends on.Click Create to register your new storage account. Wait until the account provisioning process completes and updates the Summary page. Notice the available Endpoints and the Access Keys assigned to the storage account. Record the Storage Account Name and the value assigned to the Primary Access Key. You will use these values later on to configure the application.Note: The Endpoints specify the URLs of the blob, queue, and table storage services for this account.The Primary Access Key and Secondary Access Key both provide a shared secret that you can use to access storage. The secondary key gives the same access as the primary key and is used for backup purposes. You can regenerate each key independently in case either one is compromised.Figure 11Successful creation of the storage accountNext, create the compute component that executes the application code. Click New Service once again to create a hosted services account for the application. In the Project section, click Hosted Services.Figure 12Creating a new hosted serviceEnter the Service Label and Service Description and click Next to proceed. The values you enter here allow you to identify the hosted service in the portal user interface.Figure 13Configuring the service propertiesIn the Hosted Service URL section, enter the name for your hosted service, for example, <yourname>todo, where <yourname> is a unique name. Windows Azure uses this value to generate the endpoint URL of the hosted service. To ensure that the name is valid, click Check Availability to verify that the name satisfies the naming rules and is currently available.Note: If possible, choose the same name for both the storage account and hosted service. However, you may need to choose a different name if the one you select is unavailable.In the Storage Account Affinity Group section, click "Yes, this service is related to some of my other hosted services or storage accounts and needs to be stored in the same region." and then select the "Use existing Affinity Group Region" option. Select mytodo in the affinity group drop down list; this is the affinity group that you created earlier.Note: By choosing mytodo as the affinity group, you ensure that the hosted service is deployed to the same data center as the storage account that you provisioned earlier.Figure 14Configuring the hosted service URL and affinity groupClick Create to register the hosted service and wait until the provisioning process completes.Task 3 – Deploying the Application to the Windows Azure Developer PortalA hosted service is a service that runs your code in the Windows Azure environment. It has two separate deployment states: staging and production. A staging deployment allows you to test your service in the Windows Azure environment before you deploy it to production. In this task, you create a service package for the myTODO application and then deploy it to the staging environment using the Windows Azure Developer Portal.Open Microsoft Visual Studio 2008 in elevated administrator mode, in Start | All Programs | Microsoft Visual Studio 2008, by right clicking the Microsoft Visual Studio 2008 shortcut and choosing Run as Administrator.In the File menu, choose Open and then Project/Solution. In the Open Project dialog, browse to Ex01-DeployingUsingWAZPortal\Begin in the Source folder of the lab, select MyTodo.sln in the folder for the language of your preference (Visual C# or Visual Basic) and click Open.The solution contains the following projects:MyTodoA standard cloud service project configured to support a single web role named MyTodo.WebUxMyTodo.Data.WindowsAzureA class library project that contains data contracts for the MyTodo.WebUx application for table storageAspProvidersAn implementation of Membership, Role, and SessionState providers for Azure StorageMyTodo.WebUxA web role that hosts the MyTODO MVC application in Windows AzureEnsure that the System.Web.MVC assembly is included in the service package that you deploy to Windows Azure. To do this, for a Visual C# project, expand the References node in Solution Explorer for the MVCAzureStore project, right-click the System.WebMVC assembly and select Properties. For a Visual Basic project, right-click the MVCAzureStore project and select Properties. In the Project Properties window, switch to the References tab, select the System.Web.MVC assembly, and press F4. To add the assembly to the service package, in the Properties window for the System.Web.Mvc assembly, change the value of the Copy Local setting to True.Figure 6Including assemblies in the service package deployed to Windows AzureNote: In general, you need to set Copy Local = True for any assembly that is not installed by default in the Windows Azure VMs to ensure that it is deployed with your application. To create a service package, right-click the cloud service project and select Publish. This opens Windows Explorer to the Publish folder in your solution folders, and opens up the Windows Azure Developer Portal in your browserOpen the Summary page for the project that you created in the previous task.In the hosted service Summary page, click Deploy to upload the service package to the portal.Figure 15Hosted service summary pageIn the Staging Deployment page, under the App Package section, click "Upload a file from your local storage" to select it. Click Browse to navigate to the Publish folder in your solution, which should already be open in a Windows Explorer window, and select MyTodo.cspkg. Note: The .cspkg file is an archive file that contains the binaries and files required to run a service, in this case, the myTODO MVC application. Visual Studio 2008 creates the service package for you when you select Build | Publish for your cloud project.In the Configuration Settings section, once again select "Upload a file from your local storage", click Browse and select ServiceConfiguration.cscfg using the same folder that you used in the previous step.Note: The .cscfg file contains configuration settings for the application, including storage settings that you will update later in the exercise.Finally, in the Properties section, enter a label to identify the deployment; for example, use v1.0.Note: The portal displays the label in its user interface for staging and production, which allows you to identify the version currently deployed in each environment.Figure 16Configuring service package deploymentClick Deploy to start uploading the package to the Windows Azure Developer Portal. Figure 17Uploading a service package to the Windows Azure Developer PortalWait until the deployment process finishes, which may take several minutes. At this point, you have already uploaded the package and it is in an Allocated state. Notice that the portal assigned this deployment a Web Site URL that includes a unique identifier. Shortly, you will access this URL to test the application and determine whether it operates correctly in the Windows Azure environment, but first you need to configure it.Note: During deployment, Windows Azure analyzes the configuration file and copies the service to the correct number of machines, ready to start. Load balancers, network devices and monitoring are also configured during this time.Figure 18Package successfully deployedTask 4 – Configuring the Application to Use the Storage AccountBefore you can test the deployed application, you need to configure it. In this task, you define the storage account settings for the application.In the Summary page, under the Hosted Service section, click Configure for the Staging environment.Figure 19Configuring application settingsIn the Service Tuning page, under Configuration Settings, update the value of the AccountName setting by replacing the placeholder labeled [YOUR_ACCOUNT_NAME] with the Storage Account Name that you chose when you configured the storage account in Task 2. If you followed the recommendation, the name should follow the pattern <yourname>todo, where <yourname> is a unique name.Next, update the AccountSharedKey setting by replacing the placeholder labeled [YOUR_ACCOUNT_KEY] with the Primary Shared Key value that you recorded earlier when you created the storage account in Task 2.Finally, locate the Instances element and change the count attribute to a value of 2.Note: The Instances setting controls the number of roles that Windows Azure starts and is used to scale the service. Currently, it is limited to a maximum of two instances. However, once the service is commercially available, you will be able to change it to any number that you are willing to pay for.Figure 20Setting the storage account name and shared keyNote: The configuration is simply an XML document that contains the value of the settings declared in the service definition file and its initial content is determined by the ServiceConfiguration.cscfg file that you uploaded earlier when you deployed the package in Task 3.Click Save to update the configuration and wait for the hosted service to apply the new settings. Note: The portal displays a legend "Package is updating..." while the settings are applied.Task 5 – Testing the Application in the Staging EnvironmentIn this task, you run the application in the staging environment and access its Web Site URL to test that it operates correctly.In the Summary page, under the Hosted Service section, click Run for the deployment in the Staging environment. Figure 21Running the application in the staging environmentWait until the status of the service is shown first as Initializing and then as Ready.Note: The process may take several minutes during which Windows Azure provisions servers, load balancers and other network devices, as well as preparing to monitor the application. Once the application is running, it takes care of patching the OS, recovering from hardware failure, and ensuring that storage is available.Figure 22Application initialization processOnce the service has started, click the Web Site URL link to open a new browser window that points to the application. Note: The address URL is shown as <guid>., where <guid> is some random identifier. This is different from the address where the application will run once it is in production. Although the application executes in a staging area that is separate from the production environment, there is no actual physical difference between staging and production – it is simply a matter of where the load balancer is connected.In the future, you will be able to have multiple “virtual” areas, for test, QA, pre-production, etc... Click Start to prepare the application for first time use, which requires you to register a new account.Figure 23Application running in the staging environmentComplete the account details by entering a user name, email address, and password and then click Register. You can omit the remaining fields for this test.Note: Account information is stored in the storage account created earlier. Data is not shared between to do lists.Figure 24Creating a new accountNext, the application enumerates the lists that you have currently defined. Since this is your first use, no lists should appear.Figure 25Application ready to be usedIf you wish to explore the application, create a new TODO list and enter some items. Task 6 – Promoting the Application to ProductionNow that you have verified that the service is working correctly in the staging environment, you are ready to promote it to final production. When you deploy the application to production, Windows Azure reconfigures its load balancers so that the application is available at its production URL.In the Summary page, under the Hosted Service section, click the Swap button (this is the circular button located between the Production and Staging areas). When prompted, click OK to confirm that you wish to promote to the production deployment.Figure 26Promoting the application to the production deploymentWait for the promotion process to complete, which typically takes a few seconds. Notice that the Production service status is now shown as Ready and that the Web Site URL corresponds to the URL that you chose earlier, when you configured the hosted service in Task 2.Figure 27Application successfully deployed to productionClick the Web Site URL link to open the production site in a browser window and notice the URL in the address bar.Figure 28Application running in the production environmentNote: If you visit the production site shortly after its promotion, the DNS name might not be ready. If you encounter a DNS error (404), wait a few minutes and try again. Keep in mind that Windows Azure creates DNS name entries dynamically and that the changes might take few minutes to propagate.Exercise 2 - Using PowerShell to Manage Windows Azure ApplicationsTypically, during its lifetime, an application undergoes changes that require it to be re-deployed. In the previous exercise, you saw how to use the Windows Azure Developer Portal to deploy applications. As an alternative, the Service Management API provides programmatic access to much of the functionality available through the Developer Portal. Using the Service Management API, you can manage your storage accounts and hosted services, your service deployments, and your affinity groups.The Windows Azure Service Management PowerShell Cmdlets wrap the Windows Azure Service Management API. These cmdlets make it simple to automate the deployment, upgrade, and scaling of your Windows Azure application. By pipelining commands, you compose complex scripts that use the output of one command as the input to another.In this exercise, you will learn how to deploy and upgrade a Windows Azure application using the Azure Services Management Cmdlets. Task 1 – Generating a Self-Signed Certificate (Optional) To ensure that access to the Service Management API is secure, you must first associate a certificate with your subscription. The management service uses the certificate to authenticate requests. You can use a self-signed certificate or one signed by a certification authority. Any valid X.509 v3 is suitable as long as its key length is at least 2048 bits.In this task, you generate a certificate that you can upload to the Windows Azure Developer Portal. This step is optional if you already have a certificate signed by a certificate authority. Open a Visual Studio 2008 Command Prompt in elevated administrator mode, from Start | All Programs | Microsoft Visual Studio 2008 | Tools by right clicking the Visual Studio 2008 Command Prompt shortcut and choosing Run as Administrator.Change the current directory to the location where you wish to store your certificate file.At the prompt, type the following command to generate a local certificate file. Visual Studio Command Promptmakecert -r –pe -n "CN=AzureMgmt" -a sha1 -len 2048 -ss My "AzureMgmt.cer"Note: This command creates a new self-signed certificate with a key length of 2048 bits, writes it to the "AzureMgmt.cer" file in the current directory and saves it to the My certificate store for the current user. Task 2 – Preparing the Windows Azure AccountTo use the Windows Azure Service Management API, you have to upload the certificate to your Windows Azure account to provide the required authentication. In addition, the management API, and the PowerShell cmdlets that wrap it, require you to provide several pieces of information, including the name of your service, the thumbprint of the certificate, and the subscription ID of your Windows Azure account.In this task, you upload the certificate to your Windows Azure Account and obtain the required information, including the certificate thumbprint and the subscription ID. Navigate to using a Web browser and sign in using your Windows Live ID. Figure 29Signing in to the Windows Azure portalSelect the Account tab and then click Manage My API CertificatesFigure 30Managing API certificates in the Windows Azure Developer PortalUpload the new certificate from your local storage. To do this, select Browse, locate the certificate file in your local disk and then click Upload. Note that you can only associate a maximum of five certificates with your subscription. Figure 31Uploading a certificate to the Windows Azure Developer PortalNote: The Service Management API accepts any valid X.509 v3 certificate for authentication purposes provided its key length is at least 2048 bits. You can use the self-signed certificate you created in the previous task or one signed by a certificate authority. If you submit a self-signed certificate immediately after you generate it, the Windows Azure portal could reject it due to timing differences with your computer if the server’s time is ahead of the Valid From date of the certificate. If you receive a ”Certificate is not yet valid” error when you upload the certificate, you can either wait a few minutes to account for the time skew and re-submit the certificate or use makecert to generate a new certificate that specifies a validity period with a start date that is in the past.Make a note of the value shown in the Thumbprint column for the certificate that you just installed.Select the Account tab in the Developer Portal UI and record the value shown for Subscription ID under Support Information.Figure 32Determining the subscription ID for a Windows Azure accountSelect the Summary tab for your hosted service. You can retrieve the service name from the Web Site URL shown in this page, which has the format 33Retrieving the name of the hosted serviceNote: You will use the certificate Thumbprint, account Subscription ID, and Service Name in the next task, when you deploy the service package.Task 3 – Uploading a Service Package Using Windows PowerShellIn the previous exercise, you uploaded the service package for the myTODO application using the Windows Azure Developer Portal. In this task, you deploy the package using the Windows Azure Service Management PowerShell cmdlets instead. If it is not already open, launch Microsoft Visual Studio 2008 in elevated administrator mode, from Start | All Programs | Microsoft Visual Studio 2008 by right clicking the Microsoft Visual Studio 2008 shortcut and choosing Run as Administrator.In the File menu, choose Open and then Project/Solution. In the Open Project dialog, browse to Ex02-DeployingUsingPSCmdlets\Begin in the Source folder of the lab, select MyTodo.sln in the folder for the language of your preference (Visual C# or Visual Basic) and click Open.Configure the storage account connection strings. To do this, expand the Roles node in the MyTodo project and double-click the MyTodo.WebUX role. In the role properties window, select the Settings tab, select the DataConnectionString setting, ensure that the Type is set to ConnectionString, and then click the button labeled with an ellipsis.Figure 34Defining storage account connection settingsIn the Storage Connection String dialog, choose the Enter storage credentials option. Complete your storage Account Name and storage Account Key and click OK.Figure 35Configuring the storage account name and account keyNote: This information is available in the Summary section of your storage account in the Windows Azure Developer Portal. You used the same settings in Exercise 1, when you deployed and configured the application. In that instance, because you were running the application in Windows Azure, you updated the configuration at the Developer Portal. Repeat the previous steps to configure the DiagnosticsConnectionString setting using the same account information.Create the service package. To do this, right-click the cloud service project and select Publish. This opens Windows Explorer to the Publish folder in your solution folders, and opens up the Windows Azure Developer Portal in your browser. You do not require the portal to upload the deployment using the PowerShell cmdlets so you may close the browser window.Open a Windows PowerShell command prompt. On Windows Vista, Windows Server 2008, and later versions of Windows, in the Start menu, open All Programs | Accessories | Windows PowerShell, and then select Windows PowerShell. On Windows XP and Windows Server 2003, in the Start menu, open Programs | Accessories | Windows PowerShell, and then select Windows PowerShell.At the PowerShell prompt, enter the following command to add support for the Azure Services Management cmdlets to the current session.PowerShell ConsoleAdd-PSSnapin AzureManagementToolsSnapInChange the current directory to the location where you generated the service package for the myTODO application in Step 6. Next, enter the command shown below. Use the following command line arguments ensuring that you replace the parameter placeholders with the settings that apply to your service account, which you determined in Task 1 of this exercise.PowerShell ConsoleNew-Deployment -serviceName <YOUR_SERVICE_NAME_LOWER_CASE> -subscriptionId <YOUR_SUBSCRIPTION_ID> -certificate (get-item cert:\CurrentUser\MY\<YOUR_CERTIFICATE_THUMPRINT>) -slot staging –package <PACKAGE_LOCATION> -configuration <CONFIGURATION_LOCATION> -label "v2.0"<YOUR_SERVICE_NAME_LOWER_CASE>The service name chosen when configuring the hosted service URL in Exercise 1, not its Service Label. <YOUR_SUBSCRIPTION_ID>The subscription ID of the Windows Azure account where the service will be deployed.<YOUR_CERTIFICATE_THUMPRINT>The thumbprint value (in upper case) for the certificate uploaded previously.< PACKAGE_LOCATION>A path to a local file or the URL of the blob in Azure Storage that contains the service package. < CONFIGURATION_LOCATION>A path to a local file or the public URL of the blob that contains the service configuration file.Note: The command shown above uses the New-Deployment cmdlet to upload a service package and create a new deployment in the staging environment. It assigns a "v2.0" label to identify this deployment.Note that the certificate parameter expects a certificate object. In order to retrieve the required certificate, you can use get-item and the PowerShell certificate provider to obtain the certificate given its thumbprint value. Be aware that you need to specify the thumbprint in upper case for this method to succeed. For example, to deploy a hosted service named “yournametodo”, using an account with a subscription ID of 12abb234-45c9-4b37-8179-e7d88617cb5e, a certificate thumbprint 6062B026CF12FE6CD1E3A2CE22893E5CD1DA59C7, for a package named MyTodo.cspkg and a configuration file named ServiceConfiguration.cscfg stored in the current directory, and to assign this deployment a label v2.0, use the following command. Figure 36New-Deployment command linePress ENTER to execute the command. Because New-Deployment is an asynchronous operation, the command returns immediately. Meanwhile, the operation continues in the background.Figure 37Deploying a new service package to Windows Azure using PowerShellIn the Windows Azure Developer Portal, open the Summary page and notice how the deployment for the staging environment shows its status with the message "Package is updating..." in the UI. It may take a few seconds for the service status to refresh. Wait for the deployment operation to complete and display the status as Allocated.Note: Normally, you will not use the portal to view the status and determine the outcome of your deployment operations. Here, it is shown to highlight the fact that you can use the management API to execute the same operations that are available in the portal. In the next task, you will see how to use a cmdlet to wait for the operation to complete and retrieve its status.Keep the Microsoft Visual Studio 2008 and PowerShell console open. You will need them for the next task.Task 4 – Upgrading a Deployment Using Windows PowerShellIn this task, you use the Windows Azure Service Management PowerShell cmdlets to upgrade an existing deployment. First, you change the original solution by making minor changes to its source code to produce an updated version of the application. Next, you build the application and create a new service package that contains the updated binaries. Finally, using the management cmdlets, you re-deploy the package to Windows Azure. Go back to Microsoft Visual Studio 2008. Open the master page of the application for editing. To do this, in Solution Explorer, double-click Site.Master in the Views\Shared folder of the MyTodo.WebUx project. Switch to source mode.Insert a new caption in the footer area of the page. Go to the bottom of the master page and update the copyright notice with the text “(Deployed with the PowerShell CmdLets)” as shown below.HTML... </div> <div id="footer"> <hr /> <p class="copyright"> &copy; 2009 Microsoft Corporation. All rights reserved. (Deployed with the PowerShell CmdLets)</p> <p class="powered"><a href=""><img src="<%=Url.Content("~/Content/images/powered-by-azure.png")%>" width="188" height="38" alt="Powered by Windows Azure" /></a></p> </div> <asp:ContentPlaceHolder ID="ScriptsContent" runat="server" /> </div></body></html>Generate a new service package. To do this, in Solution Explorer, right-click the MyTodo project and select Publish. This creates the .cspkg file with all the service components, opens Windows Explorer to the Publish folder in your solution folders and opens up the Windows Azure Developer Portal in your browser. You can close the browser window because you are not going to use it.Switch to the PowerShell console and enter the command shown below, specifying the settings that apply to your service account where indicated by the placeholder parameters. Do not execute the command yet.PowerShell ConsoleGet-HostedService <YOUR_SERVICE_NAME> -subscriptionId <YOUR_SUBSCRIPTION_ID> -certificate (get-item cert:\CurrentUser\MY\<YOUR_CERTIFICATE_THUMPRINT>) | Get-Deployment staging | Set-Deployment -package <PACKAGE_LOCATION> -label "v2.1"<YOUR_SERVICE_NAME_LOWER_CASE>The service name chosen when configuring the hosted service URL in Exercise 1, not its Service Label. <YOUR_SUBSCRIPTION_ID>The subscription ID of the Windows Azure account where the service will be deployed.<YOUR_CERTIFICATE_THUMPRINT>The thumbprint value (in upper case) for the certificate uploaded previously.< PACKAGE_LOCATION>A path to a local file or the URL of the blob in Azure Storage that contains the service package. The command line shown above concatenates a sequence of cmdlets. First, it obtains a reference to the hosted service using Get-HostedService, then it uses Get-Deployment to retrieve its staging environment, and finally it uploads the package using Set-Deployment. This is done to illustrate how to compose a complex command using the PowerShell pipeline. In fact, in this particular case, you could instead provide all the required information to Set-Deployment to achieve the same result. For example:Set-Deployment -subscriptionId <YOUR_SUBSCRIPTION_ID> -certificate <YOUR_CERTIFICATE> -serviceName <YOUR_SERVICE_NAME_LOWER_CASE> -slot staging -package <PACKAGE_LOCATION> -label <LABEL> If you were to run the command as described above, the operation runs asynchronously. To show the operation’s progress while the deployment is taking place, you can pipe the output of the command into the Get-OperationStatus cmdlet and specify the WaitToComplete parameter. Add this cmdlet to the end of the command line entered previously making sure that you include the pipeline character ‘|’, as shown below. PowerShell ConsoleGet-HostedService <YOUR_SERVICE_NAME_LOWER_CASE> -subscriptionId <YOUR_SUBSCRIPTION_ID> -certificate (get-item cert:\CurrentUser\MY\<YOUR_CERTIFICATE_THUMPRINT>) | Get-Deployment staging | Set-Deployment -package <PACKAGE_LOCATION> -label "v2.1" | Get-OperationStatus -WaitToCompleteFigure 38Using the PowerShell pipeline to upgrade a deploymentPress ENTER to execute the command. Wait until the deployment process finishes, which may take several minutes. When the operation ends, it displays a message with the outcome of the operation; if the deployment completed without errors, you will see the message “Succeeded”. Figure 39PowerShell console showing the status of the package deployment operationNote: Deploying a package using the steps described above does not change its state. If the service is not running prior to deployment, it will remain in that state. To start the service, you need to update its deployment status using the Set-DeploymentStatus cmdlet.To change the status of the service to a running state, in the PowerShell console, enter the following command.PowerShell ConsoleGet-Deployment staging -serviceName <YOUR_SERVICE_NAME_LOWER_CASE> -subscriptionId <YOUR_SUBSCRIPTION_ID> -certificate (get-item cert:\CurrentUser\MY\<YOUR_CERTIFICATE_THUMPRINT>) | Set-DeploymentStatus running | Get-OperationStatus –WaitToCompleteFinally, swap the deployments in the staging and production environments. To do this, in the PowerShell console, use the Get-Deployment and Move-Deployment cmdlets, as shown below, ensuring that you replace the placeholder parameters, <YOUR_SERVICE_NAME>, <YOUR_SUBSCRIPTION_ID>, and <YOUR_CERTIFICATE_THUMBPRINT> with the same values used previously, when you deployed the package.PowerShell ConsoleGet-HostedServices -subscriptionId <YOUR_SUBSCRIPTION_ID> -certificate (get-item cert:\CurrentUser\MY\<YOUR_CERTIFICATE_THUMPRINT>) | where {$_.ServiceName –eq “<YOUR_SERVICE_NAME>”} | Get-Deployment staging | Move-Deployment | Get-OperationStatus –WaitToCompleteVerification Now that you have deployed your updated solution to Window Azure, you are now ready to test it. You will launch the application to determine if the deployment succeeded and ensure that the service is working correctly and is available at its production URL. In the Summary page of the development portal, under the Hosted Service section, click the Web Site URL link to open the production site in a browser window. Notice the footer of the page. It should reflect the updated text that you entered in the last task.Figure 40New deployment showing the updated footer textNote: If you visit the production site shortly after its promotion, the DNS name might not be ready. If you encounter a DNS error (404), wait a few minutes and try again. Keep in mind that Windows Azure creates DNS name entries dynamically and that the changes might take few minutes to propagate.Exercise 3 - Monitoring Applications in Windows AzureWindows Azure Diagnostics allow you to collect rich diagnostic data to assist you in trouble shooting your service. It provides support for a variety of diagnostic features including Windows Azure logs, Windows Event logs, IIS logs, Failed Request Tracing (commonly known as FREB) logs, application crash dumps, and performance counters, in addition to Windows Azure Diagnostic Monitor logs with data about the diagnostic feature itself. The diagnostics infrastructure collects data in local storage for every diagnostic type that you enable and can transfer the data it gathers to an Azure Storage account for permanent storage. You can schedule to push the collected data to storage at regular intervals or you can request an on-demand transfer whenever you require this information. You can configure any given instance of a running service using a Diagnostics Management API provided in the Windows Azure SDK, including enabling individual diagnostic features and performing transfers of diagnostics data to Azure Storage. The API allows you to modify the configuration of a service remotely and without interrupting its execution.During this exercise, you will instrument the MyTODO application and monitor its operation. This involves adding performance counters, scheduling tasks to transfer diagnostic data to an Azure Storage account and adding code to manage these operations from outside the cloud, more precisely, from a console application running in your desktop. Task 1 – Configuring Azure Storage for Persisting Diagnostics DataThe myTODO application uses two separate storage settings. The first one, DataConnectionString, points to the storage account for the application's data. In addition, Windows Azure Diagnostics collects data locally for each instance of the application. To store this data permanently, the diagnostics monitor needs a second setting, DiagnosticsConnectionString, to point to the store for the information it gathers. It uses the configured storage account to persist performance counter data and event log information. In this task, you configure the data and diagnostics storage settings for the application. Open Microsoft Visual Studio 2008 in elevated administrator mode, from Start | All Programs | Microsoft Visual Studio 2008 by right clicking the Microsoft Visual Studio 2008 shortcut and choosing Run as Administrator.In the File menu, choose Open and then Project/Solution. In the Open Project dialog, browse to Ex03-Monitoring\Begin in the Source folder of the lab, select MyTodo.sln in the folder for the language of your preference (Visual C# or Visual Basic) and click Open.Now, configure the storage account connection strings for the application data and the diagnostics information it produces. To do this, expand the Roles node in the MyTodo project and double-click the MyTodo.WebUX role. In the role properties window, select the Settings tab, select the DataConnectionString setting, ensure that the Type is set to ConnectionString, and then click the button labeled with an ellipsis. In the Storage Connection String dialog, choose the Enter storage credentials option, complete your storage Account Name and storage Account Key and click OK.Note: This information is available in the Summary section of your storage account in the Windows Azure Developer Portal. You used the same settings in Exercise 1, when you deployed and configured the application. In that instance, because you were running the application in Windows Azure, you updated the configuration at the Developer Portal. Repeat the previous steps to configure the DiagnosticsConnectionString setting using the same account information.Task 2 – Enabling Failed Request TracingFailed Request Tracing produces detailed trace logs according to filters established within a web role’s configuration. You can customize Failed Request Tracing in several ways. You can specify what content to trace, for example, all *.css files or a specific document such as “About”. You can also choose what conditions cause tracing to write a request to the log. This includes a particular response status code (e.g. 401) or a range of codes (e.g. 400-500), an event with a certain severity (e.g. critical), or the time taken to process a request (e.g. all requests that exceed 5 seconds).For more information on Failed Request Tracing, see Troubleshooting Failed Requests Using Tracing in IIS 7.0.In this task, you configure the web role to capture failed request information for all supported trace areas. To do so, you will modify the application to introduce an arbitrary delay into one of its responses and configure a failure condition that causes Failed Request Tracing to write the request to the log when the response time exceeds a specified limit.Note: The development environment supports the use of the Failed Request Tracing feature. To enable it, you must install the Tracing feature in IIS.Open the Web.config file in the MyTodo.WebUx project. Locate the system.webServer section and insert the following tracing section into it, as shown (highlighted) in the following configuration fragment.Web.config<system.webServer> <validation ... /> <modules ... > ... </modules> <handlers> ... </handlers> <tracing> <traceFailedRequests> <add path="*"> <traceAreas> <add provider="ASP" verbosity="Verbose" /> <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" /> <add provider="ISAPI Extension" verbosity="Verbose" /> <add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression,Cache,RequestNotifications,Module" verbosity="Verbose" /> </traceAreas> <failureDefinitions timeTaken="00:00:15" statusCodes="400-599" /> </add> </traceFailedRequests> </tracing></system.webServer>Note: The failureDefintions element shown above will result in logging for any requests that take longer than 15 seconds or that result in a response status code in the range 400 to 599.Now, modify the application to introduce an arbitrary delay when it processes the response to the About page of the application. Open the HomeController.cs file (for C# projects) or HomeController.vb file (for Visual Basic projects) in the Controllers folder of the MyTodo.WebUx project.Locate the About action and insert the following (highlighted) code to temporarily suspend the thread that processes the request for several seconds.C#public ActionResult About(){ System.Threading.Thread.Sleep(18000); return this.View();}Visual BasicPublic Function About() As ActionResult System.Threading.Thread.Sleep(18000) Return Me.View()End Function Press F5 to launch the cloud project in the development fabric.Switch to the development fabric UI and ensure that the service has started successfully. Open the local store to examine the diagnostic files. To do this, in the Development Fabric, expand the Service Deployments tree view to locate the node for the MyTodo.WebUx role, expand this node to display its running instances and right-click the single instance under it to select Open local store.Figure 42Opening the local store in the development fabricNote: Currently, opening the Local Store from the Development Fabric UI is not possible when you log in as non-administrative user, even after launching Visual Studio in elevated mode by providing credentials for the administrator.If you are unable to open the local store from the Development Fabric, execute this task logged in as an administrator or, as an alternative, carry out the following procedure to start the Development Fabric service manually, using a path to the local store that is accessible to the current user.1. If necessary, press SHIFT + F5 to stop the running application.2. Stop the Development Fabric service if it is currently running. To do this, right-click its icon in the task bar and select Shutdown Development Fabric service.3. Open a Windows Azure SDK command prompt elevated as an administrator. In the Start menu, choose All Programs | Windows Azure SDK v1.0, right-click Windows Azure SDK Command Prompt and select Run as administrator.4. At the command prompt, enter bin\devfabric\dfservice -sp "<LOCAL_STORE_PATH>". Replace the placeholder with the path to a folder where you have access, for example, bin\devfabric\dfservice -sp "C:\DevFabric".5. To view the local store, open a Windows Explorer window pointing at the path chosen in the previous step. In this folder, select the subdirectory for?the current deployment, which you can determine from the Service Deployments tree view in the Development Fabric, and navigate to the res\deployment(XXX).MyTodo.MyTodo.WebUx.0 folder. In the folders tree view of the newly opened Windows Explorer window, expand directory | DiagnosticStore | FailedReqLogFiles.Now, make a request that triggers a failure based on the tracing rules that you configured earlier and cause it to be written to the log. To bring this about, click the About link in the browser window to navigate to this page. Recall that you inserted a delay in the processing of the corresponding controller action that is greater than the timeTaken limit set in the tracing configuration.Switch to the Windows Explorer window and expand the FailedReqLogFiles folder where you will find a W3SVC1 folder that contains the log files.Inside this folder, locate the log file corresponding to the failed request to the About page.Note: The W3SVC1 directory contains Failed Request Tracing log files in XML format, one file for each failed request. It should contain at least one log file for the failed request that you induced. A second log file might be present in this folder if the response time for the initial page of the site was greater than the configured limit as the result of a slow start up time of the web role. In addition, the folder contains an XSL style sheet file that allows you to view each log file in an easily comprehensible format. Figure 43Viewing Failed Request Tracing logs in the local storeDouble-click the XML log file in Windows Explorer to open the file in your browser. Notice that the Request Summary tab shows the URL of the failed request as well as a reason for the failure, in this case TIME_TAKEN. The summary also shows the response status code and the time taken to process the request.Figure 44Summary view for the failed requestNote: Each log file contains a wealth of information about a request that can prove invaluable when troubleshooting an application. It is beyond the scope of this lab to analyze this feature in detail but you might want to spend some time examining the various views available in the trace report.(Optional) The failureDefinitions element that you configured in the tracing section of the Web.config file not only specifies a timeTaken attribute to capture requests that exceeded a certain time to be processed, but also includes a statusCodes attribute to log requests that have response status code in the range 400 to 599. To see this in action, enter an invalid URL in the address bar of the browser, for example , and press ENTER. Examine the failed request log file generated as a result of the 404 status code. Notice that this time the failure reason is STATUS_CODE.In addition to failed traced requests, Windows Azure Diagnostics collects Internet Information Server logs by default and stores them locally for each instance of the web role. To view the IIS logs, in Windows Explorer, locate the LogFiles folder inside DiagnosticStore. Inside this folder, you will find a W3SVC1 folder that contains the log files. Figure 45Viewing IIS logs in the local storeOpen any one of the log files in this folder in a text editor, for example, Notepad. Notice that it is a standard IIS log file with details about every request made to the application, including its date and time, the request URL, and the response status.Figure 46Internet Information Server log fileIn this task, you examined several logging features by browsing the information captured locally by the Development Fabric. When you deploy your application to Windows Azure, you will no longer have direct access to these files in the local store. Instead, you need to configure the diagnostics infrastructure to transfer the information to table and blob storage in your Azure Storage account. In the next task, you will see how you can achieve this.Task 3 – Instrumenting a Web RoleUsing the Diagnostics Management API, an application can define the information that it needs to collect at role start up time.In this task, you add code to the myTODO application to enable Windows Azure logs and set up a transfer schedule that automatically copies the logs to an Azure Storage account at regular intervals. In addition, you enable logging and use the standard .NET tracing API to write messages to the log.Open the WebRole.cs file (for C# projects) or WebRole.vb file (for Visual Basic projects) in the MyTodo.WebUx project. This file contains the role entry point of the web role.In the OnStart method of WebRole class, first delete the call to DiagnosticsMonitor.Start at the start of the method and then insert the following (highlighted) code to replace it. This code schedules the transfer of the error logs produced in the web role to Azure Storage.(Code Snippet – Deploying and Monitoring Application in Windows Azure - Ex 3 Web Role Diagnostic Monitor Configuration – C#) C#public override bool OnStart(){ // Get the factory configuration so that it can be edited DiagnosticMonitorConfiguration config = DiagnosticMonitor.GetDefaultInitialConfiguration(); // Set scheduled transfer interval for infrastructure logs to 1 minute config.DiagnosticInfrastructureLogs.ScheduledTransferPeriod = System.TimeSpan.FromMinutes(1); // Specify a logging level to filter records to transfer config.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter = LogLevel.Error; // Set scheduled transfer interval for user's Windows Azure Logs to 1 minute config.Logs.ScheduledTransferPeriod = System.TimeSpan.FromMinutes(1); DiagnosticMonitor.Start("DiagnosticsConnectionString", config); RoleEnvironment.Changing += this.RoleEnvironmentChanging; ... return base.OnStart();}(Code Snippet – Deploying and Monitoring Application in Windows Azure - Ex 3 Web Role Diagnostic Monitor Configuration – VB)Visual BasicPublic Overrides Function OnStart() As Boolean ' Get the factory configuration so that it can be edited Dim config As DiagnosticMonitorConfiguration = DiagnosticMonitor.GetDefaultInitialConfiguration() ' Set scheduled transfer interval for infrastructure logs to 1 minute config.DiagnosticInfrastructureLogs.ScheduledTransferPeriod = System.TimeSpan.FromMinutes(1) ' Specify a logging level to filter records to transfer config.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter = LogLevel.Error ' Set scheduled transfer interval for user's Windows Azure Logs to 1 minute config.Logs.ScheduledTransferPeriod = System.TimeSpan.FromMinutes(1) DiagnosticMonitor.Start("DiagnosticsConnectionString", config) AddHandler RoleEnvironment.Changing, AddressOf RoleEnvironmentChanging CloudStorageAccount.SetConfigurationSettingPublisher(Function(configName, configSetter) AnonymousMethod1(configName, configSetter)) Return MyBase.OnStart()End FunctionNote: For projects created in Visual Studio, the role template generates code to initialize the Diagnostic Monitor with default settings. Typically, you will not need to change these settings, as you would normally request an on-demand transfer of diagnostics information whenever you require it for troubleshooting purposes.In the code shown above, the role uses custom settings to set up a schedule that transfers the Windows Azure and Diagnostics Infrastructure logs to storage once every minute and creates a logging level filter to select only those records with an error level equal to or greater than Error. Setting up an automatic transfer schedule in this manner allows you to examine the information contained in the Azure Storage diagnostic tables later in the exercise. Next, update the application to write a warning to the log whenever a user fails authentication using the standard .NET tracing API in System.Diagnostics. To do this, open AccountMembershipService.cs (for Visual C# projecs) or AccountMembershipService.vb (for Visual Basic projects) in the Authentication folder of the MyTodo.WebUx project, locate the ValidateUser method and replace its body with the following (highlighted) code.(Code Snippet – Deploying and Monitoring Application in Windows Azure - Ex 3 ValidateUser method – C#)C#public bool ValidateUser(string userName, string password){ bool valid = this.provider.ValidateUser(userName, password); if (!valid) { System.Diagnostics.Trace.TraceWarning("Invalid login: {0}", userName); } return valid;}(Code Snippet – Deploying and Monitoring Application in Windows Azure - Ex 3 ValidateUser method – VB)Visual BasicPublic Function ValidateUser(ByVal userName As String, ByVal password As String) As Boolean Implements IMembershipService.ValidateUser Dim valid As Boolean = Me.provider.ValidateUser(userName, password) If (Not valid) Then System.Diagnostics.Trace.TraceWarning("Invalid login: {0}", userName) End If Return validEnd FunctionNote: The updated method writes a warning event to the log whenever the authentication module detects a failed login attempt.Finally, enable tracing in the configuration file by configuring a trace listener specific to Windows Azure Diagnostics. To configure the listener, open the Web.config file in the MyTodo.WebUx project and insert the following (highlighted) configuration block.Web.config<configuration> ... <system.diagnostics> <trace autoflush="false" indentsize="4"> <listeners> <add name="AzureDiagnostics" type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> </listeners> </trace> </system.diagnostics></configuration>Note: The System.Diagnostics.Trace class provides a set of methods and properties that help you trace the execution of your code. To use the methods in this class to record information in the Windows Azure logs, you need to configure a trace listener specific to Windows Azure in the system.diagnostics section of the configuration file (Web.config file for a web role or App.config file for a worker role).This step is usually unnecessary for roles created in Visual Studio because they already include the necessary settings in their role templates.Press F5 to build and run the application in the development fabric.Note: In this task, for convenience, you execute the application locally in the development fabric but you configure it to use Azure Storage. Instead, you may wish to deploy the application and run it in Windows Azure. In that case, use the procedure that you learnt in Exercise 1 to deploy the application using the Windows Azure Developer Portal or, alternatively, take advantage of the PowerShell cmdlets from the Windows Azure Service Management tools that you saw in Exercise 2 to do the same thing.In the browser window, click Sign In. In the Log On page, enter any username and password and attempt to sign in using invalid credentials. Recall that previously, you modified the application to log a warning for authentication failures.Figure 47Signing in to the application with invalid credentialsSwitch to the Development Fabric UI and display the log for the web role to verify that the failed login attempt resulted in a warning message in the log.Figure 48Web role log showing the failed login attemptNext, examine the logs that the Diagnostics Monitor pushes to Windows Azure table storage. To do this, you will take advantage of the Windows Azure TableBrowser, which is a publicly available Web application that allows you to browse your Azure Storage tables and create, edit, delete, and copy entities. To use it, open your browser and navigate to the home page for the TableBrowser, enter the Account Name and Primary Access Key of your Azure Storage account and click Log In. Specify the same settings that you used previously, when you configured the DiagnosticConnectionString setting for the web role.Figure 49Signing in to the Windows Azure TableBrowser toolAfter you sign in, the tool presents you with a list of tables in your account. There should be at least five tables. The first three contain information for the providers used by the application. The remaining two tables hold the log information that the Diagnostics Manager transferred based on the schedule configured in the OnStart method of the web role.MembershipContains membership information for the Azure TableStorageMembershipProvider.RolesContains role information for the Azure TableStorageRoleProvider.SessionsContains session information for the TableStorageSessionStateProvider.WADInfrastructureLogsTableContains logs from the diagnostic infrastructure, which help the user troubleshoot issues with the diagnostic monitoring system itself.WADLogsTableContains the logs generated by the application using the standard .NET tracing API.Figure 50Table storage showing the application and diagnostics tablesClick the link for the WADLogsTable to examine its content. This table holds the application logs. It should contain at least one row corresponding to the failed login attempt. To expand or collapse the contents of the row, click the green / red icon to its left. Notice the Message column showing the information logged by the TraceInformation call that you added to the ValidateUser method earlier in the task.Figure 51Log message showing the failed login attemptTask 4 – Monitoring Azure Services RemotelyThe Diagnostics Management API allows you to change the diagnostics configuration of any role instance in a running service from outside the cloud, without stopping the service. This includes adding performance counters, collecting Windows Event and other custom logs, and triggering the transfer of diagnostics information to Azure Storage.In this task, you execute a console application in your desktop to update the role diagnostic configuration and add a performance counter. Then, you use the same tool to trigger an on-demand transfer of the collected performance data to Azure Storage. You can find the source code for the diagnostics tool in the MyTodo.Diagnostics.Client project of the solution.Figure 52Console application to configure diagnostics for an Azure Service remotelyOpen the AzureDiagnosticConfiguration.cs file (for C# projects) or AzureDiagnosticConfiguration.vb file (for Visual Basic projects) in the MyTodo.Diagnostics.Client project.Implement the AddPerformanceCounter method by inserting code that uses the Diagnostics Management API to add a performance counter to the configuration of an Azure Service. (Code Snippet – Deploying and Monitoring Application in Windows Azure - Ex3 Add Performance Counter – C#) C#public void AddPerformanceCounter(PerformanceCounterConfiguration performanceCounter){ // Create a new DeploymentDiagnosticManager for the given deployment id var diagnosticManager = new DeploymentDiagnosticManager(this.storageAccount, this.deploymentId); // Get the role instance diagnostics manager for all instance of the role var roleInstanceManagers = diagnosticManager.GetRoleInstanceDiagnosticManagersForRole(this.roleName); // Set the new configuration for each instance of the role foreach (var roleInstanceManager in roleInstanceManagers) { DiagnosticMonitorConfiguration diagnosticConfiguration = roleInstanceManager.GetCurrentConfiguration(); // Add the new performance counter to the configuration diagnosticConfiguration.PerformanceCounters.DataSources.Add(performanceCounter); // Update the configuration roleInstanceManager.SetCurrentConfiguration(diagnosticConfiguration); }}(Code Snippet – Deploying and Monitoring Application in Windows Azure - Ex3 Add Performance Counter – VB)Visual BasicPublic Sub AddPerformanceCounter(ByVal performanceCounter As PerformanceCounterConfiguration) ' Create a new DeploymentDiagnosticManager for the given deployment id Dim diagnosticManager = New DeploymentDiagnosticManager(Me.storageAccount, Me.deploymentId) ' Get the role instance diagnostics manager for all instance of the role Dim roleInstanceManagers = diagnosticManager.GetRoleInstanceDiagnosticManagersForRole(Me.roleName) ' Set the new configuration for each instance of the role For Each roleInstanceManager In roleInstanceManagers Dim diagnosticConfiguration As DiagnosticMonitorConfiguration = roleInstanceManager.GetCurrentConfiguration() ' Add the new performance counter to the configuration diagnosticConfiguration.PerformanceCounters.DataSources.Add(performanceCounter) ' Update the configuration roleInstanceManager.SetCurrentConfiguration(diagnosticConfiguration) Next roleInstanceManagerEnd SubNote: The code obtains a reference to the Diagnostics Manager for all instances of a role, then loops through each instance adding a new performance counter to the role instance configuration, and then saves the changes. When you execute the diagnostics tool specifying the AddPerformanceCounter operation in its command line, it invokes this method to add the new performance counter and update the diagnostics configuration of the service.Next, in the AzureDiagnosticConfiguration class, implement the PerformOnDemandTransfer method to transfer all diagnostic data from the local storage of the role instance to Azure Storage. (Code Snippet – Deploying and Monitoring Application in Windows Azure - Ex3 PerformOnDemandTransfer – C#)C#public void PerformOnDemandTransfer(DataBufferName dataBufferName){ // Create a new DeploymentDiagnosticManager for the given deployment id var diagnosticManager = new DeploymentDiagnosticManager(this.storageAccount, this.deploymentId); // Get the role instance diagnostics manager for all instance of the a role var roleInstanceManagers = diagnosticManager.GetRoleInstanceDiagnosticManagersForRole(this.roleName); var transferOptions = new OnDemandTransferOptions(); transferOptions.From = DateTime.UtcNow - TimeSpan.FromMinutes(5); transferOptions.To = DateTime.UtcNow; transferOptions.NotificationQueueName = this.transferQueueName .ToLowerInvariant(); var queueClient = this.storageAccount.CreateCloudQueueClient(); queueClient.RetryPolicy = RetryPolicies.Retry(3, TimeSpan.FromSeconds(1)); var queue = queueClient.GetQueueReference(transferOptions.NotificationQueueName); queue.CreateIfNotExist(); foreach (var roleInstanceManager in roleInstanceManagers) { CancelAllPreviousTransfers(roleInstanceManager); // Start the transfer for each instance of the role roleInstanceManager.BeginOnDemandTransfer(dataBufferName, transferOptions); // Poll the feedback queue every 15 sec for 10 min to see if the transfer is complete. PollAndConfirmTransfer(roleInstanceManager, queue); }}(Code Snippet – Deploying and Monitoring Application in Windows Azure - Ex3 PerformOnDemandTransfer – VB)Visual BasicPublic Sub PerformOnDemandTransfer(ByVal dataBufferName As DataBufferName) ' Create a new DeploymentDiagnosticManager for the given deployment id Dim diagnosticManager = New DeploymentDiagnosticManager(Me.storageAccount, Me.deploymentId) ' Get the role instance diagnostics manager for all instance of the a role Dim roleInstanceManagers = diagnosticManager.GetRoleInstanceDiagnosticManagersForRole(Me.roleName) Dim transferOptions = New OnDemandTransferOptions() transferOptions.From = DateTime.UtcNow - TimeSpan.FromMinutes(5) transferOptions.To = DateTime.UtcNow transferOptions.NotificationQueueName = Me.transferQueueName.ToLowerInvariant() Dim queueClient = Me.storageAccount.CreateCloudQueueClient() queueClient.RetryPolicy = RetryPolicies.Retry(3, TimeSpan.FromSeconds(1)) Dim queue = queueClient.GetQueueReference(transferOptions.NotificationQueueName) queue.CreateIfNotExist() For Each roleInstanceManager In roleInstanceManagers CancelAllPreviousTransfers(roleInstanceManager) ' Start the transfer for each instance of the role roleInstanceManager.BeginOnDemandTransfer(dataBufferName, transferOptions) ' Poll the feedback queue every 15 sec for 10 min to see if the transfer is complete. PollAndConfirmTransfer(roleInstanceManager, queue) Next roleInstanceManagerEnd SubSave the AzureDiagnosticConfiguration.cs file (for C# projects) or AzureDiagnosticConfiguration.vb file (for Visual Basic projects).Next, update the application to display the deployment ID of the service in its page title. You will need to supply this information to the diagnostics tool later, when you use it to configure your deployment. To add the deployment ID to the title, open the Site.Master file in the Views\Shared folder of the MyTodo.WebUx project. Locate the title tag inside the head of the page and insert the following code to append the DeploymentId property to the page title.Note that this step is not strictly necessary when you run the application in the Development Fabric, because you can obtain the deployment ID from corresponding node in the Service Deployments tree view.<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "">...<html xmlns=""><head runat="server"> <meta http-equiv="content-type" content="text/html; charset=UTF-8" /> <meta http-equiv="X-UA-Compatible" content="IE=8" /> <title> <asp:ContentPlaceHolder ID="TitleContent" runat="server" /> | DeploymentId: <%= Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.DeploymentId %> </title> <link href="<%=Url.Content("~/Content/styles/site.css")%>" rel="stylesheet" type="text/css" /> <asp:ContentPlaceHolder ID="StylesContent" runat="server"></asp:ContentPlaceHolder></head><body> <div id="container"> ...Note: The Diagnostics Management API requires the storage account used to store diagnostics information and the deployment ID of your service.VerificationNow, you test the remote diagnostic monitoring capabilities of Windows Azure. First, you configure a new performance monitor counter to measure “% Processor Time” and then you trigger an on-demand transfer of performance counter data to Azure Storage. Finally, you inspect the table that received the performance records collected by the counter.Press F5 to build and run the application.Obtain the deployment ID of the running service. To retrieve the ID, switch to the browser window showing the start page of the application and record the DeploymentId value shown in the title bar. Alternatively, if you are running the application in the Development Fabric, you can obtain the Deployment ID from the corresponding label in the Service Deployments tree view.Figure 53Obtaining the deployment ID of the serviceOpen a command prompt and change the current directory to the Source\Assets\MyTodo.Diagnostics.Client folder.At the command prompt, execute myTodoMonitorClient.exe indicating the AddPerformanceCounter operation. Use the following command line arguments ensuring that you replace the parameter placeholders with the settings that apply to your service mand PromptmyTodoMonitorClient.exe AddPerformanceCounter /accountName:<YOUR_STORAGE_NAME> /accountKey:<YOUR_STORAGE_KEY> /roleName:MyTodo.WebUx /deploymentId:<YOUR_DEPLOYMENT_ID> /counter:"\Processor(_Total)\% Processor Time" /sampleRate:5Note: The command receives parameters for your Azure Storage account credentials, the name of the role to configure, the deployment ID of the service, the name of the counter to add, and the sampling rate (in seconds), and then updates the configuration of the role instances to add a new performance counter to measure % Processor Time.If you are using the tool to configure an application that uses Development Storage, omit the accountName and accountKey parameters from the command line above.To obtain a list of performance counter names, open a command prompt and enter the following command: typeperf -q | moreNote that this command lists the performance counters available in your workstation and while many performance counters are common to every system, the list might contain some items that are not available in your Azure role depending on the software that you have installed.Figure 54Remotely adding performance counters to a running serviceNow, you transfer the diagnostics data saved in local storage to your Azure Storage account. At the command prompt, once again execute the myTodoMonitorClient command, this time specifying the OnDemandTransfer operation. Remember to replace the parameter placeholders with your service account mand PromptmyTodoMonitorClient.exe OnDemandTransfer /accountName:<YOUR_STORAGE_NAME> /accountKey:<YOUR_STORAGE_KEY> /roleName:MyTodo.WebUx /deploymentId:<YOUR_DEPLOYMENT_ID> /bufferName:PerformanceCountersFigure 55Pushing diagnostics data to Azure StorageNote: The bufferName parameter specifies which information you are transferring to Azure Storage. You can specify the following values: DiagnosticInfrastructureLogs, Directories, Logs, PerformanceCounters, and WindowsEventLogs.Now that you have triggered the transfer of performance data to your Azure Storage account, it is time to verify that the operation succeeded. Again, open your browser and navigate to the home page for the TableBrowser, enter the Account Name and Primary Access Key of your Azure Storage account and click Log In.If you recall the tables that existed in your account after completing the previous task, you will notice that there is now an additional table named WADPerformanceCountersTable. This table contains the performance data that was collected by the counter that you added earlier in this task.Figure 56Azure Table Storage showing the new performance counters tableClick the WADPerformanceCountersTable link to view the contents of this table. In the table, you will find the performance data collected during the interval prior to the on-demand transfer. Expand any one of the rows to view the information it contains. To do this, click the green icon next to the row. Figure 57Performance counter data table containing records for “% Processor Time”Note: You examine the information in the TableBrowser to review its format and see how it is stored in an Azure Storage table. In a more common scenario, you would use an application to process the information in these tables and generate reports and statistics.SummaryBy completing this hands-on lab, you learnt how to create a storage account and a hosted service at the Windows Azure Developer Portal. Using the portal, you deployed a service package that contained the application binaries, configured its storage and defined the number of instances to run. You also saw how to achieve this programmatically using the Service Management API and in particular, how to use the Windows Azure Service Management cmdlets to deploy, update, and manage applications using Windows PowerShell.Finally, you examined Windows Azure Diagnostics and how to collects diagnostics data from your application and store it in an Azure Storage account. You reviewed the various logs that it produces, and instrumented an application to produce performance data and trace information. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download