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
