Chassis Syslog question

[chuckk281]

Stephen was looking for more info on how to interpret SysLog files:

********************************************************************************************************************

My customer is trying to correlate event traps ID’s to what’s in our OA User Guide.  When I first looked at this I thought there was nothing useful provided by the 3 bullets; a host name, “look, it has found in the syslog” and the port number for these traps…

Is it the first number reported that represents the actual event? In this case it would be 8 as that appears in front of the date stamp.

****************************************************************************************************************

Monty got involved:

****************************************************************************************************************

The enclosure event list is internal OA event codes communicated to the OA GUI client – not related to syslog events.

In the OA syslog – we decided to make the syslog entries human readable, not just codes.

Apr  4 16:21:39 10.20.68.90 OA: Blade 10 is reporting degraded health status.

For the entry in your email – what is added to the remote syslog entry compared to the entry on the OA syslog is the IP address of the OA – highlighted in yellow above.  This allows multiple OA modules to send remote syslog events to the same remote logging server, and the OA IP address can be used to distinguish between different enclosures.

This syslog message is similar to the 0x100 OA SOAP event “Blade Device Status Changed” – with the additional information that it was Blade 10, and the health status is now degraded.  Only a limited set of internal OA events get written to the OA syslog due to limited storage space for this log.

All of the other information was added by the remote logging server, not the OA.  The first date is from the remote logging server, along with the DNS name of the OA that sent that syslog message.

*************************************************************************************************************

Stephen then asked:

************************************************************************************************************

Thank you for the education Monty!

Ok, so if I understand the operation correctly the OA will provide high level detail on a server’s status only. And that’s probably because the server itself has an event log where much more detail can be stored.  With the limited storage space of the OA for this type of data we leveraged our traditional ProLiant management architecture in the blades; IML data store and forward SNMP traps as necessary.

So to help the customer with this request we need to advise them that certain event log entries will have more details stored in the server’s or the interconnects internal event log and you should go there if you want more details.  And any entry that involves the actual enclosure (OA, power supplies, fans, temperatures, etc) including the addition or removal of devices will be stored in the OA as outlined in the OA user guide.

Correct?

**************************************************************************************************************

Once again Monty responded:

********************************************************************************************************

Yes, but some error conditions are only available on the OA interfaces:

OA error report on Device bay	Error description	OA action
Device Identification Data	FRU eeprom checksum error detected	Device denied power by OA
Management Processor	iLO or partner blade xMIC does not communicate with OA after insertion	Power remains off.
I/O Configuration	Mismatched embedded or mezz I/O with interconnect	Device denied power by OA
Location*	Partner Device with no server in adjacent bay	Partner blade denied power by OA
Power*	Insufficient power available for device power request	Device denied power by OA
Cooling*	Device bay not supported based on current fan rule	Device denied power by OA
Device Operational	Management processor reports device status OK or failed	OA reports device operational status
Device Degraded	OA reports device degraded based on configuration, location, power or cooling error – or management processor reports device degraded	OA reports device degraded
iLO Network*	OA loses TCP communication with iLO including pings	OA reports this status
Call HP Support*	HP Customer Advisory will be listed	OA syslog entry
Virtual Connect Profile*	If OA reports VC mode is enabled, the OA will report whether a supported server blade has a profile or not	OA reports this status

• Items with asterisk are only displayed if applicable to that Device bay

Hope this helps,

*************************************************************************************************************

Answer some of your questions? Comments?