gregs at sloop.net
Thu Jun 26 02:12:13 CEST 2014
FP> On 21.02.2014 06:42, Philip Wehunt wrote:
>> I could hackishly work around this in my python but I wanted to
>> identify if I am doing something wrong on the SP side or if it is a
>> bug. Mainly in the spirit of KISS. I don't like to let hackish
>> scripts linger.
FP> You probably found the same script on gist, but here's my version
FP> which doesn't fail when the 6th arg is missing. It will not add "
FP> cleared" to the subject without the arg, but it will send you the report.
FP> : https://git.server-speed.net/users/flo/bin/tree/smokemtr.py
FP> From the documentation in smokeping_config I'd say this is a bug, but
FP> given I get my mails I didn't bother fixing it yet.
First, thanks for the script. I've had to mod it a bit - my MTR isn't quite the same as yours and I want to use a non-local SMTP server and port - but those were easy mods. [MTR is in a different spot too, again easy mod.]
So, I'm very excited about the prospects of automated mtr stats when a smokeping alert gets triggered - however I run into a substantial snag.
I use a 60s poll in smokeping, and if I get a bunch of [smokeping] alerts that kick off, then, when each MTR takes a while to run, it stalls smokeping.
This causes a ripple-effect, and a raft of nagios alerts...since I use a smokeping nagios plug-in. When SP stalls [running the mtr's] the RRD's go dry, and then nagios starts alerting on an "unknown" target state. ["This RRD hasn't been written to in 180s" etc.]
So, is there some way I can fork off the mtr script, and allow smokeping to continue while the mtr stats are gathered and a report sent?
[This is something I'm woefully un-knowledgeable about...]
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the smokeping-users