3.2.10. alarm¶
Top-level container for alarm. It mounts ietf-alarms configuration.
vsr running config# system alarm
enabled¶
Enable or disable the alarms.
vsr running config# system alarm
vsr running alarm# enabled true|false
- Default value
true
max-alarm-status-changes¶
The ‘status-change’ entries are kept in a circular list per alarm. When this number is exceeded, the oldest status change entry is automatically removed. If the value is ‘infinite’, the status-change entries are accumulated infinitely.
vsr running config# system alarm
vsr running alarm# max-alarm-status-changes MAX-ALARM-STATUS-CHANGES
|
Description |
|---|---|
|
No description. |
|
The status-change entries are accumulated infinitely. |
- Default value
32
notify-status-changes¶
This leaf controls the notifications sent for alarm status updates. There are three options: 1. Notifications are sent for all updates, severity-level changes, and alarm-text changes. 2. Notifications are only sent for alarm raise and clear. 3. Notifications are sent for status changes equal to or above the specified severity level. Clear notifications shall always be sent. Notifications shall also be sent for state changes that make an alarm less severe than the specified level. For example, in option 3, assume that the severity level is set to major and that the alarm has the following state changes: [(Time, severity, clear)]: [(T1, major, -), (T2, minor, -), (T3, warning, -), (T4, minor, -), (T5, major, -), (T6, critical, -), (T7, major. -), (T8, major, clear)] In that case, notifications will be sent at times T1, T2, T5, T6, T7, and T8.
vsr running config# system alarm
vsr running alarm# notify-status-changes NOTIFY-STATUS-CHANGES
|
Description |
|---|---|
|
Send notifications for all status changes. |
|
Send notifications only for raise, clear, and re-raise. Notifications for severity-level changes or alarm-text changes are not sent. |
|
Only send notifications for alarm-state changes crossing the level specified in ‘notify-severity-level’. Always send clear notifications. |
- Default value
all-state-changes
notify-severity-level¶
Only send notifications for alarm-state changes crossing the specified level. Always send clear notifications.
vsr running config# system alarm
vsr running alarm# notify-severity-level NOTIFY-SEVERITY-LEVEL
|
Description |
|---|---|
|
Indicates that the severity level could not be determined. This level SHOULD be avoided. |
|
The ‘warning’ severity level indicates the detection of a potential or impending service-affecting fault, before any significant effects have been felt. Action should be taken to further diagnose (if necessary) and correct the problem in order to prevent it from becoming a more serious service-affecting fault. |
|
The ‘minor’ severity level indicates the existence of a non-service-affecting fault condition and that corrective action should be taken in order to prevent a more serious (for example, service-affecting) fault. Such a severity can be reported, for example, when the detected alarm condition is not currently degrading the capacity of the resource. |
|
The ‘major’ severity level indicates that a service- affecting condition has developed and an urgent corrective action is required. Such a severity can be reported, for example, when there is a severe degradation in the capability of the resource and its full capability must be restored. |
|
The ‘critical’ severity level indicates that a service- affecting condition has occurred and an immediate corrective action is required. Such a severity can be reported, for example, when a resource becomes totally out of service and its capability must be restored. |
alarm-inventory¶
The ‘alarm-inventory/alarm-type’ list contains all possible alarm types for the system. If the system knows for which resources a specific alarm type can appear, it is also identified in the inventory. The list also tells if each alarm type has a corresponding clear state. The inventory shall only contain concrete alarm types. The alarm inventory MUST be updated by the system when new alarms can appear. This can be the case when installing new software modules or inserting new card types. A notification ‘alarm-inventory-changed’ is sent when the inventory is changed.
vsr running config# system alarm alarm-inventory
alarm-type¶
An entry in this list defines a possible alarm.
vsr running config# system alarm alarm-inventory alarm-type <alarm-type-id> <alarm-type-qualifier>
|
Identifies an alarm type. The description of the alarm type id MUST indicate whether or not the alarm type is abstract. An abstract alarm type is used as a base for other alarm type ids and will not be used as a value for an alarm or be present in the alarm inventory. |
|
If an alarm type cannot be fully specified at design time by ‘alarm-type-id’, this string qualifier is used in addition to fully define a unique alarm type. The definition of alarm qualifiers is considered to be part of the instrumentation and is out of scope for this module. An empty string is used when this is part of a key. |
resource¶
Optionally, specifies for which resources the alarm type is valid.
vsr running config# system alarm alarm-inventory alarm-type <alarm-type-id> <alarm-type-qualifier>
vsr running alarm-type <alarm-type-id> <alarm-type-qualifier># resource RESOURCE
|
Description |
|---|---|
|
This type represents an XPATH 1.0 expression. When a schema node is defined that uses this type, the description of the schema node MUST specify the XPath context in which the XPath expression is evaluated. |
|
The object-identifier type represents administratively assigned names in a registration-hierarchical-name tree. Values of this type are denoted as a sequence of numerical non-negative sub-identifier values. Each sub-identifier value MUST NOT exceed 2^32-1 (4294967295). Sub-identifiers are separated by single dots and without any intermediate whitespace. The ASN.1 standard restricts the value space of the first sub-identifier to 0, 1, or 2. Furthermore, the value space of the second sub-identifier is restricted to the range 0 to 39 if the first sub-identifier is 0 or 1. Finally, the ASN.1 standard requires that an object identifier has always at least two sub-identifiers. The pattern captures these restrictions. Although the number of sub-identifiers is not limited, module designers should realize that there may be implementations that stick with the SMIv2 limit of 128 sub-identifiers. This type is a superset of the SMIv2 OBJECT IDENTIFIER type since it is not restricted to 128 sub-identifiers. Hence, this type SHOULD NOT be used to represent the SMIv2 OBJECT IDENTIFIER type; the object-identifier-128 type SHOULD be used instead. |
|
This type is used to match resources of type ‘resource’. Since the type ‘resource’ is a union of different types, the ‘resource-match’ type is also a union of corresponding types. If the type is given as an XPath 1.0 expression, a resource of type ‘instance-identifier’ matches if the instance is part of the node set that is the result of evaluating the XPath 1.0 expression. For example, the XPath 1.0 expression: /ietf-interfaces:interfaces/ietf-interfaces:interface [ietf-interfaces:type=’ianaift:ethernetCsmacd’] would match the resource instance-identifier: /if:interfaces/if:interface[if:name=’eth1’], assuming that the interface ‘eth1’ is of type ‘ianaift:ethernetCsmacd’. If the type is given as an object identifier, a resource of type ‘object-identifier’ matches if the match object identifier is a prefix of the resource’s object identifier. For example, the value: 1.3.6.1.2.1.2.2 would match the resource object identifier: 1.3.6.1.2.1.2.2.1.1.5 If the type is given as an UUID or a string, it is interpreted as an XML Schema regular expression, which matches a resource of type ‘yang:uuid’ or ‘string’ if the given regular expression matches the resource string. If the type is given as an XPath expression, it is evaluated in the following XPath context: o The set of namespace declarations is the set of prefix and namespace pairs for all YANG modules implemented by the server, where the prefix is the YANG module name and the namespace is as defined by the ‘namespace’ statement in the YANG module. If a leaf of this type is encoded in XML, all namespace declarations in scope on the leaf element are added to the set of namespace declarations. If a prefix found in the XML is already present in the set of namespace declarations, the namespace in the XML is used. o The set of variable bindings is empty. o The function library is the core function library, and the functions are defined in Section 10 of RFC 7950. o The context node is the root node in the data tree. |
description (mandatory)¶
A description of the possible alarm. It SHOULD include information on possible underlying root causes and corrective actions.
vsr running config# system alarm alarm-inventory alarm-type <alarm-type-id> <alarm-type-qualifier>
vsr running alarm-type <alarm-type-id> <alarm-type-qualifier># description <string>
will-clear (state only)¶
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.
vsr> show state system alarm alarm-inventory alarm-type <alarm-type-id> <alarm-type-qualifier> will-clear
severity-level (state only)¶
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.
vsr> show state system alarm alarm-inventory alarm-type <alarm-type-id> <alarm-type-qualifier> severity-level
severity-level-trigger¶
An entry in this list defines a possible severity level.
vsr running config# system alarm alarm-inventory alarm-type <alarm-type-id> <alarm-type-qualifier> severity-level-trigger <severity-level-trigger>
|
Description |
|---|---|
|
The alarm is cleared by the instrumentation. |
|
Indicates that the severity level could not be determined. This level SHOULD be avoided. |
|
The ‘warning’ severity level indicates the detection of a potential or impending service-affecting fault, before any significant effects have been felt. Action should be taken to further diagnose (if necessary) and correct the problem in order to prevent it from becoming a more serious service-affecting fault. |
|
The ‘minor’ severity level indicates the existence of a non-service-affecting fault condition and that corrective action should be taken in order to prevent a more serious (for example, service-affecting) fault. Such a severity can be reported, for example, when the detected alarm condition is not currently degrading the capacity of the resource. |
|
The ‘major’ severity level indicates that a service- affecting condition has developed and an urgent corrective action is required. Such a severity can be reported, for example, when there is a severe degradation in the capability of the resource and its full capability must be restored. |
|
The ‘critical’ severity level indicates that a service- affecting condition has occurred and an immediate corrective action is required. Such a severity can be reported, for example, when a resource becomes totally out of service and its capability must be restored. |
text (mandatory)¶
A user-friendly text describing the alarm-state change. Some variables are available in the text {name} {description} {severity} {value}.
vsr running config# system alarm alarm-inventory alarm-type <alarm-type-id> <alarm-type-qualifier> severity-level-trigger <severity-level-trigger>
vsr running severity-level-trigger <severity-level-trigger># text <string>
above¶
The alarm will be triggered if the value is above.
vsr running config# system alarm alarm-inventory alarm-type <alarm-type-id> <alarm-type-qualifier> severity-level-trigger <severity-level-trigger>
vsr running severity-level-trigger <severity-level-trigger># above <int64>
below¶
The alarm will be triggered if the value is below.
vsr running config# system alarm alarm-inventory alarm-type <alarm-type-id> <alarm-type-qualifier> severity-level-trigger <severity-level-trigger>
vsr running severity-level-trigger <severity-level-trigger># below <int64>
equal¶
The alarm will be triggered if the value is equal.
vsr running config# system alarm alarm-inventory alarm-type <alarm-type-id> <alarm-type-qualifier> severity-level-trigger <severity-level-trigger>
vsr running severity-level-trigger <severity-level-trigger># equal EQUAL
|
Description |
|---|---|
|
No description. |
|
No description. |
|
No description. |
different¶
The alarm will be triggered if the value is different.
vsr running config# system alarm alarm-inventory alarm-type <alarm-type-id> <alarm-type-qualifier> severity-level-trigger <severity-level-trigger>
vsr running severity-level-trigger <severity-level-trigger># different DIFFERENT
|
Description |
|---|---|
|
No description. |
|
No description. |
|
No description. |
between¶
The alarm will be triggered if the value is between start and end.
vsr running config# system alarm alarm-inventory alarm-type <alarm-type-id> <alarm-type-qualifier> severity-level-trigger <severity-level-trigger> between
start¶
Set the start value.
vsr running config# system alarm alarm-inventory alarm-type <alarm-type-id> <alarm-type-qualifier> severity-level-trigger <severity-level-trigger> between
vsr running between# start <int64>
end¶
Set the end value.
vsr running config# system alarm alarm-inventory alarm-type <alarm-type-id> <alarm-type-qualifier> severity-level-trigger <severity-level-trigger> between
vsr running between# end <int64>
alarm-list (state only)¶
The alarms in the system.
number-of-alarms (state only)¶
This object shows the total number of alarms in the system, i.e., the total number of entries in the alarm list.
vsr> show state system alarm alarm-list number-of-alarms
last-changed (state only)¶
A timestamp when the alarm list was last changed. The value can be used by a manager to initiate an alarm resynchronization procedure.
vsr> show state system alarm alarm-list last-changed
alarm (state only)¶
The list of alarms. Each entry in the list holds one alarm for a given alarm type and resource. An alarm can be updated from the underlying resource or by the user. The following leafs are maintained by the resource: ‘is-cleared’, ‘last-change’, ‘perceived-severity’, and ‘alarm-text’. An operator can change ‘operator-state’ and ‘operator-text’. Entries appear in the alarm list the first time an alarm becomes active for a given alarm type and resource. Entries do not get deleted when the alarm is cleared. Clear status is represented as a boolean flag. Alarm entries are removed, i.e., purged, from the list by an explicit purge action. For example, purge all alarms that are cleared and in closed operator state that are older than 24 hours. Purged alarms are removed from the alarm list. If the alarm resource state changes after a purge, the alarm will reappear in the alarm list. Systems may also remove alarms based on locally configured policies; this is out of scope for this module.
alt-resource (state only)¶
Used if the alarming resource is available over other interfaces. This field can contain SNMP OIDs, CIM paths, or 3GPP distinguished names, for example.
vsr> show state system alarm alarm-list alarm <resource> <alarm-type-id> <alarm-type-qualifier> alt-resource
time-created (state only)¶
The timestamp when this alarm entry was created. This represents the first time the alarm appeared; it can also represent that the alarm reappeared after a purge. Further state changes of the same alarm do not change this leaf; these changes will update the ‘last-changed’ leaf.
vsr> show state system alarm alarm-list alarm <resource> <alarm-type-id> <alarm-type-qualifier> time-created
is-cleared (state only)¶
Indicates the current clearance state of the alarm. An alarm might toggle from active alarm to cleared alarm and back to active again.
vsr> show state system alarm alarm-list alarm <resource> <alarm-type-id> <alarm-type-qualifier> is-cleared
last-raised (state only)¶
An alarm may change severity level and toggle between active and cleared during its lifetime. This leaf indicates the last time it was raised (‘is-cleared’ = ‘false’).
vsr> show state system alarm alarm-list alarm <resource> <alarm-type-id> <alarm-type-qualifier> last-raised
last-changed (state only)¶
A timestamp when the ‘status-change’ or ‘operator-state-change’ list was last changed.
vsr> show state system alarm alarm-list alarm <resource> <alarm-type-id> <alarm-type-qualifier> last-changed
perceived-severity (state only)¶
The last severity of the alarm. If an alarm was raised with severity ‘warning’ but later changed to ‘major’, this leaf will show ‘major’.
vsr> show state system alarm alarm-list alarm <resource> <alarm-type-id> <alarm-type-qualifier> perceived-severity
alarm-text (state only)¶
The last reported alarm text. This text should contain information for an operator to be able to understand the problem and how to resolve it.
vsr> show state system alarm alarm-list alarm <resource> <alarm-type-id> <alarm-type-qualifier> alarm-text