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.
POCO Custom Match Rules Overview
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 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.
The .NET Agent for Linux supports the configuration of simple POCO business transactions through the Controller UI. See .NET Agent for Linux Business Transaction Configuration
Define a POCO Entry Point
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:
- A method in a socket application that executes every time a client connects
- A loop in a standalone application that batch processes records via a web service call. For example, an expense reporting system that loops through approved expenses to submit them for reimbursement.
- A Windows service that regularly executes a database call to check for new jobs to process. For example, consider the sample application logic below:
In the example, the POCO entry point would be defined on the namespace JobProcessor, class JobProcessorCore and method ProcessJob.
Task-Based POCO Entry Point Methods
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 reflects 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.