Two similar derived metric seem to collecting data differently - one is showing gaps in the colle (4262647)

There are two derived metrics which get calculated in a similar way but when looking at the data for one of the metrics gaps are seeing in the values retrieved at regular intervals.

This is likely to be a problem with data rollups.

1) The first generation in a retention policy determines when the data is written from memory to the DB. In this case, for this metric, If the first generation says keep 4 hour data for 1 week this effectively tells the FMS to “keep this data in memory for 1 week”. In this situation it is occupying unnecessary JVM heap with this retention policy storing this metric. It’s not a lot of memory, but it’s unnecessary and if the FMS crashes unexpectedly, that data is lost.

2) While the data is stored in memory, it is subject to internal rollups as the FMS tries to manage the JVM memory as best it can. This can cause the behaviour seen.

WORKAROUND 1

Delete the specific first generation policy for the derived metric from the Manage Retention Policies dashboard.

,

WORKAROUND 2

Add an additional retention policy similar to the default for the particular topology object type being scoped to be the derived metric, e.g. after 15 minutes rollup the data to 15 minute chunks