<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 5, 2016 at 7:03 AM, Ken Gaillot <span dir="ltr"><<a href="mailto:kgaillot@redhat.com" target="_blank">kgaillot@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 10/02/2016 10:02 PM, Andrew Beekhof wrote:<br>
>> Take a<br>
>> look at all of nagios' options for deciding when a failure becomes "real".<br>
><br>
> I used to take a very hard line on this: if you don't want the cluster<br>
> to do anything about an error, don't tell us about it.<br>
> However I'm slowly changing my position... the reality is that many<br>
> people do want a heads up in advance and we have been forcing that<br>
> policy (when does an error become real) into the agents where one size<br>
> must fit all.<br>
><br>
> So I'm now generally in favour of having the PE handle this "somehow".<br>
<br>
</span>Nagios is a useful comparison:<br>
<br>
check_interval - like pacemaker's monitor interval<br>
<br>
retry_interval - if a check returns failure, switch to this interval<br>
(i.e. check more frequently when trying to decide whether it's a "hard"<br>
failure)<br>
<br>
max_check_attempts - if a check fails this many times in a row, it's a<br>
hard failure. Before this is reached, it's considered a soft failure.<br>
Nagios will call event handlers (comparable to pacemaker's alert agents)<br>
for both soft and hard failures (distinguishing the two). A service is<br>
also considered to have a "hard failure" if its host goes down.<br>
<br>
high_flap_threshold/low_flap_<wbr>threshold - a service is considered to be<br>
flapping when its percent of state changes (ok <-> not ok) in the last<br>
21 checks (= max. 20 state changes) reaches high_flap_threshold, and<br>
stable again once the percentage drops to low_flap_threshold. To put it<br>
another way, a service that passes every monitor is 0% flapping, and a<br>
service that fails every other monitor is 100% flapping. With these,<br>
even if a service never reaches max_check_attempts failures in a row, an<br>
alert can be sent if it's repeatedly failing and recovering.<br></blockquote><div><br></div><div>makes sense.</div><div><br></div><div>since we're overhauling this functionality anyway, do you think we need to add an equivalent of retry_interval too?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
>> If you clear failures after a success, you can't detect/recover a<br>
>> resource that is flapping.<br>
><br>
> Ah, but you can if the thing you're clearing only applies to other<br>
> failures of the same action.<br>
> A completed start doesn't clear a previously failed monitor.<br>
<br>
</span>Nope -- a monitor can alternately succeed and fail repeatedly, and that<br>
indicates a problem, but wouldn't trip an "N-failures-in-a-row" system.<br>
<span class="gmail-"><br>
>> It only makes sense to escalate from ignore -> restart -> hard, so maybe<br>
>> something like:<br>
>><br>
>>   op monitor ignore-fail=3 soft-fail=2 on-hard-fail=ban<br>
>><br>
</span><span class="gmail-">> I would favour something more concrete than 'soft' and 'hard' here.<br>
> Do they have a sufficiently obvious meaning outside of us developers?<br>
><br>
> Perhaps (with or without a "failures-" prefix) :<br>
><br>
>    ignore-count<br>
>    recover-count<br>
>    escalation-policy<br>
<br>
</span>I think the "soft" vs "hard" terminology is somewhat familiar to<br>
sysadmins -- there's at least nagios, email (SPF failures and bounces),<br>
and ECC RAM. But throwing "ignore" into the mix does confuse things.<br>
<br>
How about ... max-fail-ignore=3 max-fail-restart=2 fail-escalation=ban<br>
<br>
</blockquote></div><br></div><div class="gmail_extra">I could live with that :-)</div></div>