locked
Azure Diagnostic Start / Stop RRS feed

  • Question

  • Can I Start / Stop azure diagnostics completly on any role remotly, the way we can configure existing paramenter remotly like performance counters etc.
    Tuesday, October 19, 2010 11:17 AM

Answers

  • The DiagnosticMonitor object controls the WAD (Windows Azure Diagnostics) process that exists within the VM. To my knowledge, there is currently no way to start/stop this outside of the VM. However, if you build into your applications hooks specifically targetting the Start and Shutdown methods of this object, then you would be able to exert this external control.

    However, IMHO, a far better alternative is to configure WAD to capture all the pertinent details you may want, but NOT persist those values to storage until a trigger event occurs. In this scenario, the values will be written to a buffer that remains on the VM (presumably as a file) until such time as the information is aged out due to reaching the maximum buffer size.

    This should allow you to minimize any performance impacts that may occur within the VM without sacrificing visiblity should an event occur.

    • Marked as answer by Mog Liang Tuesday, October 26, 2010 9:13 AM
    Tuesday, October 19, 2010 1:04 PM

All replies

  • Hi,

    You could handle the Changed event on the RoleEnvironment. In the eventhandler you can read a configuration value and do your diagnostics magic there ;-) depending on the configuration value.


    With regards,

    Patriek
    If this reply is of help to you, please don't forget to mark it as an answer.
    Tuesday, October 19, 2010 12:14 PM
  • The DiagnosticMonitor object controls the WAD (Windows Azure Diagnostics) process that exists within the VM. To my knowledge, there is currently no way to start/stop this outside of the VM. However, if you build into your applications hooks specifically targetting the Start and Shutdown methods of this object, then you would be able to exert this external control.

    However, IMHO, a far better alternative is to configure WAD to capture all the pertinent details you may want, but NOT persist those values to storage until a trigger event occurs. In this scenario, the values will be written to a buffer that remains on the VM (presumably as a file) until such time as the information is aged out due to reaching the maximum buffer size.

    This should allow you to minimize any performance impacts that may occur within the VM without sacrificing visiblity should an event occur.

    • Marked as answer by Mog Liang Tuesday, October 26, 2010 9:13 AM
    Tuesday, October 19, 2010 1:04 PM