Open Stack

Hi Yinliyin,

At first I thought that changing the deduced to be a property on the alarm might help in solving your use case. But now I think most of the problems will remain the same:


  *   It won’t solve the general problem of two different monitors that raise the same alarm
  *   It won’t solve possible conflicts of timestamp and severity between different monitors
  *   It will make the decision of when to delete the alarm more complex (delete it when the deduced alarm is deleted? When Nagios alarm is deleted? both? And how to change the timestamp and severity in these cases?)

So I don’t think that making this change is beneficial.
What do you think?

Best Regards,
Ifat.


From: "yinliyin at zte.com.cn" <yinliyin at zte.com.cn>
Date: Monday, 9 January 2017 at 05:29
To: "Afek, Ifat (Nokia - IL)" <ifat.afek at nokia.com>
Cc: "openstack-dev at lists.openstack.org" <openstack-dev at lists.openstack.org>, "han.jing28 at zte.com.cn" <han.jing28 at zte.com.cn>, "wang.weiya at zte.com.cn" <wang.weiya at zte.com.cn>, "zhang.yujunz at zte.com.cn" <zhang.yujunz at zte.com.cn>, "jia.peiyuan at zte.com.cn" <jia.peiyuan at zte.com.cn>, "gong.yahui5 at zte.com.cn" <gong.yahui5 at zte.com.cn>
Subject: Re: [openstack-dev] [Vitrage] About alarms reported by datasource and the alarms generated by vitrage evaluator




Hi Ifat,

         I think there is a situation that all the alarms are reported by the monitored system. We use vitrage to:

            1.  Found the relationships of the alarms, and find the root cause.

            2.  Deduce the alarm before it really occured. This comprise two aspects:

                 1) A cause B:  When A occured,  we deduce that B would occur

                 2) B is caused by A:  When B occured, we deduce that A must occured

            In "2",   we do expect vitrage to raise the alarm before the alarm is reported because the alarm would be lost or be delayed for some reason.  So we would write "raise alarm" actions in the scenarios of the template.  I think that the alarm is reported or is deduced should be a state property of the alarm. The vertex reported and the vertex deduced of the same alarm should be merged to one vertex.



     Best Regards,

     Yinliyin.

























殷力殷 YinLiYin



项目经理   Project Manager
虚拟化上海五部/无线研究院/无线产品经营部 NIV Shanghai Dept. V/Wireless Product R＆D Institute/Wireless Product Operation


[cid:image001.gif at 01D26B5C.646157B0]

[cid:image002.gif at 01D26B5C.646157B0]
上海市浦东新区碧波路889号中兴研发大楼D502
D502, ZTE Corporation R&D Center, 889# Bibo Road,
Zhangjiang Hi-tech Park, Shanghai, P.R.China, 201203
T: +86 21 68896229
M: +86 13641895907
E: yinliyin at zte.com.cn
www.zte.com.cn<http://www.zte.com.cn/>

原始邮件
发件人： ＜ifat.afek at nokia.com＞;
收件人： ＜openstack-dev at lists.openstack.org＞;
抄送人：韩静00006838;王维雅00042110;章宇军10200531;贾培源10101785;龚亚辉6092001895;
日 期 ：2017年01月07日 02:18
主 题 ：Re: [openstack-dev] [Vitrage] About alarms reported by datasource and the alarms generated by vitrage evaluator


Hi YinLiYin,

This is an interesting question. Let me divide my answer to two parts.

First, the case that you described with Nagios and Vitrage. This problem depends on the specific Nagios tests that you configure in your system, as well as on the Vitrage templates that  you use. For example, you can use Nagios/Zabbix to monitor the physical layer, and Vitrage to raise deduced alarms on the virtual and application layers. This way you will never have duplicated alarms. If you want to use Nagios to monitor the other layers  as well, you can simply modify Vitrage templates so they don’t raise the deduced alarms that Nagios may generate, and use the templates to show RCA between different Nagios alarms.

Now let’s talk about the more general case. Vitrage can receive alarms from different monitors, including Nagios, Zabbix, collectd and Aodh. If you are using more than one monitor, it is  possible that the same alarm (maybe with a different name) will be raised twice. We need to create a mechanism to identify such cases and create a single alarm with the properties of both monitors. This has not been designed in details yet, so if you have  any suggestion we will be happy to hear them.

Best Regards,
Ifat.


From: "yinliyin at zte.com.cn" ＜yinliyin at zte.com.cn＞
Reply-To: "OpenStack Development Mailing List (not for usage questions)" ＜openstack-dev at lists.openstack.org＞
Date: Friday, 6 January 2017 at 03:27
To: "openstack-dev at lists.openstack.org" ＜openstack-dev at lists.openstack.org＞
Cc: "gong.yahui5 at zte.com.cn" ＜gong.yahui5 at zte.com.cn＞, "han.jing28 at zte.com.cn" ＜han.jing28 at zte.com.cn＞, "wang.weiya at zte.com.cn" ＜wang.weiya at zte.com.cn＞, "jia.peiyuan at zte.com.cn" ＜jia.peiyuan at zte.com.cn＞, "zhang.yujunz at zte.com.cn" ＜zhang.yujunz at zte.com.cn＞
Subject: [openstack-dev] [Vitrage] About alarms reported by datasource and the alarms generated by vitrage evaluator


Hi all,

   Vitrage generate alarms acording to the templates. All the alarms raised by vitrage has the type "vitrage". Suppose Nagios has an alarm A. Alarm A is raised by vitrage evaluator according to the action part of a scenario, type  of alarm A is "vitrage". If Nagios reported alarm A latter, a new alarm A with type "Nagios" would be generator in the entity graph.     There would be two vertices for the same alarm in the graph. And we have to define two alarm entities, two relationships,  two scenarios in the template file to make the alarm propagation procedure work.

   It is inconvenient to describe fault model of system with lot of alarms. How to solve this problem?



殷力殷 YinLiYin




[cid:image003.gif at 01D26B5C.646157B0]

[cid:image004.gif at 01D26B5C.646157B0]
上海市浦东新区碧波路889号中兴研发大楼D502
D502, ZTE Corporation R&D Center, 889# Bibo Road,
Zhangjiang Hi-tech Park, Shanghai, P.R.China, 201203
T: +86 21 68896229
M: +86 13641895907
E: yinliyin at zte.com.cn
www.zte.com.cn<http://www.zte.com.cn/>







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170110/ff3e5e9b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 6016 bytes
Desc: image001.gif
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170110/ff3e5e9b/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 2065 bytes
Desc: image002.gif
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170110/ff3e5e9b/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.gif
Type: image/gif
Size: 6017 bytes
Desc: image003.gif
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170110/ff3e5e9b/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.gif
Type: image/gif
Size: 2066 bytes
Desc: image004.gif
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170110/ff3e5e9b/attachment-0003.gif>