net.if.in["eth0",dropped] not reporting correctly

[Netbulae]

Hi,

Currently we have a client with dropped packets on their interface and I thought we were monitoring that.

But the values of "Interface eth0: Inbound packets with errors" remain 0 in zabbix.

We are using active 4.4 agents and 5.0 server in this environment, the net.if.in["eth0",bytes] are working fine.

On the device itself I see the dropped packets

ip -s -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether
RX: bytes packets errors dropped overrun mcast
24004595 145474 0 1270 0 0
RX errors: length crc frame fifo missed
0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
18877815 103579 0 0 0 0
TX errors: aborted fifo window heartbeat transns
0 0 0 0 2

And when I run the zabbix agent on it I can also see the correct values on the key the template uses for the item

/usr/sbin/zabbix_agentd -t "net.if.in["eth0",dropped]"
net.if.in[eth0,dropped] [u|1290]

/usr/sbin/zabbix_agentd -t "net.if.in["eth0",dropped]"
net.if.in[eth0,dropped] [u|1292]

So why are they not monitored :-&

[Netbulae]

When I run zabbix agent in debug log I also see the dropped packets

"host":"********","key":"net.if.in["eth0",dropped]","value":"1351","id":8,"clock":1682502540,"ns":889010414}

[cyber]

Hi,
But the values of "Interface eth0: Inbound packets with errors" remain 0 in zabbix.

/usr/sbin/zabbix_agentd -t "net.if.in["eth0",dropped]"
net.if.in[eth0,dropped] [u|1290]

You mix items here I think...

Your " Inbound packets with errors" is different item than "Inbound packets discarded"
net.if.in["{#IFNAME}",errors] vs net.if.in["{#IFNAME}",dropped]

Both are collected but only one is used in trigger (net.if.in["{#IFNAME}",errors] in "Interface {#IFNAME}: High error rate")

[Netbulae]

Hi,

Sorry typo. I'm looking for dropped packets.

Both are 0 continually, even though the agent reports a number of dropped packets. The graph is on 0, the data in zabbix also 0.

I see the preprocessing is "Change per second", could it be that this cannot be calculated because the gateway is unavailable? That would be strange as the dropped packets are the reason the data cannot be received.