2

Reading MSDN I got an impression that the account used for storing Azure Diagnostics is configured like this:

<ConfigurationSettings>
   <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString"
       value="DefaultEndpointsProtocol=https;AccountName=AccountName;AccountKey=AccountKey"/>
</ConfigurationSettings>

(the settings name is the fixed "Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" string). But then I also found code snippets for setting up the DiagnosticMonitor (from this question by user Søren Randrup:

<ConfigurationSettings>
     <Setting name="DiagnosticsConnectionString"
        value="DefaultEndpointsProtocol=https;AccountName=AccountName;AccountKey=AccountKey" />
</ConfigurationSettings>

var dm = DiagnosticMonitor.GetDefaultInitialConfiguration();
dm.Logs.ScheduledTransferPeriod = TimeSpan.FromSeconds(5);
dm.Logs.ScheduledTransferLogLevelFilter = LogLevel.Verbose;
DiagnosticMonitor.Start("DiagnosticsConnectionString", dm);

(the setting name is a string chosen by the developer).

This looks confusing - I'm under impression that it's the same setting but for whatever reason different people configure it differently.

Where is the storage account specified and why are the two abovementioned snippets seemingly used for the same task?

Community
  • 1
  • 1
sharptooth
  • 167,383
  • 100
  • 513
  • 979

4 Answers4

4

When DiagnosticsMonitor was first released (1.1 or 1.2 SDK, IIRC), it was started from the RoleEntryPoint (user code). This had some disadvantages, namely, if your RoleEntryPoint crashed, it took the DM down with it. When the 1.3 SDK was released, it changed the design and started the DM as a background startup task. This allows the DM to run in a separate process than your code and hence it no longer is susceptible to being crashed by user code. The "Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" is the setting defined in the Diagnostics role plugin (look in your bin/plugins directory).

If you do nothing but import the Diagnostics plugin and set this connection string, you will have diagnostics enabled for some default things, but nothing will actually transfer to your storage account for analysis.

So, a more complete solution is to:

  1. Enable the DM plugin and set a valid connection string to a storage account in Windows Azure.
  2. Either remotely (using tools like scripts, ManageAxis, Windows Azure MMC, Cerebrata, or others) set the configuration for monitoring like you want*
  3. Or, at runtime, in your RoleEntryPoint, imperatively configure the monitor via code.

This gets your counters, logs, whatever, actually transferring into your storage account. At this point, it is up to you to interpret it. There are products (e.g. ManageAxis and others) that do the analysis for you (graph, autoscale, etc.), but you are largely on your own to query the data produced by the DM otherwise.

* I prefer this method as I don't like coding this in my RoleEntryPoint and I have tooling that can watch and maintain it.

dunnry
  • 6,858
  • 1
  • 20
  • 20
1

I believe this is something that has occurred as Azure has developed... in the early days, diagnostics was not started by default - so that explains the old question and answer.

In the latest API (1.4), I think you should use the first method and use GetDefaultInitialConfiguration ... SetCurrentConfiguration in order to specify the things you want to monitor.

Stuart
  • 66,722
  • 7
  • 114
  • 165
1

I struggled with this as well, so put together the following blog post when I finally got it working

Windows Azure Diagnostics with SDK 1.6 for WebRoles

Iain Hunter
  • 4,319
  • 1
  • 27
  • 13
0

For a detailed walkthrough on Azure Diagnostics, you can check out Matthew Kerners presentation "Windows Azure Monitoring, Logging, and Management APIs" at PDC09

http://www.microsoftpdc.com/2009/SVC15

Rune Vejen Petersen
  • 3,201
  • 2
  • 30
  • 46