Certain types of applications, such as Windows Services or standalone applications, may not have entry points that are automatically detected by the .NET Agent.
For these cases, you can create custom match rules for Plain Old CLR Objects (POCOs), as described here.
To create a POCO custom match rule, define the custom match rule on the .NET class/method that is the most appropriate entry point for the business transaction. Someone who is familiar with your application code can help make this determination. You can also refer to the Custom Match Rules page.
You can optionally enable the Background Task option to have the transaction monitored as a background task. AppDynamics reports only Business Transaction metrics for background task transactions. It does not aggregate response time and call metrics at the tier and application levels for background tasks. See Monitor Background Tasks for more information.
After you create the rule, AppDynamics detects traffic on the matched entry point method and registers a business transaction for it, naming the transaction with the name of the custom match rule.
By default, you have to wait one minute and then restart the application to apply instrumentation changes required for new POCO entry points. If you create an application-level POCO that applies to a tier that has not yet registered with the Controller, you may need to restart the application after the tier registers in order to see the business transaction.
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.
As an alternative to defining POCO entry points as described here, you can use the transaction discovery tool to create match rules based on discovered transactions. For details, see Business Transaction Discovery Sessions.
On an originating tier, a POCO entry point is the method that starts the business transaction. If the POCO entry point is on a downstream tier, it may correlate to an upstream exit point. When defining a POCO entry point, it is important to choose a method that begins and ends every time the business transaction executes. For more on entry points, see Business Transactions.
Good candidates for POCO entry points include the following:
AcceptSocket() method is the blocking method that accepts a job and invokes it. The
MyProgram.DoWork() method is the unit of work because it executes every time a client calls the business transaction and it finishes at the same time as the business transaction. This makes
DoWork() a good POCO entry point.
AppDynamics automatically tracks POCO transactions for asynchronous, Task-based method entry points as end-to-end transactions. End to end latency metrics reflect the time it takes to complete the asynchronous actions associated with such methods.
To be tracked as an end-to-end transaction, the method you define as the POCO entry point must return a
Task object and use the
async modifier. In other words, the method signature should look similar to the following:
AppDynamics records the response times for such methods as it does for other types of methods—the response time reflect the time from when the method is called to when it returns control to the calling thread. However, for asynchronous task-based methods, AppDynamics records the time it takes for the asynchronous task to be fulfilled as an end-to-end transaction latency metric. For more information on end-to-end transactions, see End-to-End Latency Performance.