[ZBX-7840] icmppingloss gets a negative value of -100% Created: 2014 Feb 19  Updated: 2017 May 30  Resolved: 2014 Feb 24

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Server (S)
Affects Version/s: 2.2.2
Fix Version/s: 2.2.3rc1, 2.3.0

Type: Incident report Priority: Major
Reporter: Aleksandrs Saveljevs Assignee: Unassigned
Resolution: Fixed Votes: 3
Labels: icmpping, regression
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: JPEG File zabbixicmppingloss.jpg    

 Description   

The issue is the same as ZBX-2394, but applies to the current version.

Suppose we have a host that is pingable by both IPv4 and IPv6 (i.e., by both fping and fping6). Then the debug log will say the following:

7992:20140219:170128.182 Host [www.google.com] cnt=3 rcv=6 min/max/avg=0.000000/0.015390/0.007523

Since we think we received more packets than we sent, the result for "icmppingloss[www.google.com]" item is -100%.

 Comments   
Comment by Vladimir Goncharov [ 2014 Feb 20 ]

If in zabbix_server.conf disable fping6
(like this:

      1. Option: FpingLocation
        FpingLocation=/usr/sbin/fping
      2. Option: Fping6Location
        Fping6Location=)
        all work fine.
Comment by Andrey Shpak [ 2014 Feb 20 ]

Confirmed. See screenshot.

Comment by Mārcis Lielturks [ 2014 Feb 24 ]

Same here. After server and proxy upgrades from 2.2.1 to 2.2.2 icmppingloss was offset by "-100". Fixed by appending "Fping6Location=" to configuration files of server and proxies. One proxy was not updated to 2.2.1 together with others and reported correctly icmppingloss to server which was already running 2.2.2.

Comment by Aleksandrs Saveljevs [ 2014 Feb 24 ]

Might be a regression introduced in ZBX-7649.

Comment by Mārcis Lielturks [ 2014 Feb 24 ]

I want to fix "history" table. ZBX-1985 suggests, that Zabbix were sending twice as much requests and formula for calculation is "(1-recv/sent)*100". Is this true, and thus Zabbix actually were measuring packet loss with doubled precision? If so, then it seems that the correct way to "fix" history is with "update history set value=(value+100)/2 ....", right?

Thanks!

Comment by Aleksandrs Saveljevs [ 2014 Feb 24 ]

The bug only seems to affect hosts which are pinged by a DNS name that resolves to both IPv4 and IPv6.

It is pretty hard to fix the database in the general case, but assuming that the host is pingable only by IPv4, the SQL statement in Mārcis' post is the correct way to fix the database. I get the same formula.

Comment by Aleksandrs Saveljevs [ 2014 Feb 24 ]

Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBX-7840 .

Comment by Mārcis Lielturks [ 2014 Feb 25 ]

For me there were only 14 rows with broken values (besides the ones with -100) so fixing history was more of cosmetics to make graphs look nice again (btw, graph with fixed minimum of 0 appeared really weird when values were below 0)

Selecting broken values in "history" table for items with key "icmppingloss*"

select * from history where value<0 and itemid in (select itemid from items where key_ like 'icmppingloss%');

To fix the history.

update history set value = (value+100)/2 where value<0 and itemid in (select itemid from items where key_ like 'icmppingloss%');

Comment by Aleksandrs Saveljevs [ 2014 Mar 05 ]

Fixed in pre-2.2.3 r43224 and pre-2.3.0 (trunk) r43225.

Comment by richlv [ 2014 Mar 10 ]

just a small note - if this resulted in incorrect event generation, that would be notably more complicated to fix.
if any itservice sla calculation depends on such triggers/events, that would be wrong as well.

Generated at Tue Jan 07 20:16:57 EET 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.