Open Stack

Hi folks,

 

I wonder if anyone could share some best practice regarding to the usage of
ceilometer alarm. We are using the alarm evaluation/notification of
ceilometer and we don't feel very well of the way we use it. Below is our
problem:

 

============================

Scenario:

When cpu usage or memory usage above a certain threshold, alerts should be
displayed on admin's web page. There should be a 3 level alerts according to
meter value, namely notice, warning, fatal. Notice means the meter value is
between 50% ~ 70%, warning means between 70% ~ 85% and fatal means above 85%

For example:

* when one vm's cpu usage is 72%, an alert message should be displayed
saying "Warning: vm[d9b7018b-06c4-4fba-8221-37f67f6c6b8c] cpu usage is above
70%".

* when one vm's memory usage is 90%, another alert message should be created
saying "Fatal: vm[d9b7018b-06c4-4fba-8221-37f67f6c6b8c] memory usage is
above 85%"

 

Our current Solution:

We used ceilometer alarm evaluation/notification to implement this. To
distinguish which VM and which meter is above what value, we've created one
alarm for each VM by each condition. So, to monitor 1 VM, 6 alarms will be
created because there are 2 meters and for each meter there are 3 levels.
That means, if there are 100 VMs to be monitored, 600 alarms will be
created.

 

Problems:

* The first problem is, when the number of meters increases, the number of
alarms will be multiplied. For example, customer may want alerts on disk and
network IO rates, and if we do that, there will be 4*3=12 alarms for each
VM. 

* The second problem is, when one VM is created, multiple alarms will be
created, meaning multiple http requests will be fired. In the case above, 6
HTTP requests will be needed once a VM is created. And this number also
increases as the number of meters goes up.

=============================

 

Do anyone have any suggestions?

 

 

 

Best Regards!

Kurt Rao

  _____  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20141203/cd81abdd/attachment.html>