Nagios Support Forum

I would like to know, how this packet loss is calculated by Nagios server in terms as how many packets were transmitted and how many dropped leading to % packet loss.

define service{
use generic-service
hostgroup_name nigeria
service_description Service ping
check_command check_ping!3000.0,20%!5000.0,30%
max_check_attempts 1
check_interval 2
retry_interval 2
check_period 24x7
notification_interval 2
notification_period 24x7
retain_nonstatus_information 1
notification_options w,c,r
contact_groups admins
}

By default there are 5 icmp packets sent so 20% would mean that 1 of the 5 was dropped.

cdienger wrote:By default there are 5 icmp packets sent so 20% would mean that 1 of the 5 was dropped.

what about the RTA


how we calculate getting this in the Screenshot shared. Please specify.

ericssonvietnam wrote: what about the RTA


how we calculate getting this in the Screenshot shared. Please specify.

RTA "round trip average" is the amount of time it took "ON AVERAGE" for those 5 pings to reach their destination and echo a return.

scottwilkerson wrote:

ericssonvietnam wrote: what about the RTA


how we calculate getting this in the Screenshot shared. Please specify.

RTA "round trip average" is the amount of time it took "ON AVERAGE" for those 5 pings to reach their destination and echo a return.

+++++++++++++++

First let’s understand how ping actually works.
 Ping works by sending an Internet Control Message Protocol (ICMP) Echo Request to a specified interface on the network and waits for a reply.

So it is very much possible that with a very slight latency in network, after Nagios sends the last (5th packet), it closes the ping execution, but the response is still awaited. In other words, the last packet response is received after ping execution is closed. Thus showing us packet loss of 20% (1 out of 5). {{Please point out if Nagios is using a different mechanism for ping test}}
The above scenario can also be observed when we manually use the ping command and do ctrl+C to stop the ping.

Thus 20% packet loss should not be raised as a network issue and requires more troubleshooting at automation end.

+++++++++++++++++

You can set the percentage you want for warning and critical. you could require it to be 100%

scottwilkerson wrote:You can set the percentage you want for warning and critical. you could require it to be 100%

Please suggest how to set the new warning threshold in ping.

ericssonvietnam wrote: Please suggest how to set the new warning threshold in ping.

Can you show your current configuration for this service in Configure -> CCM -> Services -> Edit (this service)

Then I can make suggestions

scottwilkerson wrote:

ericssonvietnam wrote: Please suggest how to set the new warning threshold in ping.

Can you show your current configuration for this service in Configure -> CCM -> Services -> Edit (this service)

Then I can make suggestions

I have configured the same in the core.

I'm sorry I didn't see it in your first post, if you change dthe check_command to the following it would require 100% packet loss to be critical