<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Hi Greg</div><div><br></div><div>Thanks for answering. I configured your tree level steps and will see what's happening :)</div><div><br></div><div>Running nagios also on the RB-pi2 is to heavy i guess. </div><div><br></div><div>Let's monitor and see what the alarms are providing. </div><div><br></div><div>Thanks for your help</div><div><br><br><div><span style="background-color: rgba(255, 255, 255, 0);">Groeten Rob de Hoog</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">Verstuurd vanaf mijn iPhone</span></div></div><div><br>Op 3 jul. 2015 om 22:04 heeft Gregory Sloop <<a href="mailto:gregs@sloop.net">gregs@sloop.net</a>> het volgende geschreven:<br><br></div><blockquote type="cite"><div><title>Re: [smokeping-users] pocketless alarm question, sending to soon the alarm emails.</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<span style=" font-family:'Courier New'; font-size: 9pt;">Putting it back on-list. [you emailed me directly - no offense taken - but it's better to be on-list...]<br>
<br>
Ok...<br>
<br>
Heavy load on a pipe, at least in my experience, doesn't cause much packet loss. It will however increase latency. So, I think a test like >10%,*5*,>10%,*5*,>10%,*5* [hopefully there no syntax errors there...]<br>
[meaning any three losses of >10% over 3-30m would trigger things.]<br>
<br>
I use: <br>
>15%, *3* ,>15%, *3* ,>15%<br>
>30%, *10* ,>30%, *10*, >30%, *10*, >30%<br>
>50%, *10* ,>50%, *10*, >50%, *10*, >50%<br>
...for a first, second and third level trigger.<br>
<br>
But - I only use the triggers to generate an MTR - the MTR comes in very handy in arguments with providers [Hello Comcast] when they claim the problem must be somewhere else other than their network. (Though to be fair, the tendency to blame someone else is a *very* strong one in most help-desk/support situations. And it so pisses me off!) The MTR script runs an MTR trace of that path, and emails me the result.<br>
<br>
I do all my *alerts* with Nagios - using the smokeping plugin.<br>
In those cases, I use something like a warning for >10% loss or more for 5m, and critical with >40$ for 5m. [Nagios doesn't use an elaborate trigger system like Smokeping. But I don't get many false-positives with either setup. YMMV.]<br>
<br>
Using Nagios allows me to more carefully manage alerts and when/how/where they're delivered - which makes life a lot easier. For example - no need to buzz me about a non critical backup link at 2a. But when the smelly stuff does hit the fan, I'll get the alerts I need. So, I abandoned using Smokeping for alerts quite a number of years ago.<br>
<br>
I could dig up specifics if you really need them, but that's what I recall off the top of my head.<br>
<br>
Cheers,<br>
Greg<br>
<br>
</span><table>
<tbody><tr>
<td width="2" bgcolor="#0000ff"><br>
</td>
<td><span style=" font-family:'courier new'; font-size: 9pt;">Hi Greg <br>
<br>
thanks for your email, agree on make it simpeler.<br>
<br>
The goal i want is to monitor a serious problem asap, but prevent from false positives generated by people congesting the line with huge downloads.<br>
<br>
How would you solve this, do you monitor such and would you be able to share the configuration?<br>
<br>
thanks Rob<br>
<br>
<br>
Op 3 jul. 2015, om 18:08 heeft Gregory Sloop <</span><a style=" font-family:'courier new'; font-size: 9pt;" href="mailto:gregs@sloop.net">gregs@sloop.net</a><span style=" font-family:'courier new'; font-size: 9pt;">> het volgende geschreven:<br>
<br>
Re: [smokeping-users] pocketless alarm question, sending to soon the alarm emails. <br>
A few thoughts - though not exactly an answer to your question:<br>
<br>
1) I'm often too dense to grok out why more elaborate triggers don't work the way I want, and your falls into that category. But this seems, IMO, to be a very common problem. So, my solution: Make them simpler. Way simpler. [It's kind of like fancy regexs - I think I'm *so* clever and pat myself on the back. But then I actually run that regex against more real-world data, and well, it doesn't end pretty... So, I usually go back to - simpler is better, unless it's impossible to solve otherwise.] <br>
<br>
2) In your case - do you really want to wait 75 minutes to find out a connection is completely down? [Or perhaps you have another trigger that does that.] But even if you do - this is just my opinion - but loss greater than 10% over more than 10-15 minutes is a sign of a _serious_ problem. So, I have simple triggers that let me know if I have even modest loss over fairly short periods of time. Yes, that can increase the number of alerts you see - but if you've got a connection with that many problems, you need to address the underlying problem, not just chirp at you about it less often.<br>
<br>
3) Yes, at first glance, your pattern appears right. However, I think the *25* means *up to* 25 samples. [0-25]<br>
So, a 10% loss, followed by another 10% loss the very next sample will match a pattern of: >10%,*25*,>10% or it will also match <br>
A 10% loss, followed by another 10% loss with 1-25 samples between them with <10% loss.<br>
<br>
So your example will also trigger with 4 subsequent samples of >10% loss each [i.e. over 4 sample periods]. It would also trigger in the conditions you envision - (1) >10% loss sample, and then another > 10% loss, 25 samples later, and another 25 samples later etc... <br>
<br>
Again, I think less fancy is more likely to produce a result that's still useful and a lot less trouble to test and verify it works in the conditions you envision.<br>
<br>
HTH<br>
<br>
-Greg<br>
<br>
<br>
<span style=" color: #800000;"><b>RdH> Hi team<br>
<br>
RdH> I hope you are doing great today?<br>
<br>
RdH> what a great tool! Love to run it on my RBp2 and monitor the<br>
RdH> internet connection! I have a small question but i can’t solve it<br>
RdH> myself would you try to help me?<br>
<br>
RdH> The goal is to have an alert when the internetline is<br>
RdH> experiencing packetloss, but for a longer time not on every<br>
RdH> glitch. Im using FPingnormal with a step of 180 (means 3 minutus) <br>
<br>
RdH> The loss pattern i defined is like :<br>
RdH> 10%,*25*,>10%,*25*,>10%,*25*,>10% which means based on the how<br>
RdH> to’s provided on the website: Take 25 samples (which is 25*3<br>
RdH> minutes) so if the packetloss exists from start -> 75 minutes<br>
RdH> later still>10% -> 75 minutes later still >10% and another 75<br>
RdH> minutes later still >10% send out an email.<br>
<br>
RdH> But it send out an email almost directly, please see the<br>
RdH> screenshots where the packets loss starts and when i received the<br>
RdH> email, that timeframe is not even close to 75 minutes but more like a few minutes.<br>
<br>
RdH> Could you advise how to make the packetloss alarm more reliable<br>
RdH> where it last for at least 1 hour before sending out the email?<br>
<br>
RdH> Many thanks! Cheers Rob<br>
<br>
RdH> how the system works now (screenshots where to big)<br>
<br>
RdH> -packetloss started about 07:40 stable around 07:55 and started again 08:03<br>
RdH> -email alarm received around 08:07 after the second block of packets loss<br>
RdH> -email cleared received after 3 minutes around 08:10<br>
<br>
RdH> _______________________________________________<br>
RdH> smokeping-users mailing list<br>
</b></span></span><a style=" font-family:'courier new'; font-size: 9pt;" href="mailto:smokeping-users@lists.oetiker.ch">RdH> smokeping-users@lists.oetiker.ch</a><br>
<a style=" font-family:'courier new'; font-size: 9pt;" href="https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users">RdH> https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users</a><br>
<br>
<span style=" font-family:'arial'; font-size: 9pt; color: #c0c0c0;"><i>-- <br>
Gregory Sloop, Principal: Sloop Network & Computer Consulting<br>
Voice: 503.251.0452 x82<br>
EMail: </i></span><a style=" font-family:'arial'; font-size: 9pt;" href="mailto:gregs@sloop.net">gregs@sloop.net</a><br>
<a style=" font-family:'arial'; font-size: 9pt;" href="http://www.sloop.net/">http://www.sloop.net</a><br>
<span style=" font-family:'arial'; font-size: 9pt; color: #c0c0c0;"><i>---<br>
<span style=" font-family:'courier new'; color: #000000;">_______________________________________________<br>
smokeping-users mailing list<br>
</span></i></span><a style=" font-family:'courier new'; font-size: 9pt; font-style: Italic;" href="mailto:smokeping-users@lists.oetiker.ch">smokeping-users@lists.oetiker.ch</a><br>
<span style=" font-family:'courier new'; font-size: 9pt;"><i><a href="https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users">https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users</a></i></span></td>
</tr>
</tbody></table>
<br><br>
<span style=" font-family:'arial'; color: #c0c0c0;"><i>-- <br>
Gregory Sloop, Principal: Sloop Network & Computer Consulting<br>
Voice: 503.251.0452 x82<br>
EMail: </i></span><a style=" font-family:'arial';" href="mailto:gregs@sloop.net">gregs@sloop.net</a><br>
<a style=" font-family:'arial';" href="http://www.sloop.net">http://www.sloop.net</a><br>
<span style=" font-family:'arial'; color: #c0c0c0;"><i>---</i></span></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>smokeping-users mailing list</span><br><span><a href="mailto:smokeping-users@lists.oetiker.ch">smokeping-users@lists.oetiker.ch</a></span><br><span><a href="https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users">https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users</a></span><br></div></blockquote></body></html>