Related pages: |
In , databases and remote services (and in fact, any detected out of process components that are involved in Business Transaction processing) are collectively known as backends.
discovers backends from exit point instrumentation placed in the application code. An exit point is the precise location in the code where an outbound call is made from an instrumented node.
automatically discovers a wide range of backends.
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, uses the backend properties to identify and name the backend. Where a backend call is actually processed by a downstream tier also instrumented with
, 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. 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.
To modify backend detection, you need the Configure Backend Detection permission.
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:
In many cases, you can achieve the level of customization that you need by editing the default rules rather than creating new rules.
To edit a rule, in the Backend Detection tab, select the application and Use Custom Configuration for this Tier, and click Edit Automatic Discovery.
For certain backend types—particularly those named by URL—the name of the discovered backend instances include a port number. If the app agent is unable to discover the port number for some reason, the port number is displayed in the UI as "-1". This can happen, for example, when a port is not a public port or the API for discovering the port is not available on the application environment (often the case for an RMI backend type). Despite having an unknown port number, the backends are nonetheless uniquely identified.
For many of the automatically discovered backend types, uses a set of configurable properties to identify and name the backend. For example, the properties for a JMS messaging queue are something like this:
The following informational popup shows how the values are used to identify a discovered backend. In the following example, callout 1 shows the value that corresponds to the destination type, callout 2 to the vendor name, and callout 3 to the destination queue name:
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 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.
provides the additional flexibility to create new custom discovery rules for the automatically discovered backend types.
To create a custom discovery rule for an automatically discovered backend type, select the backend type in the Automatic Backend Discovery list. Click Add (the + icon) to create a new rule. Specify the following:
See specific exit points for examples.
When a request matches more than one type of backend detection rule, agents apply backend detection rules in the following order:
Custom Exit Points > Custom Discovery Rules > Automatic Backend Discovery.
If detection rules are of the same type, agents apply backend detection rules based on rule priority from highest to lowest. A priority of 0 is the lowest priority possible.
For example, consider an HTTP request that matches a priority 2 custom discovery rule and a priority 6 custom discovery rule. The agent applies the priority 6 rule.
To configure exit point detection:
limits the number of backend systems that can be registered and tracked. Once the limit is reached (databases and remote services combined), additional backend are put in the "All other traffic for <type>" category.
The "type" is the backend type such as HTTP or Web Service. HTTP calls and JMS queues are the most common types that may reach the limit with the default configuration rules.
On a flow map, the category appears as follows:
Metrics for the backend calls grouped in the "All other traffic" category are aggregated. If the group includes backend instances that you want to be individually tracked, you can manage backend detection, as described in Manage Backend Discovery.
The limits on the number of backends that can be registered:
backend.registration.limit Controller Setting. This limit applies whether the backends are resolved to a tier or unresolved. When the backend count exceeds the limit, the "All Other Traffic" category is automatically created. The logs indicate that a limit has been reached by a log entry such as the following:
[pool-1-thread-2] 21 Mar 2013 11:28:01,702 DEBUG AFastBackendResolver - Not discovering backend call [Exit Point Type [WEB_SERVICE] Properties [{SERVICE_NAME=ZipCodeService002.wsdl}] Display Name [ZipCodeService002.wsdl]] because maximum limit of discovered backends [300] reached. |
After reaching the backend registration limit, you should make sure that the systems being tracked as first-class registered backends are the ones that are important to you relative to those in the "All Other Traffic" category.
Also make sure that application environmental conditions are not causing an excess number of backends to be registered. These conditions may include:
To manage backend registrations, you can 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.
To change the default backend limits of 300, configure the max-disocovered-backends property.
Some backends may no longer have traffic. You can delete unused backends from the Remote Services List, any Remote Service dashboard, the Databases List, and any Database dashboard. If the backend has new traffic in the future, the app agent rediscovers it and reregisters it with the Controller.
You can also configure the Controller to automatically remove stale backends. See Stale Remote Service Removal.
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 Remote Services on Flow Maps.