This page applies to an earlier version of the AppDynamics App IQ Platform.
For documentation on the latest version, see the 4.4 Documentation.


On this page:

Related pages:

Your Rating:
Results:
PatheticBadOKGoodOutstanding!
57 rates
 

The AppDynamics .NET Agent automatically discovers exit points to NServiceBus backends when an instrumented tier makes a call to NServiceBus over MSMQ or RabbitMQ transports. The agent discovers NServiceBus entry points for downstream correlation from NServiceBus version 5.

Exit Points and Backend Naming

NServiceBus exit points are methods that publish or push messages to a queue from an upstream tier. The agent detects exit points regardless of the NServiceBus version or threading architecture. The agent names the queue for the queue name returned from the system. 

Entry Points in a Single-threaded Architecture

NServiceBus entry points are methods that listen or poll for new messages in the queue. When message receiver uses a single-threaded architecture, the .NET Agent automatically discovers entry points and correlates downstream activity without additional configuration.

The agent measures the call time from the end of the first receive method to the start of subsequent receive method. In the following example loop, the length of the ProcessMessage() method:

MessageQueue messageQueue;
for(;;)
{
        // Call timing for previous iteration ends.
        var message = messageQueue.Receive();
        // Call timing begins.
        ProcessMessage(message);
}

 

Entry Points in a Multithreaded Architecture

For the .NET Agent to automatically detect NServiceBus entry points when the receiver is running a multithreaded architecture, set the nservicebus-single-threaded app agent node property to "false" on the receiver. See "nservicebus-single-threaded" on App Agent Node Properties Reference. For instructions to register a node property, see App Agent Node Properties.

For multi-threaded message receivers, the agent does not capture timing.

Resolve Issues with NServiceBus Backends

  • If you have NServiceBus version 5 and are not seeing downstream correlation on the receiver, verify the threading architecture on the receiver. Set the nservicebus-single-threaded app agent node property to "false" on the multithreaded receivers.

  • Only use the node properties for MSMQ, msmq-single-threaded and msmq-correlation-field, if you are using MSMQ independently of NServiceBus. The .NET Agent does not use MSMQ node properties when discovering and instrumenting NServiceBus over MSMQ transport.
  • If you are using NServiceBus version 4, you can disable NServiceBus instrumentation on both the publisher and the receiver:
    • Copy the following Instrumentation element to a child of the Machine Agent element:

      <!--Disable NServiceBus instrumentation-->
         <instrumentation>
           <instrumentor name="NServiceBusReceiveContextInstrumentor" enabled="false" />
           <instrumentor name="NServiceBusPublishExitInstrumentor" enabled="false" />
           <instrumentor name="NServiceBusEntryInstrumentor" enabled="false" />
           <instrumentor name="NServiceBusExitInstrumentor" enabled="false" />
         </instrumentation>

      For more information, see "Instrumentation Element" on .NET Agent Configuration Properties.

    • Configure the publisher and receiver as you would for MSMQ or RabbitMQ.