Fields displayed for a message

In this documentation, the following fields are displayed for each message:

Event identifier
A hexadecimal identifier that uniquely identifies an event or class of events. In this documentation, the event identifiers are prefixed with 0x and followed by eight characters. In Chapter 2, the events are ordered by event identifier.

Event identifiers can be seen in the event log and in notifications (e-mails and SNMP alerts).

Note: In SNMP alerts, the event identifier is displayed as a decimal number. You will need to convert that integer into a hexadecimal number to map it to the event displayed in Messages.
Event description
The logged message string that appears for an event.

In many cases, the logged message string that appears in this document is slightly different from the event string that appears in the event log.

When the event string is displayed in the event log, information such as the user ID, or the specific blade server bay number, is displayed. In this document, that additional information appears as follows:
  • %d – this is replaced by a number (typically for bay number for a blade server or an I/O module)
  • %s – this is replaced by a string (typically a user ID)
  • %% - this is replaced by the percent sign (%)

For example, consider the event 0x06000201:

0x06000201 Management Module in bay %d is primary.

In the event log, the %d is replaced with the management module bay number:

0x06000201 Management Module in bay 1 is primary.

The logged message string might have additional information added to the beginning or end of the message. Consider the event 0x806F0229:

                           0x806F0229 absent

In the event log, the logged message string is replaced with additional information:

0x806F0229 Battery 1 (Battery Status) absent.

Provides additional information to assist the user in understanding the reason why the event occurred.
The severity is an indication of the level of concern for condition. The severity is abbreviated in the event log to the first character. The following severities can be displayed:
Table 1. Severity levels
Severity Description
Informational An informational message is something that was recorded for audit purposes, usually a user action or a change of states that are normal behavior.
Warning A warning is not as severe as an error, but if possible, the condition should be corrected before it becomes an error. It may also be a condition that requires additional monitoring or maintenance.
Error An error typically indicates a failure or critical condition that impairs service or an expected function.
Note: In the Alert Category field, events with a severity of Error are shown as a severity of Critical.
Alert Category
Similar events are grouped together in categories. Information in the alert category field is displayed in the following format:

component (severity) – trap_category

Events are grouped into the following component categories:
Note: These categories are based on the enhanced alert categories.
  • Blades
  • Chassis/System Management
  • Cooling Devices
  • I/O Modules
  • Inventory
  • Network change
  • Power Modules
  • Power On/Off
In addition, the following categories are available:
  • Event log. Events related to the event log. For example, if the field Monitor log state events is enabled on the Event log page of the advanced management module Web interface, events related to the log being 75% full and the log being 100% full are listed for this category.
  • User activity. Audit related events, such as when a user logs in to the advanced management module Web interface.
Events are also grouped into the following severity levels:
  • Informational
  • Warning
  • Critical
    Note: The severity Critical for the Alert Category field is the same as the severity Error in the Severity field.

Even though these severities are not used on the BladeCenter® T and BladeCenter HT for alerts, they are used for those chassis to create alert categories.

The trap category found in the SNMP alert management information base (MIB).
SNMP users will be notified of the alerts in the event categories via an SNMP trap. The traps are defined in mmalert.mib, which is distributed with the advanced management module firmware. The following table shows the MIB Object and the Object Identifier (OID) for the selected alert category:
Enhanced Alert Categories MIB Object OID
Chassis/System Management (Critical) mmTrapChassisC .
Cooling Devices (Critical) mmTrapFanC .
Power Modules (Critical) mmTrapPsC .
Blades (Critical) mmTrapBladeC .
I/O Modules (Critical) mmTrapIOC .
Storage Modules (Critical) mmTrapStorageC .
Chassis/System Management (Warning) mmTrapChassisN .
Cooling Devices (Warning) mmTrapFanN .
Power Modules (Warning) mmTrapPowerN .
Blades (Warning) mmTrapBladeN .
I/O Modules (Warning) mmTrapION .
Storage Modules (Warning) mmTrapStorageN .
Event Log (Warning) mmTrapLogFullN .
Chassis/System Management (Informational) mmTrapChassisS .
Cooling Devices (Informational) mmTrapFanS .
Power Modules (Informational) mmTrapPowerS .
Blades (Informational) mmTrapBladeS .
I/O Modules (Informational) mmTrapIOS .
Storage Modules (Informational) mmTrapStorageS .
Event Log (Informational) mmTrapSysLogS .
Power On/Off (Informational) mmTrapPwrDOS .
Inventory change (Informational) mmTrapSysInvS .
Network change (Informational)) mmTrapNwChangeS .
User activity (Informational) mmTrapRemoteLoginS .
Test Message mmTrapAppS .

