“There are only two hard things in computer science: cache invalidation and naming things.”
That classic Phil Karlton quote holds plenty of truth. But thanks to the New Relic .NET agent team, naming your self-hosted applications, Azure Cloud Services, virtual machines, websites, and anything else reporting to New Relic using the .NET agent just got easier. That can be a big deal for enterprises that may have literally thousands of things working with the New Relic .NET agent.
To make dealing with large numbers of .NET apps easier, the team added two new APIs: StartAgent and SetApplicationName as well as a new feature that has been implemented to delay the startup of the agent.
See the supporting public code on GitHub.
To take advantage of the new functionality, simply name the app via an API call in your code:
First, add a newrelic.config to the root of your Web role so that you can disable the automatic startup of the agent on your role by adding
autoStart="false" to the service element. You’ll want to do this so that your application does not report to New Relic before you name it.
Next, add the following line of code to a method or event handler that is executed early in your application’s life cycle. In an MVC application you might choose the
Application_Start event handler.
Next, since the agent was configured not to start automatically, you can use the StartAgent API to start the agent after your application is named:
A big deal in the enterprise
This API and configuration combo has solved one of the longest running asks in Azure Cloud Service circles.
So why is naming your applications that report to New Relic so important? With thousands of VMs or services reporting to New Relic in an enterprise setting, even implementing a naming convention could prove a hassle, much less naming all of them manually.
In an Azure setting where we use Cloud Services, for example, as our application goes through our dev/test environments, a normal mechanism for providing environment-based configuration would be to use the service configuration files, which can now be used to assign the application name:
But what about more complex scenarios? Your organization might have several hundred or even more than a thousand Cloud Services. Say you want to name the applications by deployment slots and location (i.e., mycloudservice.prod.westus, mycloudservice.prod.eastus, mycloudservice.prod.westeurope, and so on) and you want the environment where the application is deployed to determine the name. This type of scenario could be challenging to developers and operations folks who need to be surgical about diagnostics of their vast cloud implementations. Our new .NET functionality is designed to make the process much easier.
What’s in a name?
We have put together a few quick examples on GitHub showing how powerful our two little APIs can be when working with Azure Cloud Services. We also combined the APIs with the Azure Management APIs to show how easy it is to gain a considerable amount of flexibility with your application information.
Clearly, names matter, and we believe this new .NET agent functionality makes it easier for you to properly name large numbers of apps, VMs, websites, and so on.