[smokeping-users] New module - continuous ping

Niko Tyni ntyni at debian.org
Tue Nov 24 14:22:16 CET 2015


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,
-- 
Niko



More information about the smokeping-users mailing list