After upgrading to SDK 2.5, the diagnostics mechanism in VS 2013 has changed.

When I open the role configuration and click Configure (under diagnostics), and then click Log Directories, I see the IIS logs, failed request tracing logs, and the absolute directory logs. The local resource log box is missing.

In this article:

http://msdn.microsoft.com/en-us/library/azure/dn186185.aspx

Where they have a screenshot of the Log Directories tab, you can see clearly there are two boxes - one for absolute directory and another for local resources. I'm not seeing the second box in my Visual Studio 2013 (update 4 + SDK 2.5).

Any ideas?

Thanks,

Ido.

Hi,

Thank you for your question.

I am trying to involve someone familiar with this topic to further look at this issue.

Regards,

Mekh.

Thanks.

I've also managed to reproduce this issue in another computer running VS 2013 with SDK 2.5.

Ido.

Hi Ido,

The below issue is a documentation error. We will get this MSDN article updated. We should only see Logs from Absolute Directory section in the Diagnostics Configuration dialog.

However, if you want to  add a local storage resource in your diagnostics configuration and transfer it to a blob, you can still do it by manually configuring the wadcfgx file. Below is the configuration that you will have to add.

In the <Directories> section, add a new data source as follows (in wadcfgx)

<DataSources>

<DirectoryConfiguration containerName="wad-custom2">

   <LocalResource name="diagStore" relativePath="."/>

</DirectoryConfiguration>

</DataSources>

If there is a local storage defined in your csdef (as shown below), it will be transferred to the wad-custom2 blob container.

<LocalResources>

      <LocalStorage name="diagStore" cleanOnRoleRecycle="false" />

</LocalResources>

Let me know if you have further questions on this.

Thanks,

Gaurav

• Proposed as answer by Mekh SubbaMicrosoft contingent staff, Moderator Friday, December 05, 2014 9:34 AM
• Marked as answer by Ido Flatow. _MVP Friday, December 05, 2014 10:47 AM

Hi Ido,

The below issue is a documentation error. We will get this MSDN article updated. We should only see Logs from Absolute Directory section in the Diagnostics Configuration dialog.

However, if you want to  add a local storage resource in your diagnostics configuration and transfer it to a blob, you can still do it by manually configuring the wadcfgx file. Below is the configuration that you will have to add.

In the <Directories> section, add a new data source as follows (in wadcfgx)

<DataSources>

<DirectoryConfiguration containerName="wad-custom2">

   <LocalResource name="diagStore" relativePath="."/>

</DirectoryConfiguration>

</DataSources>

If there is a local storage defined in your csdef (as shown below), it will be transferred to the wad-custom2 blob container.

<LocalResources>

      <LocalStorage name="diagStore" cleanOnRoleRecycle="false" />

</LocalResources>

Let me know if you have further questions on this.

Thanks,

Gaurav

• Proposed as answer by Mekh SubbaMicrosoft contingent staff, Moderator Friday, December 05, 2014 9:34 AM
• Marked as answer by Ido Flatow. _MVP Friday, December 05, 2014 10:47 AM

Hi Gaurav,

Thanks for the reply. I've already manually configured the wadcfgx and stumbled other issues with collecting local resources (possible bug in the PaaS WAD plugin - I'm discussing this with the Azure team on a separate thread).

Will the local resource setting be available through the GUI any time in the future? it's silly to have 80% of the file being configured in the GUI and 20% manually.

Hi everyone,

did you already encounter a solution for the described problem? It seems i have the same issue. I try to use Diagnostics 1.3 coming with Azure SDK 2.5 to push a local storage directory to a storage container.

I tried it with the above given hints by Gaurav, but it is not working.

The effects:

• My local storage does not appear in the given storage container. Instead, i get a folder "Tables" in the storage container containing crash dump files etc..
  
  ServiceDefinition.csdef:
  <LocalResources>
    <LocalStorage name="BillingDirectory" cleanOnRoleRecycle="false" sizeInMB="50000" />
    <LocalStorage name="DiagnosticStore" cleanOnRoleRecycle="false" sizeInMB="70000" />
  </LocalResources>
  
  diagnostics.wadcfgx:
  <DiagnosticsConfiguration xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration">
    <PublicConfig xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration">
      <WadCfg>
        <DiagnosticMonitorConfiguration overallQuotaInMB="50000">
          <Directories scheduledTransferPeriod="PT1M">
            <DataSources>
              <DirectoryConfiguration containerName="xserver-billing">
                <LocalResource relativePath="." name="BillingDirectory" />
              </DirectoryConfiguration>
  ...
  
  Content of the "Tables" folder which was copied to the storage container:
      CrashDump.tsf
      CrashDump_00..01.tsf
      ...
      WindowsEventLogsTable.tsf
      ...
  I was able to find the "Tables" folder on my system here:
  C:\Resources\{<GUID>}\directory\<DeploymentID>.WebRoleWebApp.DiagnosticStore\WAD0103
  
  
• If i add a relative path other than ".", i can find a folder with the same name in the folder
  "C:\Resources\{<GUID>}\directory\<DeploymentID>.WebRoleWebApp.DiagnosticStore\WAD0103\<relativePath>"
  on my system. Seems like Diagnostics are looking there to get the data to be copied to the storage container?
  
  ServiceDefinition.csdef:
  <LocalResources>
    <LocalStorage name="BillingDirectory" cleanOnRoleRecycle="false" sizeInMB="50000" />
    <LocalStorage name="DiagnosticStore" cleanOnRoleRecycle="false" sizeInMB="70000" />
  </LocalResources>
  
  diagnostics.wadcfgx:
  <DiagnosticsConfiguration xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration">
    <PublicConfig xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration">
      <WadCfg>
        <DiagnosticMonitorConfiguration overallQuotaInMB="50000">
          <Directories scheduledTransferPeriod="PT1M">
            <DataSources>
              <DirectoryConfiguration containerName="xserver-billing">
                <LocalResource relativePath="billing" name="BillingDirectory" />
              </DirectoryConfiguration>
  ...
  But if i try to write log files to this folder, they do not appear there after the system start. Seems like the folder is created again by Diagnostics in an empty state and is overwritten? Finally, no data is transferred to the storage container as no data can be found in the folder.
  

