locked
Azure SDK 2.5 Diagnostics RRS feed

  • Question

  • Hello,

    Before SDK 2.5, "Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" setting made it possible to have a difference diagnostics storage account per service configuration (e.g. Test, Beta and Prod). Thus per deployment - different cloud service (cloud service for Test/Beta/Prod)
    This was because the "Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString"  was in the service configuration file, which is per service configuration.

    Now in SDK 2.5 the setting is gone and replaced by a setting in the diagnostics.wadcfgx

    file. But that file is not per service configuration.
    How do I in SDK 2.5 configure the web role to have the same functionality as in 2.4?

    Tuesday, November 18, 2014 2:12 PM

Answers

  • Hi guys sorry for the delay in jumping on here. Let me provide some details on whats going on here -  Since Azure SDK 2.5 uses the extension model the diagnostics extension, the configuration and the connection string are no longer part of the deployment package and cscfg. All the diagnostics configuration is contained within the wadcfgx and the connection string is now applied during publish but not persisted with any project related artifacts. The advantage with this approach is that diagnostics agent and settings are decoupled from the project and can be dynamically enabled and updated even after your application is deployed.

    Due to this change some existing workflows need to be rethought – instead of configuring the diagnostics as part of the application that gets deployed to each environment you can first deploy the application to the environment and then apply the diagnostics configuration for it. For automated deployment type of scenarios this can be done by using a powershell script after the application is deployed as described in Step 5 here http://azure.microsoft.com/en-in/documentation/articles/cloud-services-dotnet-diagnostics/. We are currently working on a step by step guide and scripts showing how to enable diagnostics in continuous delivery scenarios.

    From VS to update the config manually you can right click on the role you want to update the diagnostics for in Server Explorer, choose to “Update Diagnostic…” (or “Enable Diagnostics” if you published with diagnostics turned off) and apply the connection string that should be used to store the diagnostics data for that service or environment. We realize this requires an additional step than was previously needed and are working on simplifying the process but at the moment if you trying to manually deploy an application with the diagnostics you do need to make the additional step of updating the configuration for each environment.

    Thanks

    • Proposed as answer by Mekh Subba Thursday, November 27, 2014 7:30 AM
    • Marked as answer by Mekh Subba Friday, November 28, 2014 8:46 AM
    Saturday, November 22, 2014 4:25 AM

