.NET Backend Detection

The .NET Agent automatically detects many common backend types. Most backend types have a default discovery rule and a set of configurable properties. To revise backend discovery rules, see Backend Detection Rules and Exit Point Detection Rules.

For all other traffic transactions, see Business Transactions.

ADO.NET Backends

The .NET Agent automatically discovers ADO.NET data providers implementing standard Microsoft interfaces as database backends. See .NET Supported Environments.

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

AppDynamics uses database identification 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 based on common rules that you can parse and distill to a database name. However because no standards exist for the connection string, the ADO.NET provider implementer determines 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 .NET Agent names this 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 these properties for ADO.NET exit points:

Azure Service Bus Backends for .NET

The .NET Agent automatically detects Azure Service Bus backends when an instrumented tier makes a call to Azure Service Bus. The agent supports client library Azure.Messaging.ServiceBus version 7.0.0 and later.

Azure Service Bus exit points are methods that send or publish messages to queue or topic. Azure Service Bus entry points are methods that receive messages from a queue or a topic. The agent supports queue correlation from a sender exit call to a receiver entry point.

If you are using NServiceBus over the Azure Service Bus transport, see NServiceBus Backends for .NET.

Exit Points and Backend Naming

The agent discovers an Azure Service Bus backend exit point when a downstream application sends or publishes a message or a batch of messages to a queue or a topic.

The agent identifies a backend with the following properties:

• Address: URI address to the Azure Service Bus Server. For example, //myservicebusname.servicebus.windows.net/.
• Host: Host of the Azure Service Bus Server. For example, myservicebusname.servicebus.windows.net.
• Path: Name of the queue or the topic where the message is sent or published. For example, myqueuename.

The agent names the backend as Address/Path. For example, amqps://myservicebusname.servicebus.windows.net/myqueuename.

Entry Points

The agent discovers Azure Service Bus entry point when an upstream application receives a message from a queue or a topic. The Agent names the entry point as Address/Path, similar to backend.

The Agent supports the ServiceBusProcessor Message Handler receiving pattern.

ServiceBusProcessor Message Handler

The agent detects the below pattern where the application processes an incoming message using a message handler configured using ServiceBusProcessor. In this case, the call timing reflects the execution time of the entire handler. The agent also detects the exit calls made within the handler.

ServiceBusClient client = ...;
string queueName = ...;
await using ServiceBusProcessor processor = client.CreateProcessor(queueName);
processor.ProcessMessageAsync += args =>
{
    Console.WriteLine($"Message Received: {args.Message.Body}");
    // more logic if needed
};

Other Patterns

The agent detects an entry point when an application calls ServiceBusReceiver.CompleteMessageAsync(ServiceBusReceivedMessage,CancellationToken) which can be used in other receiving patterns. However in this case the call timing reflects only the time spent on completing a message. The agent does not detect exit calls while handling the message for this pattern.

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 cannot derive the server name from the request, it then constructs a name using Domain Component (DC) values.

For example: activedirectory.example.com

HTTP Backends

AppDynamics automatically detects HTTP exit points (backends). See HTTP Backend Detection.

.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 Windows and Linux versions of the .NET Agent, you can enable or disable the use of these properties for HTTP exit points: 

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

This table list the properties used for queue exit points. However, each message-oriented product is different and there may be variations in the properties, or their names.

For 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 these properties for MongoDB exit points:

.NET Remoting

When an application uses .NET remoting, AppDynamics automatically detects and identifies remoting exit points (backends). See Enable Correlation for .NET Remoting to configure downstream correlation.

The default remoting automatic discovery rule uses the URL property. 

For example: tcp://remoting.example.com:8648/MovieTicketBooking

.NET Remoting Configurable Properties

You can configure the use of this 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 

This table describes the WCF backend detection support for each variant of the .NET Agent:

WCF Configurable Properties

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

.NET Web Services Backends

When an application uses the Microsoft Web Services client library, AppDynamics automatically detects and identifies web services exit points (backends) by default. 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 these properties for Web Services exit points:

Custom Exit Points

To monitor a backend that is not included in .NET Supported Environments, you can 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 to avoid having to restart your application and the AppDynamics.Agent.Coordinator after instrumentation changes.