Difference between revisions of "Ceilometer/blueprints/alarm-notification-details"
< Ceilometer | blueprints
(→Implementation) |
|||
Line 50: | Line 50: | ||
"details": { | "details": { | ||
"type": "combination", | "type": "combination", | ||
− | |||
"alarm_ids": ["0ca2845e-c142-4d4b-a346-e495553628aa"], | "alarm_ids": ["0ca2845e-c142-4d4b-a346-e495553628aa"], | ||
"state": "alarm" | "state": "alarm" | ||
} | } | ||
</nowiki></pre> | </nowiki></pre> |
Revision as of 10:14, 30 January 2014
Contents
Summary
It is useful to know why the state of the alarm changed. While this information is currently available in human-readable form, it is not available in machine-readable format.
Use Cases
- forwarding the alarm notification to a different system
- different reason representation than the current stringified one
Proposal
Current notification example:
{ "alarm_id": "0ca2845e-c142-4d4b-a346-e495553628ce", "current": "alarm", "previous": "ok", "reason": "Transition to alarm due to 1 samples outside threshold, most recent: 99.4" }
Proposed notification:
{ "alarm_id": "0ca2845e-c142-4d4b-a346-e495553628ce", "current": "alarm", "previous": "ok", "reason": "Transition to alarm due to 1 samples outside threshold, most recent: 99.4" "details": { "type": "threshold", "disposition": "outside", "count": 1, "most_recent": 99.4 } }
Implementation
The details dictionary would be set by the alarm evaluator in Evaluator._transition() and AlarmNotifier.notify() would be called with an additional argument from Evaluator._refresh(). Its contents would be different for each alarm type, e.g.
Threshold alarms:
"details": { "type": "threshold", "disposition": "outside", "count": 1, "most_recent": 99.4 }
Combination alarms:
"details": { "type": "combination", "alarm_ids": ["0ca2845e-c142-4d4b-a346-e495553628aa"], "state": "alarm" }