The Data Collector will cache up to 50% of configured Data Collector memory by default per per How Data Collector caches data when the Data Aggregator is down
This can be increased beyond this as needed.
DX NetOps Performance Management all versions
To increase the configured value follow these steps.
The file creation and edits are tracked in the DC karaf.log file file found in /opt/IMDataCollector/apache-karaf/data/log.
Recommend creating the file one of two ways and tracking log messages to see it get read into the running process.
In the karaf.log we'll see messages like this when the file is added or edited.
025-03-10T16:39:30,866 | INFO | -karaf-4.4.6/etc | fileinstall | install.internal.Util$OsgiLogger 205 | 12 - org.apache.felix.fileinstall - 3.7.4 | | Creating configuration {com.ca.im.core.jms.health} from /opt/IMDataCollector/apache-karaf-4.4.6/etc/com.ca.im.core.jms.health.cfg
2025-03-10T16:39:30,871 | INFO | core.jms.health) | JmsBrokerHealthService | ms.health.JmsBrokerHealthService 57 | 31 - com.ca.im.common.core.jms - 24.3.5.RELEASE-6 | | JMS Health: set PRQ maxdiskspace =10G
We'll see messages like this if the file is deleted.
2025-03-10T16:40:12,873 | INFO | -karaf-4.4.6/etc | fileinstall | install.internal.Util$OsgiLogger 205 | 12 - org.apache.felix.fileinstall - 3.7.4 | | Deleting configuration {com.ca.im.core.jms.health} from /opt/IMDataCollector/apache-karaf-4.4.6/etc/com.ca.im.core.jms.health.cfg
KB Article: How to confirm that the DC is collecting data
This configuration is not tested.
By extending the cache, it will take longer to reach live data being seen, as it must process the cached data first.
Thresholding times may go up as more timestamps would need to be processed in a shorter amount of time.
This may tax the thresholding engine, and possibly leading it to move to a state of degraded and ultimately disabled.