[smokeping-users] New module - continuous ping
swilton at fluentit.com.au
swilton at fluentit.com.au
Wed Nov 25 05:04:53 CET 2015
24 November 2015 21:22, "Niko Tyni" <ntyni at debian.org> 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,
While responding to your message last night, I realised that I had carried some unneeded functionality across from the standalone script that I was talking about into the smokping module. I also realised that I could use fping to reduce the number of forked processes, as well as being able to use IO::Select, which will be more portable. I have attached the fping module that I have just finished working on to this message, and I will probably just send a pull request for the fping version.
For the record, ping processes that were killed off in the previous version were handled cleanly.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 13637 bytes
Desc: not available
More information about the smokeping-users