We’ve noticed that some customers have reported their Azure Cloud Services applications have stopped sending data to New Relic.
Cloud Services now has the option to enable one of several different types of profiling when a service is deployed. By default this is enabled. When this option is checked, it appears that Azure Diagnostics removes the registry keys specific to profiling. It appears to delete the
COR_PROFILER entries from the registry keys below and then restarts the app pools. This is happening after the agent installer runs and sets them correctly.
These entries set the environment variables for
w3wp (IIS) processes, and when these entries are removed, they prevent the agent from loading into the application’s process.
There is a way to disable Azure Diagnostics and doing so allows our registry keys to stick around.
- In Visual Studio expand the Cloud Services project
- Expand the Roles folder
- Right click on the WebRole
- Select Properties
- In the Configuration screen that opens, uncheck
- Save the changes
- Publish the deployment
If the above doesn’t help or you’re not able to modify those settings in Visual Studio, there’s another option available. You can Install the agent with the “Instrument all” option, so that the variables are set system-wide.
To do this, you’ll need to make a change to the
newrelic.cmd file that is installed in your project as part of the
NewRelicWindowsAzure Nuget package before you deploy your Azure instance. This change would be made in the Visual Studio project itself.
In that file, find the section that looks like this:
IF "%IsWorkerRole%" EQU "true" ( msiexec.exe /i %NR_INSTALLER_NAME% /norestart /quiet NR_LICENSE_KEY=%LICENSE_KEY% INSTALLLEVEL=50 /lv* %RoleRoot%\nr_install.log ) ELSE ( msiexec.exe /i %NR_INSTALLER_NAME% /norestart /quiet NR_LICENSE_KEY=%LICENSE_KEY% /lv* %RoleRoot%\nr_install.log )
and replace it with this (removing the entire IF/ELSE block):
msiexec.exe /i %NR_INSTALLER_NAME% /norestart /quiet NR_LICENSE_KEY=%LICENSE_KEY% INSTALLLEVEL=50 /lv* %RoleRoot%\nr_install.log
That will work around the issue of the agent failing to report, but it should be noted that this will result in more profiler logs being produced. If your team makes regular deployments, this shouldn’t be a problem, as it would take quite a while for enough of those tiny logs to accumulate for it to make a significant impact on storage space.
I hope this helps if you’re running into this issue!