Ceilometer/blueprints/alarm-notification-details

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"
  "reason_data": {
    "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:

  "reason_data": {
    "type": "threshold",
    "disposition": "outside",
    "count": 1,
    "most_recent": 99.4
  }

Combination alarms:

  "reason_data": {
    "type": "combination",
    "alarm_ids": ["0ca2845e-c142-4d4b-a346-e495553628aa"]
  }