Related pages:

Custom exit points enable you to identify backend types that are not automatically detected. For example, you can define a custom exit point to monitor code calls to a file system read method.

After you have defined a custom exit point, the backend appears on the flow map with the type-associated icon you selected when you configured the custom exit point.

Configuration Notes

You configure exit point detection in the Configuration > Instrumentation page. Select the Backend Detection tab and choose the application or tier on which to configure an exit point and the application type of the exit point, Java, .NET, and so on. From there you can add new exit points or modify existing ones. 

The specific configuration options available differ based on the application type, but in general, you identify the exit point and specify the mechanism for it to be detected, such as a class and method name. These additional notes apply to exit point configuration: 

  • If the method you are using to identify the exit point is overloaded, you need to add the parameters that identify the signature for this form of the method.
  • Match conditions let you restrict the method invocations for which you want AppDynamics to collect metrics based on runtime values tested by the condition. Match conditions can test parameter values or any value accessible by getter chain from the invoked object.
  • Optionally, you can split an exit point based on a method parameter, the return value, or the invoked object.

  • You can configure custom metrics and transaction snapshot data to collect for the backend.

  • If you configure a custom backend for a method that encapsulates an automatically detected backend, such as an HTTP client call, you may lose correlation from the automatically detected exit call.

  • Splitting a backend on return value may break correlation.

    You are limited to 50 characters for the exit point value when adding a custom exit point or splitting/grouping exit points.

Adding a Custom Exit Point

When adding a custom exit point, you specify the class and method that identify an external call to the exit point. You can refine the call by specifying a return value, parameter, or getter chain match value. 

The type you choose determines the icon that appears in the flow map for the custom exit point. If the type is not listed, select Use Custom and enter a string in the Type field to identify the exit point calls in the UI.

Note that you can also split the exit point based on these values. If you add a split condition for an exit point, it means that any exit point that matches the overall match condition for the custom exit point is further evaluated against the split condition. If its call matches the split condition, it is given the more specific name you configure in the split exit point configuration. 

High Volume Exit Points

The Is High Volume option for custom exit points lets you create an optimized exit point configuration for backend systems with high-performance requirements, such as caching servers or in-memory databases. 

A "high volume" exit point keeps the overhead associated with the exit point to a negligible amount by bypassing certain processing operations on calls to this exit point. As a result, transaction correlation and error detail reporting are not available for the exit point, nor are match conditions in the exit point configuration. 

With a high volume exit point, you do get the number of calls, number of errors, and average response time for calls.

Splitting and Grouping Exit Points

By splitting an exit point, you can use dynamic application values to identify an exit point. Specifically, you can use the value of either a method parameter, the method return value, or a value returned by a specified getter chain on the invoked object of the identified method. The configuration settings you use to configure exit point splitting are the same as used for Data Collectors. See Data Collectors for information on how to use the configuration UI.

A simple example of how you would use exit point splitting is for a cache exit point. In this example, say you configure splitting for an exit point that identifies a method for writing to the cache. The object on which the method for writing to the cache offers a method to get the current cache name, the getCacheName() method. By configuring a split on this method (as a getter chain on the invoked object), you can have the exit point named with the name of the cache node, as dynamically determined: 

Splitting also lets you group exit points. Given an exit point for NamedCache.entrySet(), as shown in the example above, suppose we created another exit point. This one uses the getAll() method on the same class, NamedCache. It also has a split configuration that uses the getCacheName() method of the invoked object.

If the  getCacheName() getter chain points to the same cache name when the getAll() and the entrySet() methods are invoked, they will be shown as calls to the same backend.