This ZenPack is developed and supported by Zenoss Inc. Commercial ZenPacks are available to Zenoss commercial customers only. Contact Zenoss to request more information regarding this or any other ZenPacks. Click here to view all available Zenoss Commercial ZenPacks.
The DMTF Redfish ZenPack allows you to monitor servers that provide support for Redfish API.
This ZenPack provides support for monitoring servers implementing Redfish API. For example SuperMicro X10/X11 servers, Dell PowerEdge 13G/14G servers, and HP Proliant servers with iLO5
The Redfish Scalable Platforms Management API is a standard from DMTF that uses RESTful interface semantics to access data defined in model format to perform systems management. It is suitable for a wide range of servers, from stand-alone servers to rack mount and bladed environments but scales equally well for large-scale cloud environments.
The features added by this ZenPack can be summarized as follows. Each of them is described below.
The following components will be automatically discovered through the Redfish API hostname you provide. The properties and relationships will be continually maintained.
There is RedfishStatus template bound to each component which checks the component's status every 5 minutes and generates /Status/Redfish events with severity:
The following metrics are collected every 5 minutes by default. Any other Redfish metrics can also be collected by adding them to the appropriate monitoring template.
Redfish API provides access to logs that Redfish ZP may fetch and convert to Zenoss events. There is a separate datasource plugin (RedfishLogDataSource in Manager template) that performs such work.
As some logs might be a bit chatty (e.g. audit logs may record each login to Redfish), there is a zRedfishSkipLogs zProperty, which sets a list of Redfish's logs we don't want to fetch. A list of all available logs is on each Manager components details page: "Available Logs" property. We can also suppress unnecessary logs by creating transforms.
Redfish has the next record types: * Event * SEL * Oem
Depending on a record type Redfish ZP will use different strategies for setting eventKey and severity fields in Zenoss events.
Published events will have the next standard fields: - component: Redfish Manager component which provides logs - eventKey: unique value based on a sensor number for SEL events, empty for all other events - eventClassKey: equal to RedfishLog (mapped to /Redfish/Log event class). - rcvtime: event creation time taken from Redfish. - summary: description from the original event - severity: for Event and Oem types are always Info, for SEL events: * Redfish Ok = Zenoss Clear * Redfish Warning = Zenoss Warning * Redfish Critical = Zenoss Error
The following additional fields will also be populated for each event: - redfish.log - redfish.log_id - redfish.entry_type - redfish.message_id - redfish.sensor_number - redfish.sensor_type - redfish.severity
Installing this ZenPack will add the following items to your Zenoss system.
The following plugins will be used for modeling a Redfish device details:
When combined with the Zenoss Service Dynamics product, this ZenPack adds a built-in service impact and root cause analysis capabilities for services running on Redfish-enabled devices. The service impact relationships shown in the diagram and described below are automatically added. These will be included in any services that contain one or more of the explicitly mentioned components.
Internal Impact Relationships:
External Impact Relationships:
Use the following steps to start monitoring Redfish device using the Zenoss web interface:
Fill out the form.
Alternatively, you can use zenbatchload to add devices from the command line. To do this, you must create a file with contents similar to the following. Replace all values in angle brackets with your values minus the brackets. Multiple devices can be added under the same sections.
<device_host> zRedfishUserName='<username>', zRedfishPassword='<password>', zRedfishPort=443, zRedfishUseSSL='true'
supermicro-bmc.example.com zRedfishUserName='root', zRedfishPassword='$ecret'
You can then load the Devices using zenbatchload with the following command:
Redfish datasource along with standard ones has two additional configuration fields:
"Component OpenData Id" defines internal Redfish Id which is the same as HTTP path in Redfish API. There is no needs to change this field as by default value is taken from the monitored component property oid, which is set during modeling.
"Metric path" specifies a path to the requested value, which is a list of dict's keys separated by slashes. A zero-based index might be used to point the list's item integer, also according to Redfish's specifications all lists elements should have a MemberId value, which might be used as a key instead of an index.
You may use the "Test" button to check whether provided parameters are correct. Before testing datasource you need to set a valid device name in Device Name input field. In the case of an empty "Metric path" field, the test window will show a whole resource output in JSON format, which might be useful if you need to find the correct value for this field.
Please consider the responsiveness of your target devices when the same system is monitored by different Zenoss instances and/or other tools. Multiple issues can be caused by monitoring some devices with several monitoring tools.
Also, be aware that some vendors can provide less data through Redfish API.