[smokeping-users] New module - continuous ping

[Steven Wilton]

On 24/11/15 21:22, Niko Tyni wrote:
> On Tue, Nov 24, 2015 at 07:25:08AM +0000, swilton at fluentit.com.au wrote:
>   
>> I have just finished work on a new module for running continuous pings.  At a minimum, it works on Debian 8 systems with the iputils-ping package installed, although any version of ping that supports the "-O" flag to report outstanding pings should work. It also requires IO::Epoll (Debian package libio-epoll-perl), and forks off a ping process for each target, so it will result in one ping process running continuously per target.
>>
>> It works by keeping a record of pings on a per-target basis based on the output of the ping processes, and then returning the recorded data when smokeping polls for the data.  I have seen some requests for similar functionality in past posts, so I thought I would share this.
> Very nice, many thanks for your work!
>
> A few comments; none of this should preclude inclusion in Smokeping
> (which is up to Tobi of course; I'm all for it.)
>
> - did you look at using 'fping -l' for this? I guess it could work with
>    just one ping process with that
>
> - I like the way you're keeping open pipes to the ping processes and tracking
>    them. This could probably be generalized into its own base* module if
>    there are other useful long running measurement processes...
>
> - does this recover if the actual ping process dying off for some reason?
>    It looks like it might, in the $io->close block around L147? (I guess
>    it's not a common issue, but it would be nice to catch it.)
>
> - does it handle ping sequence number wraparound? Those numbers are 16-bit
>    so I guess it could actually happen at some point. There's a record of
>    max_seq for each pinger, but it doesn't seem to get used anywhere, and
>    the dropped packet detection doesn't seem to break at wraparound AFAICS?
>
> - with multiple targets, it might be useful to be able to distribute
>    these pings more uniformly, so that all targets wouldn't get pinged at
>    the very same second. Similar concerns apply to basefork.pm I guess, and
>    probably only start to matter with a massive number of hosts...
>
> Thanks again,
Hi Niko,

I did have a look at using fping -l, but it does not give sequence 
numbers for packets in transit, which I am using to detect missed 
packets.  The logic was originally used and tested in a standalone 
script, but it may result in over-counting lost packets in some 
circumstances in the smokeping module where one FETCH results in 
assuming lost packets, and the next one reports the actual lost 
packets.  This would mainly be a concern with larger levels of packet loss.

If the ping process dies, the process will be re-started.  I may need to 
reap the child processes to keep things clean, since I did not do a lot 
of testing around killing the ping processes.

On L164 I check that the sequence number has not wrapped before setting 
the drops counter.  Once again this was important in the standalone 
script, but does not appear to be important in the smokeping module 
since I only add dropped packet records if $drops is > 0.

The pings will all start fractions of a second apart since they are 
started on the first attempt to FETCH results, and it is designed to run 
pings every second (or even down to around 5 pings per second per 
target), which is why I did not worry about staggering the start times 
manually.

I will run some tests on the above items before I send the push request 
to Tobi (which I will need to read up on how to do - I have done git 
push/pull request privately, but never on github or to someone else).

Steven