Werk #20150: NetApp ONTAP: fix iSCSI latency calculation
| Component | Checks & agents | ||||||||
| Title | NetApp ONTAP: fix iSCSI latency calculation | ||||||||
| Date | Jul 30, 2026 | ||||||||
| Level | Trivial Change | ||||||||
| Class | Bug Fix | ||||||||
| Compatibility | Incompatible - Manual interaction might be required | ||||||||
| Checkmk versions & editions |
|
This werk impacts those who monitor NetApp ONTAP systems using iSCSI or FCP.
The latency counters of the ONTAP counter manager are not final latency values. They are cumulative average counters in microseconds and have to be divided by the corresponding operations counter to obtain the latency of a single operation.
Two check plugins did not follow that rule for the SAN protocols:
netapp_ontap_volumes(Volume services): the iSCSI and FCP latencies were divided by their operations counter correctly, but the graphs interpreted the result as milliseconds instead of microseconds. The graphs therefore showed a latency a factor of 1000 too high.netapp_ontap_vs_traffic(Traffic SVM services): the iSCSI latency counters were not divided by their operations counter, because the counter was looked up under a protocol name that the check does not use.
Both plugins now report the latency per operation. Metric names and service descriptions are unchanged and no re-discovery is required.
For the Volume services the correction is applied when the graph is rendered. It therefore also applies to the data recorded before this update: those graphs show correct values over their whole history and stay continuous.
For the Traffic SVM services the recorded values were not a mis-scaled latency but a different quantity altogether, so they cannot be converted. The iSCSI latency graphs of these services will drop to their correct, much smaller values at the moment of the update, and the data recorded before it is not comparable to the data recorded afterwards, therefore this werk is flagged as incompatible.