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[1]
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> [1]: 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.
Florian et.al.
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...]
TIA
-Greg
_______________________________________________
smokeping-users mailing list
[email protected]
https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users
