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:

• JMS queues that use the session ID in the destination. This causes each session to be identified as a separate backend.
• Calls to message queues hosted on the same server. In this case, you might not be interested in seeing each queue separately, and instead, want to aggregate everything for the same host and port to the same backend.
• Dynamic generation of IP addresses, such as when you host a service on Amazon Elastic Compute Cloud (Amazon EC2).
• Different JDBC drivers connecting to the same database may cause many backends. This can happen when there are slight variations in the driver metadata that Splunk AppDynamics uses to identify the database. For example, if two different JDBC drivers are used to access the same database, something as simple as a different spelling or format of the database name (ORACLE, oracle, or ORACL) can generate multiple database names when they are the actually the same physical database.

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.