Along with the support for the new categories, the existing (legacy) categories are still available. New SNMP users should use the enhanced categories.

Every SNMP trap has the same set of variables for each trap. These parameters might be extended in the future by adding additional objects to the bottom (end) of the existing data.

For more information about specifying monitored alerts, see the Advanced Management Module User's Guide.

Log source
Use the log source as an aid in determining which component has reported an event. The log source field shows one of the following sources:
  • Audit. A user action log.
  • Blade_number. The blade server indicated by the bay number.
  • Cool_number. A fan or blower, depending on chassis type, indicted by bay number.
  • IOMod_number. An I/O module indicated by the bay number.
  • Stor_number. A storage module indicated by the bay number.
  • Power_number . A power module indicated by the bay number.
  • SERVPROC. The service processor for the advanced management module.
Automatically notify service
If this field is set to “Yes,” and you have enabled Service Advisor, your authorized service and support provider will be automatically notified if the event is generated. If IBM® is the service provider, IBM will contact you. In addition, AutoFTP will send the service data related to this event to the specified FTP server, if AutoFTP is configured.
Note: Service Advisor must be configured to run for the call-home function to work.

While waiting for IBM to call, you can perform the recommended actions for the event.

If this field is a “Yes,” it indicates that the advanced management module can generate a message that shows the condition has recovered. This does not mean that the event is a recovery of the condition.

If the message is a recovery message, the advanced management module will typically prefix the message with the word “Recovery”. An example of a recoverable message is an over- temperature threshold event. A component alerts the advanced management module for an over-temperature condition and then recovers when the condition no longer exists.

If this field is a “No” then there is no possible recovery reported by the advanced management module. These are typically informational message such as a user has logged in, or a component was installed.

For standard blade server messages that are informational and can be recovered, a customize message will be displayed. For example, consider the following message:

0x806F000F E FW/BIOS, firmware progress (ABR Sensor) error

The recovery event will be displayed if the blade server recovers from the event

0x806F000F I Recovery FW/BIOS, firmware progress (ABR Sensor) error

For some events, the event identifier and event description provide an exact message that is displayed. In other cases, the event description listed in Messages is a partial description; the actual description provides additional information. In those cases, an example of an actual event is provided in this section.
Chassis LED
The front panel of a chassis provides LED indicators for faults, temperatures, information and location (Blue). Some events will cause an LED to illuminate. Other events, such as events from a blade server, are indicated through the chassis as well as through Light Path on the blade server. For example, if a blade server indicates an error LED is lit, the chassis error LED should also be lit. Where appropriate, this field displays the chassis LEDs that are lit for an event.

For more information about LEDs and light path, see Light path diagnostic LEDs.

Alarm Panel LED (BC T and BC HT)
The alarm panel on the BladeCenter T and BladeCenter HT chassis can indicate a Critical, Major, Minor or informational LED. Where appropriate, this field displays the Alarm Panel LEDs that are lit for an event.

For more information about LEDs and light path, see Light path diagnostic LEDs - BladeCenter T and BladeCenter HT chassis.

User response
Indicates what actions should be performed by the user to resolve the event. If, after performing all of the actions described in the User Response, the user cannot resolve the problem, the user should contact IBM. See Getting help and technical assistance for more information.

Perform the steps listed in this section in the order shown until the problem is resolved.

Note: In addition to the steps shown in this section, another resource that you can use is the Problem Determination and Service Guide for the specified blade server type. It might have more specific steps that can be used to resolve this event.