## Log services In addition to the [Active Heath System](#the-active-health-system-log), HPE iLO features log services that enables you to view logs of four different types: - Security Log ([SL](#security-logs)) - Integrated Management Log ([IML](#integrated-management-log)) - iLO Event Log ([IEL](#ilo-event-log)) - [Alert Event Log](#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) TIP Several log query filtering examples are present in the [Odata Query section](/docs/redfishservices/ilos/supplementdocuments/odataqueryoptions/) ## Security Logs 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. ### Accessing SLs through Redfish 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 ```shell > curl --insecure --location \ https://{iLO}/redfish/v1/systems/1/logservices/sl/entries/3 ``` Response body ```json { "@odata.context": "/redfish/v1/$metadata#LogEntry.LogEntry", "@odata.etag": "W/\"FAE7C91E\"", "@odata.id": "/redfish/v1/Systems/1/LogServices/SL/Entries/3", "@odata.type": "#LogEntry.v1_11_0.LogEntry", "Id": "3", "Created": "2022-10-12T09:19:32Z", "EntryType": "Oem", "Message": "The overall security state of the system is at \"Risk\".", "Name": "Security Log", "Oem": { "Hpe": { "@odata.context": "/redfish/v1/$metadata#HpeLogEntry.HpeLogEntry", "@odata.type": "#HpeLogEntry.v2_4_0.HpeLogEntry", "Categories": [ "Security", "Administration", "Configuration" ], "Class": 55, "ClassDescription": "Security Configuration", "Code": 5, "Count": 1, "EventNumber": 89, "RecommendedAction": "Refer to iLO user manual or Security Dashboard help page.", "Severity": "Caution", "Updated": "2022-10-12T09:19:32Z", "UserAction": "None" } }, "OemRecordFormat": "Hpe-SL", "Severity": "Warning" } ``` ### Clearing SLs through Redfish Action To completely clear all SLs, perform `POST` on `https://{iLOIP}/redfish/v1/systems/1/logservices/sl/Actions/LogService.ClearLog`. NOTE Cleared SLs are available in the server [AHS](#the-active-health-system-log) logs. ## Integrated Management Log 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. ### Examples of IML event types - 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 ### Accessing IMLs through Redfish 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 ```shell > curl --insecure --location / https://{iLO}/redfish/v1/systems/1/logservices/iml/entries/{Id} ``` Response body ```json { "@odata.context": "/redfish/v1/$metadata#LogEntry.LogEntry", "@odata.id": "/redfish/v1/Systems/1/LogServices/IML/Entries/3", "@odata.type": "#LogEntry.v1_11_0.LogEntry", "Id": "3", "Created": "2022-10-14T07:33:24Z", "EntryType": "Oem", "Message": "BCM 5720 1GbE 2p BASE-T LOM Adptr - NIC Connectivity status changed to OK for adapter in slot 0, port 2", "Name": "Integrated Management Log", "Oem": { "Hpe": { "@odata.context": "/redfish/v1/$metadata#HpeLogEntry.HpeLogEntry", "@odata.type": "#HpeLogEntry.v2_4_0.HpeLogEntry", "Categories": [ "Hardware" ], "Class": 17, "ClassDescription": "Network", "Code": 10, "Count": 1, "EventNumber": 8332, "LearnMoreLink": "http://www.hpe.com/support/class0x0011code0x000a-gen11", "RecommendedAction": "If the connection is lost, then check the physical connection from the server to its destination device such as interconnect ,blade, switch etc, including any cables. Refer to the NIC issues flowchart in the Troubleshooting Guide for more information.", "Repaired": true, "Severity": "Repaired", "Updated": "2022-10-14T07:33:24Z" } }, "OemRecordFormat": "Hpe-IML", "Severity": "OK" } ``` ### Repairing IMLs through Redfish PATCH 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`. NOTE When events are manually marked as repaired, SNMP or REST alerts are not notified. Repair event request ```text PATCH /redfish/v1/systems/1/logservices/iml/entries/{ImlId} ``` Body ```json { "Oem" : { "Hpe" : { "Repaired" : true } } } ``` ### Clearing IMLs through Redfish Action To completely clear all IMLs, perform `POST` on `https://{iLOIP}/redfish/v1/systems/1/logservices/iml/Actions/LogService.ClearLog`. NOTE Cleared IMLs are available in the server [AHS](#the-active-health-system-log) logs. ## iLO Event Log 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. ### Accessing IELs through Redfish 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 ```shell > curl --insecure --location \ https://{iLO}/redfish/v1/managers/1/logservices/iel/entries/{IelId} ``` Response body ```json { "@odata.context": "/redfish/v1/$metadata#LogEntry.LogEntry", "@odata.etag": "W/\"1BAAE966\"", "@odata.id": "/redfish/v1/Managers/1/LogServices/IEL/Entries/3", "@odata.type": "#LogEntry.v1_11_0.LogEntry", "Id": "3", "Created": "2022-10-26T19:26:26Z", "EntryType": "Oem", "Message": "Browser logout: Administrator - 192.168.230.1(DNS name not found).", "Name": "iLO Event Log", "Oem": { "Hpe": { "@odata.context": "/redfish/v1/$metadata#HpeLogEntry.HpeLogEntry", "@odata.type": "#HpeLogEntry.v2_4_0.HpeLogEntry", "Categories": [ "Security", "Administration" ], "Class": 35, "ClassDescription": "iLO 6", "Code": 1018, "Count": 1, "EventNumber": 10147, "Severity": "Informational", "Updated": "2022-10-26T19:26:26Z" } }, "OemRecordFormat": "Hpe-iLOEventLog", "Severity": "OK" } ``` ### Clearing IELs through Redfish Action To completely clear all IELs, perform `POST` on `https://{iLOIP}/redfish/v1/managers/1/logservices/iel/Actions/LogService.ClearLog`. NOTE Cleared IELs are still present in the server [AHS](#the-active-health-system-log) logs. ## Alert Event Log 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](/docs/concepts/redfishevents/). `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: - `EventID` - `EventTimeStamp` - `Created` - `MessageId` - `Severity` - `OriginOfCondition` - `MessageArgs` - `ServiceEvent` The Properties from `EventID` to `MessageArgs` are under the `LogEntry` schema, while `ServiceEvent` is a new OEM property defined in iLO 5. ### Accessing Alert Event Log through Redfish 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 Event entry ```text GET /redfish/v1/Systems/1/LogService/Event/Entries/24 ``` Response body ```json { "@odata.context": "/redfish/v1/$metadata#LogEntry.LogEntry", "@odata.id": "/redfish/v1/Systems/1/LogServices/Event/Entries/24/", "@odata.type": "#LogEntry.v1_11_0.LogEntry", "Id": "24", "Created": "2022-08-01T00:05:59Z", "EntryType": "Oem", "EventId": "3f4b0657-6612-5c36-d2fa-d747682c8c8b", "EventTimestamp": "2022-08-01T00:05:59Z", "Links": { "OriginOfCondition": { "@odata.id": "/redfish/v1/Chassis/2/Thermal#Fans/0/" } }, "MessageArgs": [ "1" ], "MessageId": "iLOEvents.3.7.FanFailed", "Name": "Event", "Oem": { "Hpe": { "@odata.context": "/redfish/v1/$metadata#HpeLogEntry.HpeLogEntry", "@odata.type": "#HpeLogEntry.v2_4_0.HpeLogEntry", "ServiceEvent": "True" } }, "OemRecordFormat": "Hpe-Event", "Severity": "Critical" } ``` ### Clearing Alert Event Log through Redfish Action To completely clear all Alert Event Logs, perform POST toward `https://{iLOIP}/redfish/v1/Systems/1/LogServices/Event/Actions/LogService.ClearLog/`. TIP Read the [RESTful Events](/docs/concepts/redfishevents/) section for more information on Redfish Events. ## The Active Health System Log 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. ### Download Active Health System Data examples 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. GET request ```text /redfish/v1/Managers/1/ActiveHealthSystem/?$select=Links ``` Response body ```json { "@odata.context": "/redfish/v1/$metadata#HpeiLOActiveHealthSystem.HpeiLOActiveHealthSystem", "@odata.etag": "W/\"C6FCEAC3\"", "@odata.id": "/redfish/v1/Managers/1/ActiveHealthSystem/", "@odata.type": "#HpeiLOActiveHealthSystem.v2_5_0.HpeiLOActiveHealthSystem", "Links": { "AHSLocation": { "extref": "/ahsdata/HPE_XZA22545B4_20230103.ahs?downloadAll=1" }, "RecentWeek": { "extref": "/ahsdata/HPE_XZA22545B4_20230103.ahs?days=7" }, "InfoSight": { "extref": "/ahsdata/HPE_XZA22545B4_20230103.ahs?minimalDL=1&&days=1" } } } ``` Once 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. #### Download the entire AHS log The following example retrieves the entire AHS log from an HPE iLO 6 based server. Generic request ```text GET /redfish/v1/managers/1/activehealthsystem ``` cURL ```shell curl --insecure --location --user :password \ https:////redfish/v1/managers/1/activehealthsystem ``` iLOrest ```shell ilorest login -u -p password ilorest -d serverlogs --selectlog=AHS --downloadallahs ``` For a full Redfish example click here: get_ahs_data.py ## Air Filter record 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: Early reminder log entry ```text 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. ``` Critical reminder log entry ```text The air filter installed in the server has now operated for 90 days and has reached its maximum usage limit for a highly particulate environment. 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 action ```text POST /redfish/v1/managers/1/actions/Oem/Hpe/HpeiLO.TriggerFilterChangeTimer ``` Payload ```json { "RemainingDaysForEarlyReminder": , "RemainingDaysForCriticalReminder": } ``` The request parameters such as `RemainingDaysForEarlyReminder` and `RemainingDaysForCriticalReminder` specifies duration of the `FinishedPost` [operation](/docs/redfishservices/ilos/ilo6/ilo6_174/ilo6_computersystem_resourcedefns174#oemhpepoststate) 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. NOTE 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.