Some device charts showing Interface bits-in/out traffic intermittently have gaps in data. Why does this occur?
DX NetOps CAPM all releases
Sometimes, this can be a problem with the devices themselves. If there are many warning messages in the DC logs where it was not able to contact or poll the device/s due to timeout:
2021-06-12 12:00:53,715 | WARN | 300000-thread-1 | ThrottleCounterManager | or.common.ThrottleCounterManager 279 | 195 - com.ca.im.data-collection-manager.core.common - 20.2.7.RELEASE-497 | | Polls not sent due to TIMEOUT: /xxx.xxx.xxx.xxx=177 /xxx.xxx.xxx.xxx=158
Or if there are instances where a 32bit counter has rolled over:
2021-08-30 06:42:48,442 | INFO | cutor-thread-297 | CounterRollover | .dm.snmp.rdp.impl.SnmpDeltaCache 368 | 190 - com.ca.im.data-collection-manager.core.interfaces - 20.2.7.RELEASE-497 | | Counter value rolled over, dropping response: previous=4056881085 / current=6041337 for ip xxx.xxx.xxx.xxx, OID 126.96.36.199.188.8.131.52.1.10.436793344, itemID 172819, in poll group 4074.
The metric in this case is IfInOctets (OID= 184.108.40.206.220.127.116.11.1.10). This is a 32-bit counter.
So when the value becomes too large for a 32 bit counter to hold, the counter rolls back to 0 and starts again, meaning the poll is dropped.
The device may not actually be supported in CAPM. You can check this on our Certification portal:
DX NetOps Certification Portal
However, it maybe closely related to other devices that are certified with many of the same OIDs and MIB structure. In this case CAPM is able to discover it and associate Metric Families to it, but since it's not accurately fully certified, it is only using the 32 bit counters (default) of the Interface Vendor Certification instead of the 64 bit in High Speed Interface VC.
So, without proper certification, CAPM uses 32 bit counters with the resulting counter rollover errors such as the following that cause dropped polls (which appear as data gaps):
2021-09-03 10:26:32,718 | INFO | cutor-thread-304 | CounterRollover | .dm.snmp.rdp.impl.SnmpDeltaCache 368 | 190 - com.ca.im.data-collection-manager.core.interfaces - 20.2.7.RELEASE-497 | | Delta calculated is greater than or equal to 1000000000; dropping response: previous=186815782 / current=2931171055 for ip xxx.xxx.xxx.xxx, OID 18.104.22.168.22.214.171.124.1.16.151060891, itemID 172757, in poll group 4074.
2021-09-03 10:26:36,102 | INFO | cutor-thread-305 | CounterRollover | .dm.snmp.rdp.impl.SnmpDeltaCache 368 | 190 - com.ca.im.data-collection-manager.core.interfaces - 20.2.7.RELEASE-497 | | Counter value rolled over, dropping response: previous=3737149325 / current=273837373 for ip xxx.xxx.xxx.xxx, OID 126.96.36.199.188.8.131.52.1.10.436330496, itemID 67563, in poll group 4074.
The only way to overcome this without certification is to use fast polling, as per:
TechDocs : DX NetOps CAPM : Poll Critical Interfaces Faster than Non-critical Interfaces
We have another KB article that advises further on how to address these sorts of issues:
KB : Best practice for resolving CA Performance Center when graph chart plot data lack/missing