-
Problem report
-
Resolution: Unresolved
-
Trivial
-
None
-
None
-
None
Preprocessing step "CHANGE_PER_SECOND" missing in "net.if.out.discardsifOutDiscards.{#SNMPINDEX}" item in "FortiGate by SNMP" template
Found an issue regarding the preprocessing of the item with key “net.if.out.discardsifOutDiscards.{#SNMPINDEX}” as the summary says. It can be checked in the repository https://git.zabbix.com/projects/ZBX/repos/zabbix/browse/templates/net/fortinet/fortigate_snmp/template_net_fortigate_snmp.yaml?at=refs%2Fheads%2Frelease%2F7.0#1704
The item with the key “net.if.in.discardsifInDiscards.{#SNMPINDEX}” does have that preprocessing step https://git.zabbix.com/projects/ZBX/repos/zabbix/browse/templates/net/fortinet/fortigate_snmp/template_net_fortigate_snmp.yaml?at=refs%2Fheads%2Frelease%2F7.0#1625, that was the way we found the issue.
There are two main reasons why we consider this to be an issue:
- Inconsistency in template design*:*
If the missing CHANGE_PER_SECOND preprocessing step in the item Interface _ {#IFNAME}({#IFALIAS}): Outbound packets discarded_ is intentional, then it creates an inconsistency within the template. The corresponding inbound item Interface {#IFNAME}({#IFALIAS}): Inbound packets discarded does include this preprocessing step, even though both items are conceptually equivalent—they both monitor interface discard counters, which are monotonically increasing and typically require a rate calculation for meaningful analysis. There is a clear asymetry.
- Misleading data collection:
If the preprocessing step is truly missing by mistake, then the outbound discard item is currently collecting raw counter values instead of the rate of change.
In both scenarios, the behavior is problematic, either due to inconsistency or from the rate conversion point of view.