1
votes

I just started checking out Windows Azure and I have trouble getting any access logs from IIS for my test web role. The web role itself works fine, but I would like to see a log for accesses (both successful and failed).

As far as I can see the default configuration files for a web role contain instructions to send those logs to a blob named "wad-iis-logfiles", but that blob is never even created (it doesn't exist in my blob storage).

My diagnostics.wadcfg for the web role currently is:

<DiagnosticMonitorConfiguration configurationChangePollInterval="PT1M" overallQuotaInMB="4096" xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration">
  <DiagnosticInfrastructureLogs bufferQuotaInMB="512" scheduledTransferPeriod="PT5M" />
  <Directories bufferQuotaInMB="512" scheduledTransferPeriod="PT5M">
    <IISLogs container="wad-iis-logfiles" />
    <CrashDumps container="wad-crash-dumps" />
  </Directories>
  <Logs bufferQuotaInMB="512" scheduledTransferPeriod="PT5M" scheduledTransferLogLevelFilter="Information" />
  <PerformanceCounters bufferQuotaInMB="512">
    (... snip...)
  </PerformanceCounters>
  <WindowsEventLog bufferQuotaInMB="512" scheduledTransferPeriod="PT1M" scheduledTransferLogLevelFilter="Error">
    <DataSource name="Application!*" />
  </WindowsEventLog>
</DiagnosticMonitorConfiguration>

Question 1: is this configuration file correct?

Question 2: are there other things that need to be set before I can get the IIS log files?

1
How are you checking the existence of wad-iis-logfiles blob container? Do you see other blob containers starting with wad- e.g. wad-control-container?Gaurav Mantri
I'm looking at them in the Server Explorer in Visual Studio (2012). There are 3 blobs: they are named "vsdeploy", "mam" and "wad-control-container"Luc C
Can you check the contents of wad-control-container especially for the deployment id of your current web role deployment. There should be some files in there contents of which are used by the diagnostics agent running in your web role. See if you see <IISLogs container="wad-iis-logfiles" /> setting in that file. Also please see if you're using https in your diagnostics connection string in your role's config file.Gaurav Mantri
To download, you can use free Azure Explorer - cerebrata.com/labs/azure-explorer. What about my other question regarding the diagnostics connection string? Is it using http or https?Gaurav Mantri
Is the file in wad-control-container showing the same configuration settings as your .wadcfg? If you are deploying a service and a file already exists in wad-control-container, then any other configuration changes will be ignored. So if you are trying to do an in place update and modify the .wadcfg then it won't work. You first have to delete the file in wad-control-container.kwill

1 Answers

0
votes

With the help of the commenters I was able to solve the issue.

There are several interacting things causing the issue.

As commenter @kwill mentioned, an existing configuration blob in wad-control-container overrides any other configuration, and that configuration is not replaced during an in-place update. I was using in-place update to put my modified diagnostics.wadcfg in place, so that is the explanation why my attempts to change settings that way didn't work. Note that editing the properties of the web test role (in the "Roles" branch of the Azure Cloud services project operates by editing that same file, so that didn't work either. More information on how that wad-control-container overrides setting can be found in http://msdn.microsoft.com/en-us/library/windowsazure/dn205146.aspx .

The reason that blob already existed may have been that I had been changing some other performance measurement settings in the azure management window earlier.

I managed to "fix" the situation by editing the blob found in wad-control-container for my instance, using the tool mentioned by commenter @Gaurav Mantri - "Azure Explorer". As mentioned, without that tool you can download the blob and edit it, but never put it back properly, since the '/' characters in the blob's name get translated to '%2F', and those are not translated back on upload.

Note that the XML schema is not the same as the schema for diagnostics.wadcfg, but some similarities exist. I changed the "Directories" element toward the bottom of the blob to read:

<Directories>
  <BufferQuotaInMB>512</BufferQuotaInMB>
  <ScheduledTransferPeriodInMinutes>2</ScheduledTransferPeriodInMinutes>
  <Subscriptions>
    <DirectoryConfiguration>
      <Path>C:\Resources\directory\8091b0be14e54213ac12fcbd5f9c8e1b.WebTestRole.DiagnosticStore\CrashDumps</Path>
      <Container>wad-crash-dumps</Container>
      <DirectoryQuotaInMB>0</DirectoryQuotaInMB>
    </DirectoryConfiguration>
    <DirectoryConfiguration>
      <Path>C:\Resources\directory\8091b0be14e54213ac12fcbd5f9c8e1b.WebTestRole.DiagnosticStore\LogFiles</Path>
      <Container>wad-iis-logfiles</Container>
      <DirectoryQuotaInMB>16</DirectoryQuotaInMB>
    </DirectoryConfiguration>
  </Subscriptions>
</Directories>

In the original version the "BufferQuotaInMB" and "DirectoryQuotaInMB" fields were 0.

Note that after uploading the blob again the effect is not immediate. It takes a while for the changed configuration to get picked up, and then it takes another while before the IIS log files are copied for the first time.

Last note: it may be obvious, but I don't think editing that blob is a recommendable solution. It is good to know the option exists though.