A discoverable backend is identified by its type and associated properties. The precise set of properties used to identify any given backend is dependent on its type. The type itself is defined in the built-in backend discovery rules for backend types supported out of the box. For exit calls to backends that are not instrumented with APM agents, Splunk AppDynamics uses the backend properties to identify and name the backend. Where a backend call is actually processed by a downstream tier also instrumented with Splunk AppDynamics, ensure that any given backend that is identified will always result in calls that will be processed by just one downstream tier.

This means, for example, that if tier A makes an HTTP call to an HTTP router on localhost:4040 which will forward the call to tier B or tier C depending on the URL, custom backend naming rules will be required to include enough segments of the request URL - as well as the host and port - such that requests destined for tier B will be associated with a backend with a different set of backend properties than those associated with tier C.

The Automatic Backend Discovery list in the Configuration > Instrumentation > Backend Detection tab shows the configurable backend discovery rules.

The automatic discovery rules vary according to the type of backend being identified, but generally include settings for enabling automatic discovery of the backend type, enabling correlation, and properties used to identify and name the backend. Splunk AppDynamics uses transaction correlation to track request processing across distributed tiers. Certain types of backends are automatically discovered as high volume exit points (sometimes called turbo exit points). These backend types include cache servers, EhCache, Danga Memcache, Memcached, and Oracle Coherence. For more about high volume exit points, see Exit Point Detection Rules.

When an exit point is identified for the first time, the exit call results in a backend discovery event.