The priority level of this event as defined by the
vendor. These are ordered from most serious (emergency)
to least serious (debug).
Parsed from file DOCS-CABLE-DEVICE-MIB.mib
Module: DOCS-CABLE-DEVICE-MIB
The priority level of this event, as defined by the
vendor. These are ordered from most serious (emergency)
to least serious (debug).
emergency(1) events indicate vendor-specific fatal
hardware or software errors that prevent normal system
operation.
alert(2) events indicate a serious failure that causes
the reporting system to reboot but that is not caused by
hardware or software malfunctioning.
critical(3) events indicate a serious failure that
requires attention and prevents the device from
transmitting data but that could be recovered without
rebooting the system.
error(4) and warning(5) events indicate that a failure
occurred that could interrupt the normal data flow but
that does not cause the device to re-register.
notice(6) and information(7) events indicate a
milestone or checkpoint in normal operation that could
be of particular importance for troubleshooting.
debug(8) events are reserved for vendor-specific
events.
During normal operation, no event more
critical than notice(6) should be generated. Events
between warning and emergency should be generated at
appropriate levels of problems (e.g., emergency when the
box is about to crash).
docsDevEvLevel OBJECT-TYPE
SYNTAX INTEGER {
emergency(1),
alert(2),
critical(3),
error(4),
warning(5),
notice(6),
information(7),
debug(8)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The priority level of this event as defined by the
vendor. These are ordered from most serious (emergency)
to least serious (debug)."
View at oid-info.com
The priority level of this event, as defined by the
vendor. These are ordered from most serious (emergency)
to least serious (debug).
emergency(1) events indicate vendor-specific fatal
hardware or software errors that prevent normal system
operation.
alert(2) events indicate a serious failure that causes
the reporting system to reboot but that is not caused by
hardware or software malfunctioning.
critical(3) events indicate a serious failure that
requires attention and prevents the device from
transmitting data but that could be recovered without
rebooting the system.
error(4) and warning(5) events indicate that a failure
occurred that could interrupt the normal data flow but
that does not cause the device to re-register.
notice(6) and information(7) events indicate a
milestone or checkpoint in normal operation that could
be of particular importance for troubleshooting.
debug(8) events are reserved for vendor-specific
events.
During normal operation, no event more
critical than notice(6) should be generated. Events
between warning and emergency should be generated at
appropriate levels of problems (e.g., emergency when the
box is about to crash).
Parsed from file rfc4639-DOCSIS-Cable-Device.mib.txt
Company: None
Module: DOCS-CABLE-DEVICE-MIB
The priority level of this event, as defined by the
vendor. These are ordered from most serious (emergency)
to least serious (debug).
emergency(1) events indicate vendor-specific fatal
hardware or software errors that prevent normal system
operation.
alert(2) events indicate a serious failure that causes
the reporting system to reboot but that is not caused by
hardware or software malfunctioning.
critical(3) events indicate a serious failure that
requires attention and prevents the device from
transmitting data but that could be recovered without
rebooting the system.
error(4) and warning(5) events indicate that a failure
occurred that could interrupt the normal data flow but
that does not cause the device to re-register.
notice(6) and information(7) events indicate a
milestone or checkpoint in normal operation that could
be of particular importance for troubleshooting.
debug(8) events are reserved for vendor-specific
events.
During normal operation, no event more
critical than notice(6) should be generated. Events
between warning and emergency should be generated at
appropriate levels of problems (e.g., emergency when the
box is about to crash).
docsDevEvLevel OBJECT-TYPE SYNTAX INTEGER { emergency(1), alert(2), critical(3), error(4), warning(5), notice(6), information(7), debug(8) } MAX-ACCESS read-only STATUS current DESCRIPTION "The priority level of this event as defined by the vendor. These are ordered from most serious (emergency) to least serious (debug)." ::= { docsDevEventEntry 5 }
docsDevEvLevel OBJECT-TYPE SYNTAX INTEGER { emergency(1), alert(2), critical(3), error(4), warning(5), notice(6), information(7), debug(8) } ACCESS read-only STATUS mandatory DESCRIPTION "The priority level of this event, as defined by the vendor. These are ordered from most serious (emergency) to least serious (debug). emergency(1) events indicate vendor-specific fatal hardware or software errors that prevent normal system operation. alert(2) events indicate a serious failure that causes the reporting system to reboot but that is not caused by hardware or software malfunctioning. critical(3) events indicate a serious failure that requires attention and prevents the device from transmitting data but that could be recovered without rebooting the system. error(4) and warning(5) events indicate that a failure occurred that could interrupt the normal data flow but that does not cause the device to re-register. notice(6) and information(7) events indicate a milestone or checkpoint in normal operation that could be of particular importance for troubleshooting. debug(8) events are reserved for vendor-specific events. During normal operation, no event more critical than notice(6) should be generated. Events between warning and emergency should be generated at appropriate levels of problems (e.g., emergency when the box is about to crash)." ::= { docsDevEventEntry 5 }
Automatically extracted from RFC2669
docsDevEvLevel OBJECT-TYPE SYNTAX INTEGER { emergency(1), alert(2), critical(3), error(4), warning(5), notice(6), information(7), debug(8) } MAX-ACCESS read-only STATUS current DESCRIPTION "The priority level of this event, as defined by the vendor. These are ordered from most serious (emergency) to least serious (debug). emergency(1) events indicate vendor-specific fatal hardware or software errors that prevent normal system operation. alert(2) events indicate a serious failure that causes the reporting system to reboot but that is not caused by hardware or software malfunctioning. critical(3) events indicate a serious failure that requires attention and prevents the device from transmitting data but that could be recovered without rebooting the system. error(4) and warning(5) events indicate that a failure occurred that could interrupt the normal data flow but that does not cause the device to re-register. notice(6) and information(7) events indicate a milestone or checkpoint in normal operation that could be of particular importance for troubleshooting. debug(8) events are reserved for vendor-specific events. During normal operation, no event more critical than notice(6) should be generated. Events between warning and emergency should be generated at appropriate levels of problems (e.g., emergency when the box is about to crash)." ::= { docsDevEventEntry 5 }
docsDevEvLevel OBJECT-TYPE SYNTAX INTEGER { emergency(1), alert(2), critical(3), error(4), warning(5), notice(6), information(7), debug(8) } MAX-ACCESS read-only STATUS current DESCRIPTION "The priority level of this event, as defined by the vendor. These are ordered from most serious (emergency) to least serious (debug). emergency(1) events indicate vendor-specific fatal hardware or software errors that prevent normal system operation. alert(2) events indicate a serious failure that causes the reporting system to reboot but that is not caused by hardware or software malfunctioning. critical(3) events indicate a serious failure that requires attention and prevents the device from transmitting data but that could be recovered without rebooting the system. error(4) and warning(5) events indicate that a failure occurred that could interrupt the normal data flow but that does not cause the device to re-register. notice(6) and information(7) events indicate a milestone or checkpoint in normal operation that could be of particular importance for troubleshooting. debug(8) events are reserved for vendor-specific events. During normal operation, no event more critical than notice(6) should be generated. Events between warning and emergency should be generated at appropriate levels of problems (e.g., emergency when the box is about to crash)." ::= { docsDevEventEntry 5 }
Internet Assigned Numbers Authority
| OID | Name | Sub children | Sub Nodes Total | Description |
|---|---|---|---|---|
| 1.3.6.1.2.1.69.1.5.8.1.1 | docsDevEvIndex | 0 | 0 | Provides relative ordering of the objects in the event log. This object will always increase except when (a) the log is reset via… |
| 1.3.6.1.2.1.69.1.5.8.1.2 | docsDevEvFirstTime | 0 | 0 | The value of docsDevDateTime at the time this entry was created. |
| 1.3.6.1.2.1.69.1.5.8.1.3 | docsDevEvLastTime | 0 | 0 | If multiple events are reported via the same entry, the value of docsDevDateTime that the last event for this entry occurred, oth… |
| 1.3.6.1.2.1.69.1.5.8.1.4 | docsDevEvCounts | 0 | 0 | The number of consecutive event instances reported by this entry. This starts at 1 with the creation of this row and increments … |
| 1.3.6.1.2.1.69.1.5.8.1.6 | docsDevEvId | 0 | 0 | For this product, uniquely identifies the type of event that is reported by this entry. |
| 1.3.6.1.2.1.69.1.5.8.1.7 | docsDevEvText | 0 | 0 | Provides a human-readable description of the event, including all relevant context (interface numbers, etc.). |