Does anyone have a clue what is going on there and what i might be doing wrong or if there is a bug in the Diagnostics implementation?

• Edited by Simone Forster Wednesday, January 14, 2015 2:48 PM

Hi everyone,

did you already encounter a solution for the described problem? It seems i have the same issue. I try to use Diagnostics 1.3 coming with Azure SDK 2.5 to push a local storage directory to a storage container.

I tried it with the above given hints by Gaurav, but it is not working.

The effects:

• My local storage does not appear in the given storage container. Instead, i get a folder "Tables" in the storage container containing crash dump files etc..
  
  ServiceDefinition.csdef:
  <LocalResources>
    <LocalStorage name="BillingDirectory" cleanOnRoleRecycle="false" sizeInMB="50000" />
    <LocalStorage name="DiagnosticStore" cleanOnRoleRecycle="false" sizeInMB="70000" />
  </LocalResources>
  
  diagnostics.wadcfgx:
  <DiagnosticsConfiguration xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration">
    <PublicConfig xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration">
      <WadCfg>
        <DiagnosticMonitorConfiguration overallQuotaInMB="50000">
          <Directories scheduledTransferPeriod="PT1M">
            <DataSources>
              <DirectoryConfiguration containerName="xserver-billing">
                <LocalResource relativePath="." name="BillingDirectory" />
              </DirectoryConfiguration>
  ...
  
  Content of the "Tables" folder which was copied to the storage container:
      CrashDump.tsf
      CrashDump_00..01.tsf
      ...
      WindowsEventLogsTable.tsf
      ...
  I was able to find the "Tables" folder on my system here:
  C:\Resources\{<GUID>}\directory\<DeploymentID>.WebRoleWebApp.DiagnosticStore\WAD0103
  
  
• If i add a relative path other than ".", i can find a folder with the same name in the folder
  "C:\Resources\{<GUID>}\directory\<DeploymentID>.WebRoleWebApp.DiagnosticStore\WAD0103\<relativePath>"
  on my system. Seems like Diagnostics are looking there to get the data to be copied to the storage container?
  
  ServiceDefinition.csdef:
  <LocalResources>
    <LocalStorage name="BillingDirectory" cleanOnRoleRecycle="false" sizeInMB="50000" />
    <LocalStorage name="DiagnosticStore" cleanOnRoleRecycle="false" sizeInMB="70000" />
  </LocalResources>
  
  diagnostics.wadcfgx:
  <DiagnosticsConfiguration xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration">
    <PublicConfig xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration">
      <WadCfg>
        <DiagnosticMonitorConfiguration overallQuotaInMB="50000">
          <Directories scheduledTransferPeriod="PT1M">
            <DataSources>
              <DirectoryConfiguration containerName="xserver-billing">
                <LocalResource relativePath="billing" name="BillingDirectory" />
              </DirectoryConfiguration>
  ...
  But if i try to write log files to this folder, they do not appear there after the system start. Seems like the folder is created again by Diagnostics in an empty state and is overwritten? Finally, no data is transferred to the storage container as no data can be found in the folder.
  

Does anyone have a clue what is going on there and what i might be doing wrong or if there is a bug in the Diagnostics implementation?

• Edited by Simone Forster Wednesday, January 14, 2015 2:48 PM

Hi,

I'm still seeing these issues. I didn't notice any new/updated SDK.

My solution is to use absolute folders instead of local resource folders.

Ido.

Hi Ido,

thanks for the quick reply. I also implemented a solution with an absolute folder. But the problem is that this absolute folder cannot be accessed by all users due to access right problems as is put on C:\. We will now re-implement the accessing structures so that they use the copied files on the storage instead of the original files on the system.

But this feels all only like a workaround...

That's why we gave extra permissions in the startup script, only problem is that the diagnostics agent runs before the startup script :-( so it only works after redeploying to an existing instance.

This is indeed a workaround and hopefully will be resolved.

I actually have the fix for the issue (found the problem in their code), but I don't recall the SDK being open-sourced.

Ido.

Giving extra permissions as you described is no option for us as we cannot redeploy again. But accessing the backuped files on the storage will work.

Thank you anyway for the hints and the response.

The only thing left is the wish that Microsoft provides an update with a bug fix for that ;-). Let's see if / when this will be the case.

Simone.

Hey guys

Just wanted to jump in and acknowledge this is a bug we are looking into.

For now the only workaround is the one Ido mentions with using absolute folders.

Thanks for your patience

Saurabh

Hi Saurabh,

This issue is really annoying for our project. We would like to move back to using local folder for custom logging as soon as possible.

Could you please let us know when bug is resolved and update with bug fix provided (any bug id or other progress tracking information)?

Thanks, Oleksii

Hey everyone

We just released an update to the diagnostics extension (version 1.4) that fixes the issue around local resources with relative paths not being transferred.

If you apply the extension again to your existing service with Visual Studio or PowerShell you will automatically get the latest version.

Please try it out and let us know if you are still having trouble with the issue.

Thanks
Saurabh