In addition to the Active Heath System, HPE iLO features log services that enables you to view logs of four different types:
- Security Log (SL)
- Integrated Management Log (IML)
- iLO Event Log (IEL)
- Alert Event Log.
These logs are part of the standard Redfish LogServiceCollection and spanning over the following URIs:
/redfish/v1/Systems/1/LogServices(IML, SL, Alert Event Log)/redfish/v1/Managers/1/LogServices(IEL)
Several log query filtering examples are present in the Odata Query section
The Security Logs provide a record of the security events recorded by the iLO firmware. Examples of the logged events include changes to the security configuration and security compliance issues. Other logged events include hardware intrusion, maintenance, and denial of service. The security logs provide a focused view of all recorded security events. When the security log is full, the new events overwrite the previous event in the log.
To access the Redfish SL resource, perform GET on /redfish/v1/Systems/1/LogServices/SL/. This resource includes a link to the collection of entries /redfish/v1/Systems/1/LogServices/SL/Entries/ and an action /redfish/v1/Systems/1/LogServices/SL/Actions/LogService.ClearLog to clear the SLs. Individual SLs can be accessed by performing GET on /redfish/v1/Systems/1/LogServices/SL/Entries/{@SlId}.
> curl --insecure --location \
https://{iLO}/redfish/v1/systems/1/logservices/sl/entries/3To completely clear all SLs, perform POST on https://{iLOIP}/redfish/v1/systems/1/logservices/sl/Actions/LogService.ClearLog.
Cleared SLs are available in the server AHS logs.
The IML provides a record of historical events that have occurred on the server. Events are generated by the system ROM and by services such as the iLO drivers. Logged events include server-specific information such as health and status information, firmware updates, operating system information, and ROM-based POST codes. Entries in the IML can help you diagnose issues or identify potential issues. Preventative action might help to avoid disruption of service. When the IML is full, new events overwrite the previous event in the log.
- Fan actions and status
- Power supply actions and status
- Temperature status and automatic shutdown actions
- Drive failure
- Firmware flash actions
- Smart Storage Energy Pack status
- Network actions and status
To access the Redfish IML resource, perform GET on /redfish/v1/Systems/1/LogServices/IML/. This resource includes a link to the collection of entries /redfish/v1/Systems/1/LogServices/IML/Entries/ and an action LogService.ClearLog to clear the IMLs. Individual IMLs can be accessed by performing GET on /redfish/v1/Systems/1/LogServices/IML/Entries/{Id}.
> curl --insecure --location /
https://{iLO}/redfish/v1/systems/1/logservices/iml/entries/{Id}To manually mark an IML event as repaired, perform a PATCH on https://{iLOIP}/redfish/v1/systems/1/logservices/iml/entries/{ImlId}. This is only supported on events that are of severity Caution or Critical.
When events are manually marked as repaired, SNMP or REST alerts are not notified.
PATCH /redfish/v1/systems/1/logservices/iml/entries/{ImlId}To completely clear all IMLs, perform POST on https://{iLOIP}/redfish/v1/systems/1/logservices/iml/Actions/LogService.ClearLog.
Cleared IMLs are available in the server AHS logs.
The iLO Event Log provides a record of significant events recorded by the iLO firmware. Examples of the logged events include server events such as a server power outage or a server reset. Other logged events include logins, virtual power events, clearing the log, and some configuration changes. iLO provides secure password encryption, tracking all login attempts and maintaining a record of all login failures. The Authentication Failure Logging setting allows you to configure logging criteria for failed authentications. The event log captures the client name for each logged entry to improve auditing capabilities in DHCP environments, and records the account name, computer name, and IP address. When the event log is full, each new event overwrites the oldest event in the log. For a list of the errors that might appear in the event log, see the error messages guide for your server.
To access the Redfish IEL resource, perform GET on /redfish/v1/Managers/1/LogServices/IEL/. This resource includes a link to the collection of entries /redfish/v1/Managers/1/LogServices/IEL/Entries/ and an action /redfish/v1/Managers/1/LogServices/IEL/Actions/LogService.ClearLog to clear the IELs. Individual IELs can be accessed by performing GET on /redfish/v1/Managers/1/LogServices/IEL/Entries/{@IelId}.
> curl --insecure --location \
https://{iLO}/redfish/v1/managers/1/logservices/iel/entries/{IelId}To completely clear all IELs, perform POST on https://{iLOIP}/redfish/v1/managers/1/logservices/iel/Actions/LogService.ClearLog.
Cleared IELs are still present in the server AHS logs.
The Entries under API - /redfish/v1/Systems/{item}/LogServices/Event/Entries list alerts in iLO. In general, clients can choose to asynchronously receive events by subscribing to events. Alerts are specifically those event entries having EventType as Alert, and they can be accessed synchronously by performing GET on /redfish/v1/Systems/{item}/LogServices/Event/Entries (without subscribing).
These alerts are non-persistent, meaning that after an iLO reset, the count of /Event/Entries resets to 0, and only the new alerts generated after the iLO reset are logged to this collection. iLO can store up to 256 REST alerts (no life cycle events will be stored) in a rolling buffer mechanism. These alerts can also be cleared by performing POST on /redfish/v1/Systems/1/LogServices/Event/Actions/LogService.ClearLog/.
Following information is only stored/retrieved and presented in JSON format as an API response:
EventIDEventTimeStampCreatedMessageIdSeverityOriginOfConditionMessageArgsServiceEvent
The Properties from EventID to MessageArgs are under the LogEntry schema, while ServiceEvent is a new OEM property defined in iLO 5.
To access the Redfish Alert Event Log resource, perform GET on /redfish/v1/Systems/1/LogServices/Event/. This resource includes a link to the collection of entries /redfish/v1/Systems/1/LogServices/Event/Entries and an action /redfish/v1/Systems/1/LogServices/Event/Actions/LogService.ClearLog/ to clear the Alert Event Logs. Individual Alert Event Logs can be accessed by performing GET on /redfish/v1/Systems/1/LogServices/Event/Entries/{@entriesId}.
GET /redfish/v1/Systems/1/LogService/Event/Entries/24To completely clear all Alert Event Logs, perform POST toward https://{iLOIP}/redfish/v1/Systems/1/LogServices/Event/Actions/LogService.ClearLog/.
Read the RESTful Events section for more information on Redfish Events.
The data collected by the Active Health System is stored in the Active Health System Log. The data is logged securely, isolated from the operating system, and separate from customer data. Host resources are not consumed in the collection and logging of Active Health System data.
When the Active Health System Log is full, new data overwrites the oldest data in the log.
It takes less than five minutes to download the Active Health System Log and send it to a support professional to help you resolve an issue.
The HPE Active Health System (AHS) monitors and records changes in the server hardware and system configuration.
The Active Health System provides:
- Continuous health monitoring of over 1600 system parameters
- Logging of all configuration changes
- Consolidated health and service alerts with precise time stamps
- Agentless monitoring that does not affect application performance
Refer to the iLO user guide for more information on the AHS log.
Active Health System (AHS) data may be accessed by first discovering the resource of type HpeiLOActiveHealthSystem. This is typically at https://{iLO}/redfish/v1/managers/{item}/activehealthsystem/. Refer to the LogServiceCollection section for confirmation of this URI.
Perform a GET of the HpeiLOActiveHealthSystem resource and look for the Links object. It contains links to the location of the AHS file associated to time ranges. The following example retrieves this object from an iLO 6 based server.
/redfish/v1/Managers/1/ActiveHealthSystem/?$select=LinksOnce you have identified the location of the AHS file, perform a GET to location with the following query parameters to define the download time range and embed customer case information:
| Query parameter | Description |
|---|---|
case_no | Insert the case number into the AHS log header |
co_name | Insert the company name into the AHS log header |
contact_name | Insert the contact name into the AHS log header |
days | Download the last N days of the AHS log, from today's date |
downloadAll | Download the entire AHS log |
email | Insert the contacts email address into the AHS log header |
from | The starting date of the download range (in YYYY-MM-DD format). Must be added with the to query parameter to limit the range of data returned |
to | The ending date of the download range (in YYYY-MM-DD format). Must be added with the from query parameter to the AHS location URI to limit the range of data returned |
phone | Insert the contacts phone number into the AHS log header |
If successful, the response is an HTTP 200 level status code and a binary download which can be saved to a file.
The following example retrieves the entire AHS log from an HPE iLO 6 based server.
GET /redfish/v1/managers/1/activehealthsystemFor a full Redfish example click here: get_ahs_data.py
Some HPE servers like the HPE DL145 Gen11 embed an air filter that has to be replaced periodically. The iLO of those servers automatically generates reminder records in the Integrated Management Log (IML). By default, HPE iLO reminds you to replace the air filter with an early and critical IMLs at 85 and 90 days of Power-On operation respectively. The examples of HPE iLO generating IMLs are as follows:
The air filter installed in the server has now operated for 85 days and will
reach its maximum usage limit for a highly particulate environments in 5 days.
To ensure optimal performance, it is advised that you inspect the air filter
and replace it, if necessary.Use the following Redfish action to set custom durations for these reminder IMLs:
POST /redfish/v1/managers/1/actions/Oem/Hpe/HpeiLO.TriggerFilterChangeTimerThe request parameters such as RemainingDaysForEarlyReminder and RemainingDaysForCriticalReminder specifies duration of the FinishedPost operation after which the early warning and critical warning reminders are respectively logged.
The power-on duration of a system tracks the operating time of a server, against the set duration for a notification, only when the server POST (Power On Self Test) is complete.
HPE iLO checks for a system uptime every 24 hours to determine the expired reminders. Expect a delay of about 0-24 hours to receive a notification in the IML log after the server has completed the power-on durations set using the RemainingDaysForEarlyReminder and RemainingDaysForCriticalReminder parameters.