Stone 037c99f0b7 Fault Management doc

Added Data Networks toctree

Changed case on doc title in top level index - changed doc directory to
fault-mgmt.

Added Distributed Cloud section.

Broke out "OpenStack Fault Management Overview" statement about remote log
collection to conditionally included file.

Incorporated patch 6 review comments. Also implemented rST :abbr:
for first instance of SNMP in each file.

Changed port number and community string in two SNMP walk examples.

Change-Id: I1afd71265e752c4c9a54bf2dc9a173b3e17332a7
Signed-off-by: Stone <ronald.stone@windriver.com>

2020-11-27 14:13:00 -05:00

1.5 KiB

Raw Blame History

Traps

supports SNMP (Simple Network Management Protocol) traps. Traps send unsolicited information to monitoring software when significant events occur.

The following traps are defined.

wrsAlarmCritical
wrsAlarmMajor
wrsAlarmMinor
wrsAlarmWarning
wrsAlarmMessage
wrsAlarmClear
wrsAlarmHierarchicalClear

Note

Customer Logs always result in wrsAlarmMessage traps. uses Wind River Systems (wrs) Enterprise Registration and Alarm MIBs. See SNMP Overview <snmp-overview> for details.

For Critical, Major, Minor, Warning, and Message traps, all variables in the active alarm table are included as varbinds (variable bindings), where each varbind is a pair of fields consisting of an object identifier and a value for the object.

For the Clear trap, varbinds include only the following variables:

<AlarmID>
<EntityInstanceID>
<DateAndTime>
<ReasonText>

For the HierarchicalClear trap, varbinds include only the following variables:

<EntityInstanceID>
<DateAndTime>
<ReasonText>

For all alarms, the Notification Type is based on the severity of the trap or alarm. This is done to facilitate the interaction with most SNMP trap viewers which typically use the Notification Type to drive the coloring of traps, that is, red for critical, yellow for minor, and so on.

1.5 KiB Raw Blame History

Traps

1.5 KiB

Raw Blame History