.NET Backend Detection

The .NET Agent automatically discovers many common backend types. Most backend types have a default discovery rule and a set of configurable properties.

For instructions to revise backend discovery rules, see Backend Detection Rules.

ADO.NET Backends

The .NET Agent automatically discovers ADO.NET data providers implementing standard Microsoft interfaces as database backends. For a complete list, see "Supported ADO.NET Clients" on .NET Supported Environments.

Because the ADO.NET API is interface-based, by default AppDynamics instruments all ADO.NET database providers that implement these interfaces.

For database identification, AppDynamics uses information from the ADO.NET connection string. The connection string specifies the server address and schema or the local file name. Most connection strings are formatted according to well-known rules that can be parsed and distilled to a database name. However, because there is no standard on the connection string, it is up to the ADO.NET provider implementer to choose the format.

For some providers, AppDynamics may fail to parse the connection string. In these cases, the .NET Agent uses the complete connection string minus any user password. The property is labeled ADO.NET connection string and the value shows the connection string minus any user password.

For example, the agent names following database backend using the connection string pattern <datasource name>-<database name>:

.\SQLEXPRESS-HowdyWorldDB

ADO.NET configurable properties

You can enable or disable the use of the following properties for ADO.NET exit points:

Directory Service Backends

The .NET Agent automatically discovers exit calls to directory services that use the System.DirectoryServices.Protocols (S.DS.P) libraries.

The agent names the backend for the server name. If the agent is unable to derive the server name from the request, it constructs a name using Domain Component (DC) values.

For example, activedirectory.example.com

HTTP Backends

AppDynamics automatically detects HTTP exit points (backends). 

.NET Agent for Windows

For the .NET Agent for Windows, the default HTTP automatic discovery rule uses the URL property.  From the enabled properties AppDynamics derives a display name using the URL.

For example,

http://api.example.com:8989/searchfares

.NET Agent for Linux

For the .NET Agent for Linux, the default HTTP automatic discovery rule for backends uses the host name and port number. 

For example:

http://api.example.com:8989

HTTP configurable properties

For both the Windows and Linux versions of the .NET Agent, you can enable or disable the use of the following properties for HTTP exit points:

New in 4.5.13 You can now customize HTTP backend detection and naming for the .NET Agent for Linux through the Controller UI.
Customizing HTTP backend detection and naming is a feature preview in this agent version, recommended for pre-production systems. For information on enabling preview features, see Enable Preview Features.

Message Queue Backends

By default, AppDynamics automatically detects and identifies many message queue exit points. For a list of the supported message-oriented middleware products, see Supported Remote Service Detection for .NET.

The default queue automatic discovery rule uses the destination property to name the message queue backend.

For example:

HowdyWorldQueue$\HWT_MQ_Server1_MsgQ

Message Queue Configurable Properties

In general, the properties listed below are used for queue exit points. However, each message-oriented product is different and there may be variations in the properties or their names.

For more information on specific queue types, see:

• MSMQ Backends for .NET
• NServiceBus Backends for .NET
• RabbitMQ Backends for .NET 

MongoDB Backends

By default the .NET Agent detects MongoDB exit calls for create, read, update, and delete (CRUD) operations using the C# and .NET MongoDB Driver versions 1.10, 2.0, 2.2, and 2.4.

The default MongoDB automatic discovery rule uses the host, port and database name to name the MongoDB backend. For example, mymongohost.27017.mymongodb.

MongoDB configurable properties

You can configure the use of the following properties for MongoDB exit points:

.NET Remoting

AppDynamics automatically detects and identifies remoting exit points (backends) when an application uses .NET remoting. 

The default remoting automatic discovery rule uses the URL property. For example, tcp://remoting.example.com:8648/MovieTicketBooking

See Enable Correlation for .NET Remoting to configure downstream correlation.

.NET Remoting configurable properties

You can configure the use of the following property for .NET Remoting exit points:

WCF Backends

AppDynamics automatically detects and identifies WCF exit points (backends) when an application uses the WCF client library. The default WCF automatic discovery rule uses the remote address property. The agent uses the enabled properties to derive a display name using the remote address.

For example, http://wcf.example.com:8205/Services/Service1.svc

Agent Compatibility 

The table below describes the WCF backend detection support for each variant of the .NET Agent. 

WCF configurable properties

You can enable or disable the use of the following properties for WCF exit points:

.NET Web Services Backends

By default, AppDynamics automatically detects and identifies web services exit points (backends) when an application uses the Microsoft Web Services client library. The default web services automatic discovery rule uses the URL property. From the enabled properties AppDynamics derives a display name using the URL.

For example, http://webservice.example.com:8105/Services/Service1.asmx

Web Services configurable properties

You can enable or disable the use of the following properties for Web Services exit points:

All Other Traffic

For information on All Other Traffic transactions, see Business Transactions.

Custom Exit Points

If you want to monitor a backend that isn't listed under 'Remote Service Detection' on .NET Supported Environments, then configure a custom exit point.

By default, you have to restart the instrumented application for instrumentation changes to take effect. You can enable Runtime Reinstrumentation for the .NET Agent so that you don't need to restart your application and the AppDynamics.Agent.Coordinator after instrumentation changes.