Skip to end of metadata
Go to start of metadata

On this page:

Related links:

Deploy AppDynamics for Azure

Your Rating:
1 Star2 Star3 Star4 Star5 Star
1 rates

This topic applies to the .NET Agent in the Azure App services environment. It describes how the .NET Agent by default names your virtual application tiers and nodes and also how you can customize tier names.

There are two ways to automatically name the tiers of virtual applications:

  • Default: AppDynamics creates new tiers for each virtual directory. Each tier contains a node representing the virtual directory.
  • Custom: When you specify a tier name in the AppDynamicsConfig.json file, all virtual directory applications will report as nodes under this tier.

Default Behavior 

The following shows the Azure Web Apps configuration of the demomultiapp application with three virtual apps, the main application and two sub-applications.


Once you instrument the application with the .NET Agent, restart the application and apply load to it, the .NET Agent reports metrics for the application and virtual applications. In the Controller UI, each virtual application node appears under a separate tier. The name of the tier consists of the name of the application appended with the virtual path of the sub-application. For example, demomultiapp/billing as shown below. The name of the node is the same as the tier name prepended with the name of the virtual machine on which it runs.

You can manually edit the tier name in the Controller UI.

Customize Tier Names

Rather than creating a tier for each virtual application, all virtual applications can report as nodes under a single tier. The tier name specified in the AppDynamicsConfig.json file sets the tier name.


  • When you instrument your application using the .NET Agent site extension, the .NET Agent automatically instruments all virtual directories and applications. However, all AppSettings set at the root app are inherited by all virtual applications.
  • For NuGet-based deployments, the agent uses the AppDynamicsConfig.json file deployed in the same path as the Profiler DLL and ignores the AppDynamicsConfig.json file settings for individual virtual apps in the deployment.


For example, in Azure Web Apps we have the following virtual app and sub-applications.

By default, the tier name of the application in the AppDynamicsConfig.json file is null. The following edited version of the AppDynamics.Config.json file shows a tier name of Business App 15. Note that the node name cannot be changed as its value is automatically updated as the application scales vertically and horizontally.

After the application is restarted, the virtual app tier name appears as Business App 15. When you expand the tier on the Tiers & Nodes Dashboard, you see the nodes of the virtual applications and the root application.

The Nodes Dashboard displays the nodes of the tier Business App 15 in a similar manner.

Nodes of the virtual application are displayed in the Controller UI using the name of the virtual machine the app is running on, followed by the name of the virtual application as it appears in Azure Web Apps.

The current agent configuration file does not support targeting different virtual applications for customized tier naming, however, you can manually create .NET tiers and move the nodes to different tiers in the Controller UI.

Prevent Daas Instrumentation

You can prevent the agent from instrumenting the Daasrunner process by creating the environment variable AppDynamics.Processlist and setting it to w3wp.exe. This environment variable acts as a whitelist, where only the processes specified will be instrumented. Then delete the Daas tier and the Daasrunner node on the Tiers & Nodes Dashboard.  You might also want to include WebJob processes in this list.  See 'Specify Which WebJobs to Monitor' on Install the AppDynamics Azure Site Extension for .NET.


In this version, you cannot customize the tier names of virtual sub-applications in the AppDynamicsConfig.json file.

Also, this version does not support monitoring virtual apps together with deployment slots.

  • No labels