On 24/11/15 21:22, Niko Tyni wrote:
On Tue, Nov 24, 2015 at 07:25:08AM +0000, [email protected] 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
_______________________________________________
smokeping-users mailing list
[email protected]
https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users
