Alarm-type (List)#
Path: /alarms/alarm-inventory/alarm-type
An entry in this list defines a possible alarm.
Parameters#
| Name | Type | Required | Default | Description |
|---|---|---|---|---|
| alarm-type-id | alarm-type-id | required | The statically defined alarm type identifier for this possible alarm. | |
| alarm-type-qualifier | alarm-type-qualifier | required | The optionally dynamically defined alarm type identifier for this possible alarm. | |
| resource | multi-value, resource-match | optional | Optionally, specifies for which resources the alarm type is valid. | |
| will-clear | boolean | required | This leaf tells the operator if the alarm will be cleared when the correct corrective action has been taken. Implementations SHOULD strive for detecting the cleared state for all alarm types. If this leaf is ‘true’, the operator can monitor the alarm until it becomes cleared after the corrective action has been taken. If this leaf is ‘false’, the operator needs to validate that the alarm is no longer active using other mechanisms. Alarms can lack a corresponding clear due to missing instrumentation or no logical corresponding clear state. | |
| severity-level | multi-value, severity | optional | This leaf-list indicates the possible severity levels of this alarm type. Note well that ‘clear’ is not part of the severity type. In general, the severity level should be defined by the instrumentation based on the dynamic state, rather than being defined statically by the alarm type, in order to provide a relevant severity level based on dynamic state and context. However, most alarm types have a defined set of possible severity levels, and this should be provided here. | |
| description | string | required | A description of the possible alarm. It SHOULD include information on possible underlying root causes and corrective actions. |