The requisitionMetrics resource is collected via JMX bean org.opennms.netmgt.provision.overall:name=*. The data provided relates to performance of importing individual requisitions. When rescanning existing requisitions, this is helpful data. However, when making a change and syncing a requisition, the metrics are generated based on the pending requisition file, which can end up generating lots of pre-allocated RRD files and eat up unnecessary disk space.

I see a couple options:

• Update the resource type to include additional SiblingColumnStorageStrategy replacements to strip the pending and epoch timestamps off the resource type. This effectively collates all the metrics into a single resource instance, though it will skew data averages in RRD and make the data appear jumpy in Newts/Cortex by having multiple sets of data written to the same resource. I’ve tested this method and it’s easy but less accurate.

• Update how the beans are generated so there’s only metrics available for each requisition instead of each individual pending file. I imagine this is a much more difficult task, though should produce more accurate results.

I bring this up for dicsussion as we found an instance that had over 20GB of RRD files allocated for each edit/sync of requisition files. And with that many resource instances, the data becomes less relevant as it’s hard to find the exact instance that relates to the sync job you’re interested in investigating.