All replies

  • Hello!
    Thanks for reaching out here.

    We're investigating on your query. Please stay tuned, we'll keep this thread updated at the earliest.

    Thank you,
    Arvind

    Tuesday, November 18, 2014 8:45 PM
  • Hi,

    Long time back, only way to configure diagnostics was through the code written in your Web or Worker role’s OnStart() method. After that came diagnostics.wadcfg file to decalaratively define diagnostics configuration (though code based configuration was still supported). With SDK 2.5, code based configuration is gone.

    Reference  :  http://gauravmantri.com/2014/11/18/azure-sdk-2-5-and-cloud-service-diagnostics/

    ----------------------------------------------------------------------------------------------------------------------------------

    This response contains a reference to a third party World Wide Web site. Microsoft is providing this information as a convenience to you. Microsoft does not control these sites and has not tested any software or information found on these sites; therefore, Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. There are inherent dangers in the use of any software found on the Internet, and Microsoft cautions you to make sure that you completely understand the risk before retrieving any software from the Internet.

    Regards,

    Mekh.

    Wednesday, November 19, 2014 5:19 AM
  • Hope to hear from you soon

    Thanks,

    Hannes

    Wednesday, November 19, 2014 5:53 AM
  • Hi

    That's not the issue. I didn't do anything in code. And I don't mind that the method of configuration has changed (e.g. other file). My problem is that configuration functionality (different azure storage account per service configuration - test, beta, prod is no longer available. So this is a breaking change with no easy alternative as far as I could find.

    Regards,

    Hannes

    Wednesday, November 19, 2014 5:57 AM
  • Hi,

    Can you please have a check if you can define the storage account information in “PrivateConfig” section in diagnostics.wadcfgx file ?

    Regards,

    Mekh.

    Wednesday, November 19, 2014 7:45 AM
  • Hi,

    yes I can. To repeat my self that is not the issue.

    In SDK 2.4 you could define the storage account for diagnostics in

    • ServiceConfiguration.Cloud.Test.cscfg
    • ServiceConfiguration.Cloud.Beta.cscfg
    • ServiceConfiguration.Cloud.Prod.cscfg

    As you can see this is per Service Configuration.

    In SDK 2.5 you have to configure the storage account for diagnostics in diagnostics.wadcfgx.

    But there is not such a thing as diagnostics.Cloud.Test.wadcfgx, diagnostics.Cloud.Beta.wadcfgx....

    So now I can no longer define a different storage account per Service Configuration.

    I hope its clear now what the problem is.

    Regards,

    Hannes 

    Wednesday, November 19, 2014 7:52 AM
  • Totally Agree

    Rido

    Wednesday, November 19, 2014 1:55 PM
  • Any valid solutions for this problem ? It looks like this is a missing feature for this version.
    Thursday, November 20, 2014 9:45 AM
  • Hi guys sorry for the delay in jumping on here. Let me provide some details on whats going on here -  Since Azure SDK 2.5 uses the extension model the diagnostics extension, the configuration and the connection string are no longer part of the deployment package and cscfg. All the diagnostics configuration is contained within the wadcfgx and the connection string is now applied during publish but not persisted with any project related artifacts. The advantage with this approach is that diagnostics agent and settings are decoupled from the project and can be dynamically enabled and updated even after your application is deployed.

    Due to this change some existing workflows need to be rethought – instead of configuring the diagnostics as part of the application that gets deployed to each environment you can first deploy the application to the environment and then apply the diagnostics configuration for it. For automated deployment type of scenarios this can be done by using a powershell script after the application is deployed as described in Step 5 here http://azure.microsoft.com/en-in/documentation/articles/cloud-services-dotnet-diagnostics/. We are currently working on a step by step guide and scripts showing how to enable diagnostics in continuous delivery scenarios.

    From VS to update the config manually you can right click on the role you want to update the diagnostics for in Server Explorer, choose to “Update Diagnostic…” (or “Enable Diagnostics” if you published with diagnostics turned off) and apply the connection string that should be used to store the diagnostics data for that service or environment. We realize this requires an additional step than was previously needed and are working on simplifying the process but at the moment if you trying to manually deploy an application with the diagnostics you do need to make the additional step of updating the configuration for each environment.

    Thanks

    • Proposed as answer by Mekh Subba Thursday, November 27, 2014 7:30 AM
    • Marked as answer by Mekh Subba Friday, November 28, 2014 8:46 AM
    Saturday, November 22, 2014 4:25 AM
  • I think the new workflow you propose is not correct:

    The feature to have different diagnostics storage connection strings for different service configurations is mandatory to be configured before the deployment.

    This because we don't want to deploy a staging application which starts with writing diagnostics in the production storage, changing that after deployment is too late.

    Please bring back this possibility, as it was in Azure SDK 2.4.

    Sunday, November 23, 2014 9:35 PM
  • Hi

    Is there a chance of getting back the good old solution with diagnostics storage connection string in the *.cscfg or something similar? If yes, what is the timeframe, 2.6 SDK?

    Not having the diagnostics storage connection string in the service configuration really stopped our normal deployment workflow and right now we have aborted our planned upgrade to 2.5 for this year. We have a very simple workflow where development ship *.cspkg (not *.cscfg, development do not have access to production storage accounts etc.) files to operation (they are the only one with access to production storage accounts etc.) for deployment into production. This was easy until now, but it looks much more complicated to get the diagnostics storage connection string right with 2.5.

    It’s fine with all the other diagnostics settings, we have the same settings for development, test and production anyway.

    /Christian

    Wednesday, December 3, 2014 10:09 AM
  • Quite disappointed. I can only second what others are experiencing.

    When deploying we are using Azure management portal and it seems that diagnostics connection cannot be alter before nor after deployment, which indicates that it is part of package. Is there a way to modify the connection string in the package once it has been build?

    Regards

    Ranko

    Wednesday, December 3, 2014 10:24 AM
  • I echo the disappointment expressed here by others.  An extra manual step during deployment from VS is error prone and needs to be removed.
    Tuesday, January 20, 2015 8:41 PM
  • we have the same situation:will break all deployment workflow. it is one of breaking changes of SDK 2.5. and so far, I do not see any benefits moving diagnostics storage setting out of cloud config. but trouble and pain. 

    in 2.5, diagnostics storage setting becomes post deployment action. looks like you do that via PowerShell, which means all deployment agent (server) needs installl Azure PowerShell. do we have Azure Management API (RESful API) support such post deployment action \ steps ?

    Thanks


    Max

    Wednesday, January 21, 2015 12:29 AM