Re: [openstack-dev] [Horizon] Ceilometer Alarm management page
Hello, thank you very much for the feedback. Ok, I have tried to go through the triggers an events. Let me summarize, so we can confirm I understand it correctly: == The trigger: -- - has a pattern - that is something like starting condition, that leads to creating a trigger - has a criteria - that is the condition, that has to be fulfilled in some given timeout after the trigger is created: --- then it can run some action(triggered notification pipeline) and it saves the trigger(so it has query-able history of the triggers) --- or the timeout action ( optional expiration notification pipeline). Questions - 1. In the example in https://blueprints.launchpad.net/ceilometer/+spec/notifications-triggers the pattern and criteria are a condition that are checking appearance of specific events. What are the options for the conditions? What is the querying API? 2. Can the conditions be tied only to the events? Or also to samples and statistics, so I can build similar queries and conditions, that alarms have? 3. If I have set e.g. trigger for measuring health of my baremetals(checking disk failures), I could just set both conditions(pattern, criteria) the same, to observing some events marking disk failure, right? If there will be disk Failures, it would create a trigger for each disk failure notification, right? So I could then browse the triggers to check which resources had a disk failures? What are the querying options over the triggers? E.g. I would like to get number of triggers of some type on some resource_ids, from last month, grouped by project? Summary == If the trigger pattern and criteria supports a general condition like Alarms do, I believe this could work, yes. Otherwise it seems we should use Alarms(and Alarms Groups) for checking sample based alerts, and Triggers for checking events(notifications) based alerts. So e.g. the health of hardware would be likely computed from combination of Alarms and Triggers. On 09/24/2013 03:48 PM, Thomas Maddox wrote: I think Dragon's BP for notification triggers would solve this problem. Instead of looking at it as applying a single alarm to several resources, you could instead leverage the similarities of the resources: https://blueprints.launchpad.net/ceilometer/+spec/notifications-triggers. Compound that with configurable events: https://blueprints.launchpad.net/ceilometer/+spec/configurable-event-defini tions -Thomas On 9/24/13 7:46 AM, Julien Danjou jul...@danjou.info wrote: On Tue, Sep 24 2013, Ladislav Smola wrote: Yes it would be good if something like this would be supported. - relation of alarm to multiple entities, that are result of sample-api query. Could it be worth creating a BP? Probably indeed. -- Julien Danjou # Free Software hacker # independent consultant # http://julien.danjou.info ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Ceilometer Alarm management page
On 09/25/2013 01:51 AM, Gabriel Hurley wrote 4. There is a thought about tagging the alarms by user defined tag, so user can easily group alarms together and then watch them together based on their tag. The alarm API don't provide that directly, but you can imagine some sort of filter based on description matching some texts. I'd love to see this as an extension to the alarm API. I think tracking metadata about alarms (e.g. tags or arbitrary key-value pairs) would be tremendously useful. yes, that sound like a very good idea. 5. There is a thought about generating a default alarms, that could observe the most important things (verifying good behaviour, showing bad behaviour). Does anybody have an idea which alarms could be the most important and usable for everybody? I'm not sure you want to create alarm by default; alarm are resources, I don't think we should create resources without the user asking for it. Seconded. Continues as Alarms Groups or Triggers conversation in this thread. Maybe you were talking about generating alarm template? You could start with things like CPU usage staying at 90% for more than 1 hour, and having an action that alerts the user via mail. Same for disk usage. We do this kind of template for common user tasks with security group rules already. The same concept applies to alarms. Ok, will check this out. Thank you for the feedback, Ladislav ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Ceilometer Alarm management page
On Tue, Sep 24 2013, Ladislav Smola wrote: Well for example, if we find metrics, that can be used for measuring health (this is probably more undercloud talking, or hardware metrics in general), we could do something like I want this alarm on all resources of this type, if there will be e.g. 100s of the resources of the same type, it would be pretty dull to connect alarm to each of them, or to decide to change them. Agreed, but I don't know/think that Ceilometer has such capabilities right now. -- Julien Danjou // Free Software hacker / independent consultant // http://julien.danjou.info signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Ceilometer Alarm management page
On Tue, Sep 24 2013, Ladislav Smola wrote: Yes it would be good if something like this would be supported. - relation of alarm to multiple entities, that are result of sample-api query. Could it be worth creating a BP? Probably indeed. -- Julien Danjou # Free Software hacker # independent consultant # http://julien.danjou.info signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Ceilometer Alarm management page
I think Dragon's BP for notification triggers would solve this problem. Instead of looking at it as applying a single alarm to several resources, you could instead leverage the similarities of the resources: https://blueprints.launchpad.net/ceilometer/+spec/notifications-triggers. Compound that with configurable events: https://blueprints.launchpad.net/ceilometer/+spec/configurable-event-defini tions -Thomas On 9/24/13 7:46 AM, Julien Danjou jul...@danjou.info wrote: On Tue, Sep 24 2013, Ladislav Smola wrote: Yes it would be good if something like this would be supported. - relation of alarm to multiple entities, that are result of sample-api query. Could it be worth creating a BP? Probably indeed. -- Julien Danjou # Free Software hacker # independent consultant # http://julien.danjou.info ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Ceilometer Alarm management page
3. There is a thought about watching correlation of multiple alarm histories in one Chart (either Alarm Histories, or the real statistics the Alarm is defined by). Do you think it will be needed? Any real life examples you have in mind? I think the first use case is to debug combined alarms. There's also a lot of potential to debug an entire platform activity by superimposing several alarm graphs. Yep, this is where it gets useful for admins. For a regular user a basic set of alarms is fine, you just want to react to certain conditions in your app/workload/whatever. But for an admin if you can correlate alarms to hosts and metrics and cross-project resource creation/deletion/etc. and start to understand the cloud as a whole. I think this is an end-game use case that's very valuable, and which many companies have built their entire businesses around (which is to say it's not an easy problem or a small problem, but the need is very real). 4. There is a thought about tagging the alarms by user defined tag, so user can easily group alarms together and then watch them together based on their tag. The alarm API don't provide that directly, but you can imagine some sort of filter based on description matching some texts. I'd love to see this as an extension to the alarm API. I think tracking metadata about alarms (e.g. tags or arbitrary key-value pairs) would be tremendously useful. 5. There is a thought about generating a default alarms, that could observe the most important things (verifying good behaviour, showing bad behaviour). Does anybody have an idea which alarms could be the most important and usable for everybody? I'm not sure you want to create alarm by default; alarm are resources, I don't think we should create resources without the user asking for it. Seconded. Maybe you were talking about generating alarm template? You could start with things like CPU usage staying at 90% for more than 1 hour, and having an action that alerts the user via mail. Same for disk usage. We do this kind of template for common user tasks with security group rules already. The same concept applies to alarms. 6. There is a thought about making overview pages customizable by the users, so they can really observe, what they need. (includes Ceilometer statistics and alarms) I think that could be as easy as picking the alarms you want in overviews with a very small and narrowed graph. Conceptually easy pickings, non-trivial work. But agreed. All the best, - Gabriel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Ceilometer Alarm management page
On Thu, Sep 19 2013, Ladislav Smola wrote: Hi Ladislav, Sorry for the late reply, 1. The points 1-4 from are some sort simple version of the page, that uses all basic alarm-api features. Do you think we need them all? Any feedback for them? Enhancements? That looks like a really good start if we can have all of this! 2. There is a thought, that we should maybe divide Alarms into (System, User-defined). The only system alarms now, are set up with Heat and used for auto-scaling. I don't think there is any formal way to distinguish alarms. Though it's likely you can retrieve the alarm list Heat created for the user to distinguish them. On the other hand, I am not sure the user can see the alarms created by Heat since they might not directly belong to the user, but to Heat. 3. There is a thought about watching correlation of multiple alarm histories in one Chart (either Alarm Histories, or the real statistics the Alarm is defined by). Do you think it will be needed? Any real life examples you have in mind? I think the first use case is to debug combined alarms. There's also a lot of potential to debug an entire platform activity by superimposing several alarm graphs. 4. There is a thought about tagging the alarms by user defined tag, so user can easily group alarms together and then watch them together based on their tag. The alarm API don't provide that directly, but you can imagine some sort of filter based on description matching some texts. 5. There is a thought about generating a default alarms, that could observe the most important things (verifying good behaviour, showing bad behaviour). Does anybody have an idea which alarms could be the most important and usable for everybody? I'm not sure you want to create alarm by default; alarm are resources, I don't think we should create resources without the user asking for it. Maybe you were talking about generating alarm template? You could start with things like CPU usage staying at 90% for more than 1 hour, and having an action that alerts the user via mail. Same for disk usage. 6. There is a thought about making overview pages customizable by the users, so they can really observe, what they need. (includes Ceilometer statistics and alarms) I think that could be as easy as picking the alarms you want in overviews with a very small and narrowed graph. -- Julien Danjou /* Free Software hacker * independent consultant http://julien.danjou.info */ signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
