Splunk AppDynamics

Effects of editing app-agent-config.xml to increase analytics-collectors-limit" value

CommunityUser
Splunk Employee
Splunk Employee

Hello,

We have a scenario where we see the following error in our agent log files.

ERROR AnalyticsCollectorFactory - Bounds exceeded creating analytics collector. Disabling Analytics Collection

 

Hence we are planning to edit the app-agent-config.xml to increase analytics-collectors-limit" value from 2200 (default ) to 5000 as show below

<agent-service name="Analytics" enabled="true" minimum-java-version="1.5">
<configuration-properties>
<property name="analytics-collectors-limit" value="5000"/>
</configuration-properties>
</agent-service>

We would like to understand if there is any overhead or effects/issues of doing this.

also if no downsides can i just change it to warn instead of stopping the Analytics collection as shown below.

<agent-service name="Analytics" enabled="true" minimum-java-version="1.5">
<configuration-properties>
<property name="analytics-collectors-limit" value="5000,WARN_IF_BOUND_EXCEEDED"/>
</configuration-properties>
</agent-service>

  

Please help with your thoughts.

Labels (1)
0 Karma
1 Solution

Chitra_Lal
Contributor

Hi Ajay,

Yes you can keep this configuration with:

<property name="analytics-collectors-limit" value="5000,WARN_IF_BOUND_EXCEEDED"/>

As it will not stop the analytics collection even if the limit is hit.

Regarding the other part of your query, this property "analytics-collectors-limit" enforces the application to stick to the limit which is set on the number of `AnalyticsCollector` instances that can be created in the Java Agent.  For each BT transaction their needs to be a corresponding `AnalyticsCollector` associated with it which extracts the information analytics needs from the Java Agent.  Normally there’s a shared pool of collectors that get reused but if there are too many concurrent transactions occurring at a time it can exhaust the pool and exceed the limit.  Normally this only happens for highly asynchronous applications.  Increasing the limit just means supporting a bigger pool of `AnalyticsCollector` instances which will cause some increase in heap usage (and possibly GC time) depending on how high the boundary is set. So shouldn't have any side affects if this is set to just warn and not completely stop monitoring.

Hope that clarifies. Do let m eknow in case you have any queries.

Thanks,

Chitra

View solution in original post

0 Karma

Chitra_Lal
Contributor

Hi Ajay,

Yes you can keep this configuration with:

<property name="analytics-collectors-limit" value="5000,WARN_IF_BOUND_EXCEEDED"/>

As it will not stop the analytics collection even if the limit is hit.

Regarding the other part of your query, this property "analytics-collectors-limit" enforces the application to stick to the limit which is set on the number of `AnalyticsCollector` instances that can be created in the Java Agent.  For each BT transaction their needs to be a corresponding `AnalyticsCollector` associated with it which extracts the information analytics needs from the Java Agent.  Normally there’s a shared pool of collectors that get reused but if there are too many concurrent transactions occurring at a time it can exhaust the pool and exceed the limit.  Normally this only happens for highly asynchronous applications.  Increasing the limit just means supporting a bigger pool of `AnalyticsCollector` instances which will cause some increase in heap usage (and possibly GC time) depending on how high the boundary is set. So shouldn't have any side affects if this is set to just warn and not completely stop monitoring.

Hope that clarifies. Do let m eknow in case you have any queries.

Thanks,

Chitra

0 Karma

CommunityUser
Splunk Employee
Splunk Employee
Thank you Chitra.
Appreciate it.
0 Karma
Get Updates on the Splunk Community!

Why You Can't Miss .conf25: Unleashing the Power of Agentic AI with Splunk & Cisco

The Defining Technology Movement of Our Lifetime The advent of agentic AI is arguably the defining technology ...

Deep Dive into Federated Analytics: Unlocking the Full Power of Your Security Data

In today’s complex digital landscape, security teams face increasing pressure to protect sprawling data across ...

Your summer travels continue with new course releases

Summer in the Northern hemisphere is in full swing, and is often a time to travel and explore. If your summer ...