AppDynamics Application Intelligence Platform
Each type of supported database and remote service has a list of properties associated with it. Each supported backend is identified by its type and the related properties. This set of preconfigured properties are referred to as backend automatic-discovery rules. AppDynamics uses these rules to identify and name the databases and remote services.
By default, the configuration for backend discovery is inherited from the tier or application level configuration. See Hierarchical Configuration Model.
The Automatic Backend Discovery list in the Backend Detection tab shows the configurable backend discovery rules.
The automatic discovery rules vary according to the type of backend being identified. The default discovery rules include settings to enable the following:
Correlation across tiers enables tracking of distributed business transactions. When calls are made from one tier to another, correlation enables AppDynamics' tag and trace functionality. For more details, see Measure Distributed Transaction Performance.
If you know that the application flow map should be showing a specific backend and you are not seeing it, you can modify the configuration to detect backends. You can:
For example, HTTP backend detection is enabled by default. HTTP backends are identified by host and port (Java) or URL (.NET and PHP) and correlation is enabled (Java and .NET). AppDynamics allows you to easily edit the HTTP automatic discovery rules for Java and .NET.
In the left navigation pane click Configure -> Instrumentation -> Backend Detection and select the application. In many cases, you can achieve the level of customization that you need by editing the default rules.
For many of the automatically discovered backend types, AppDynamics uses a set of configurable properties to identify and name the backend. The properties are a list of name-value pairs. For example, the properties for a messaging queue might look like this:
Property Name DESTINATION_TYPE
Property Name DESTINATION_NAME
Property Name VENDOR
*Value* Active MQ
On its dashboard flow map, this queue appears like this:
Values for each property appear on the dashboard as follows:
In this example, the default configuration uses all three properties for the ActiveMQ queue. You can change the default configuration for the backend types shown in the UI to aggregate or split the backends. For example, you could disable the Vendor property for JMS backend detection to aggregate (join) all JMS backends with the same destination and destination type. The metrics for all JMS backends with the same destination and destination type would be aggregated as one backend.
For properties that you want to use, you can also configure how AppDynamics uses the property. For example, if the URL property is used to identify a backend and your URLs include a file name, the default configuration results in a separate backend for every file. To reduce the number of backends identified using the URL property, configure which parts of the URL to use. For example, run a regular expression on the URL to discard the file name or any other parts of the URL that you do not want used for identification.
When you see "All other traffic for <type>" on an application flow map, your application has reached the default backend limit and no new backends are tracked. There is a limit of 300 backends (combined total of discovered databases and remote services) per AppDynamics business application. When the limit is reached, additional backends are not identified and tracked as separate backends; instead AppDynamics groups the additional backends by type and aggregates the metrics. The aggregate backends are represented on the flow maps as one backend named "All other traffic for <type>". Type is the backend type such as HTTP, Web Service, etc. HTTP calls and JMS queues are the most common types that hit the limit with the default configuration rules.
Another way to know that the default backend limit is reaches is when you see a message like this one in the logs:
If the backend limit is reached, consider reducing the number of them. For practical reasons you may not need to monitor them all.
Here are some common causes of large numbers of backends:
To reduce the number of backends, change the configuration of the backend detection rules. For example, if a property causes excessive unique identification, consider removing the property or modifying its use in the detection and naming rule. If you created custom exit points, consider refining or removing them.
Some backends may no longer have traffic. You can delete unused backends from the Remote Services Dashboard and Databases List and Dashboard. If later the backend has new traffic, the app agent will re-discover it and re-register it with the Controller.
You can also configure the Controller to automatically remove stale backends. See Remove Stale Backends.
Once you have configured detection for all the backends you require, you may need to organize the way they appear in the UI. See Group Backends on Flow Maps.