How to use Diagnostics.wadcfg to configure Windows Azure diagnostics collection

When a role imports the Diagnostics module by using the service definition, the Diagnostics module looks for a file named “diagnostics.wadcfg” in the root directory of the role. This file can be deployed in the same place as your app.config/web.config file.

The file is used by the diagnostics agent to create the initial profile for collection. You can modify the settings after deployment using the PowerShell cmdlets I’ve talked about previously.

Here is a sample file. It should be pretty straight forward to understand. Note, times for seconds would be in the format PT30S, this representing 30 seconds.

<?xml version="1.0" encoding="utf-8" ?>
<DiagnosticMonitorConfiguration xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration" configurationChangePollInterval="PT15M" overallQuotaInMB="4096">
  <WindowsEventLog bufferQuotaInMB="1024" 
                   scheduledTransferLogLevelFilter="Verbose" 
                   scheduledTransferPeriod="PT10M">
    <DataSource name="Application!*"/>
    <DataSource name="System!*"/>    
  </WindowsEventLog>
  <DiagnosticInfrastructureLogs bufferQuotaInMB="1024"
                                scheduledTransferLogLevelFilter="Verbose"
                                scheduledTransferPeriod="PT10M" />
  <Logs bufferQuotaInMB="1024"
        scheduledTransferLogLevelFilter="Verbose"
        scheduledTransferPeriod="PT10M" />
  <PerformanceCounters bufferQuotaInMB="512" scheduledTransferPeriod="PT10M">
    <PerformanceCounterConfiguration counterSpecifier="\Memory\Available MBytes" sampleRate="PT5M"/>
    <PerformanceCounterConfiguration counterSpecifier="\Processor(_Total)\% Processor Time" sampleRate="PT5M"/>
    <PerformanceCounterConfiguration counterSpecifier="\Network Interface(*)\Bytes Sent/sec" sampleRate="PT5M"/>
    <PerformanceCounterConfiguration counterSpecifier="\Network Interface(*)\Bytes Total/sec" sampleRate="PT5M"/>
  </PerformanceCounters>  
</DiagnosticMonitorConfiguration>

All you really have to do is drop that file in the root directory of your role and you are done!

The documentation here, suggests that you would use code to configure diagnostics. If you have ever read any of my blog posts you probably know how I feel about that. (Note: for those that haven’t its just wrong to use code. Really ops should be supplying this file for production. You have an ops team right?)

THIS POSTING IS PROVIDED “AS IS” WITH NO WARRANTIES, AND CONFERS NO RIGHTS, UNLESS MY BROTHER GAVE YOU THE SECRET CODE.

Encrypting and Decrypting in Windows Azure

When deploying applications to Windows Azure, you probably will be dealing with encrypted connections strings, passwords and other such things. If you have ever used Remote Desktop, you will have noticed an encrypted password, along with a certificate that is used to encrypt the password. You can of course do the same with your secret things too.

Doing this creates the need for a tool to encrypt such settings. There are a few posts out there that show how to decrypt the values in code (you can grab some from here), you still need a way for operators to create these values in the first place. I thought a couple of PowerShell scripts should do the trick nicely.

You will need the thumbprint of a certificate in the CurrentUser\My store, which would be the same cert you deploy with you Azure deployment in order to decrypt.

The Encrypt function looks like:

Function Encrypt($stringToEncrypt, $thumb)
{
    $cert = get-item cert:\CurrentUser\My\$thumb
    [System.Reflection.Assembly]::LoadWithPartialName("System.Security") | out-null
    $passbytes = [Text.Encoding]::UTF8.GetBytes($stringToEncrypt)
    $content = New-Object Security.Cryptography.Pkcs.ContentInfo -argumentList (,$passbytes)
    $env = New-Object Security.Cryptography.Pkcs.EnvelopedCms $content
    $env.Encrypt((new-object System.Security.Cryptography.Pkcs.CmsRecipient($cert)))

    [Convert]::Tobase64String($env.Encode())
}

The Decrypt function looks like:

Function Decrypt($EncryptedString, $thumb)
{    
    $cert = get-item cert:\CurrentUser\My\$thumb    
    [System.Reflection.Assembly]::LoadWithPartialName("System.Security") | out-null
    $encodedBytes = [Convert]::Frombase64String($EncryptedString)
    $env = New-Object Security.Cryptography.Pkcs.EnvelopedCms
    $env.Decode($encodedBytes)
    $env.Decrypt($cert)
    $enc = New-Object System.Text.ASCIIEncoding
    
    $enc.GetString($env.ContentInfo.Content)    
}

Usage is simple:

$pwd = Encrypt "TheDavidAiken" "39836617C1A2BBAC6F90C0224C31B019854C6659"
Decrypt $pwd "39836617C1A2BBAC6F90C0224C31B019854C6659"

Enjoy.

THIS POSTING IS PROVIDED “AS IS” WITH NO WARRANTIES, AND CONFERS NO RIGHTS, UNLESS YOU HAVE A NOTE FROM MY MUM

Ten Basic Troubleshooting Tips for Windows Azure

The last few posts I’ve talked a LOT about configuring diagnostics. Much of that comes not because I love pretty graphs, but because I end up working with customers who are troubleshooting problems with applications running on Windows Azure.

Here is MY list of recommendations to help things run a little smoother:

  1. Keep your diagnostics account separate from your production account. This will help with performance of both production and diagnostics since they won’t be competing for the same storage account.
  2. Make sure your storage account is in the same data center as your compute. I know. Just saying.
  3. Make sure you collect the right set of performance counters AND check that you are actually collecting data. Make sure you are collecting the .Net 4.0 counters for ASP.NET where applicable.
  4. Use either the .wadcfg or PowerShell scripts I’ve talked about here to configure diagnostics. Hard coding it will overwrite any changes you make when an instance restarts.
  5. Knowing and understanding your baseline workload is important. You should look at your performance on a regular basis, and over a period of time.
  6. To troubleshoot, you can enable RDP and perform an upgrade of your service. You can then RDP into specific instances to troubleshoot.
  7. When you are working with Microsoft’s product support, try not to delete old deployments. Once you do it makes finding a root cause more difficult. You can always VIP swap them out and leave them running while they troubleshoot.
  8. Having more instances running means more people can look at the problem at the same time.
  9. Check the status of the service at http://www.microsoft.com/windowsazure/support/status/servicedashboard.aspx
  10. Invest in a diagnostics data viewing tool, such as Cerebrata, or grab a free trail of ManageAxis by following the rabbit hole from the Cloud Cover Show.

 

M5$A)4R!03U-424Y'($E3(%!23U9)1$5$(.*`G$%3($E3XH”=(%=)5$@@3D\@A5T%24D%.5$E%4RP@04Y$($-/3D9%4E,@3D\@4DE’2%13`