<div dir="ltr">Hi, Ifat<div><br></div><div>You comments is quite right. See my additional explanation inline.<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Jan 12, 2017 at 5:12 PM Afek, Ifat (Nokia - IL) <<a href="mailto:ifat.afek@nokia.com">ifat.afek@nokia.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="white" lang="EN-US" link="blue" vlink="purple" class="gmail_msg"><div class="m_8448659893550973962WordSection1 gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">
<p class="MsoNormal gmail_msg" style="margin-left:36.0pt"><u class="gmail_msg"></u> <u class="gmail_msg"></u></p>
<p class="MsoNormal gmail_msg" style="margin-left:36.0pt">One possible solution would be introducing a high level (abstract) template from users view. Then convert it to Vitrage scenario templates (or directly to graph). The
<b class="gmail_msg">more sources</b> (nagios, vitrage deduction) for an abstract alarm we get from the system, the
<b class="gmail_msg">more confidence</b> we get for a real fault. And the confidence of an alarm could be included in the scenario condition.<u class="gmail_msg"></u><u class="gmail_msg"></u></p>
<p class="MsoNormal gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></p>
</div></div></div></div></div><div bgcolor="white" lang="EN-US" link="blue" vlink="purple" class="gmail_msg"><div class="m_8448659893550973962WordSection1 gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg">[Ifat] I understand your idea, not sure yet if it helps with the use case.
<u class="gmail_msg"></u><u class="gmail_msg"></u></p>
<p class="MsoNormal gmail_msg">How would you imagine the ‘confidence’ property? As Boolean or a counter? One option is ‘deduced’ vs. ‘monitored’.</p></div></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="white" lang="EN-US" link="blue" vlink="purple" class="gmail_msg"><div class="m_8448659893550973962WordSection1 gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg">Another option is to count the number of monitors that reported it.</p></div></div></div></div></div></blockquote><div> </div><div><div>'deduced' vs 'monitored' would be good enough for most cases. Unless we have identify some real use case, I also think there is no need for bring in quantitative indicator like counter or probability.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="white" lang="EN-US" link="blue" vlink="purple" class="gmail_msg"><div class="m_8448659893550973962WordSection1 gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg">Personally, I don’t think this is needed. I think that
 if Nagios reports an error, then it is confident enough without getting it from another monitor.</p></div></div></div></div></div></blockquote><div><br></div><div>You are right. We would consider a reported alarm as a reliable indicator of fault. What I was thinking about is: when we the alarm is not seen, can we be sure there is no fault? </div><div><br></div><div>Another situation is slow upstream alarm with fast downstream alarm. I don't have an actual example for the moment, so please allow me to imagine an extreme condition.</div><div><br></div><div>Suppose host fault will cause instance fault. But due to some restriction, the host fault is scanned every 1 hour, but instance fault can be scanned every 1 second. Now, we get alarms from 10 instance in the same host. Can we deduce that the host is likely in fault status? And we may raise a "deduced" alarm on the host and trigger an immediate scan which may result in a "monitored" alarm. In this way, we reduce the time of detecting the root cause, i.e host fault.</div><div><br></div><div>An alternative solution is to distinguish fault from alarm. Alarm is actually a reflection of fault status.  Beside the directly linked alarm, fault status can also be deduced from downstream alarms. I haven't think over this model yet, it just flashed over my mind. Any comments are welcome.</div></div></div></div>