[Proposal] Implementing SensorEvent message registry

[Patrick Williams]

On Tue, Aug 20, 2024 at 05:08:14PM +0000, Amithash Prasad wrote:
 
> We have two primary methods of creating threshold based events.
> (1) Legacy, used only by dbus-sensors, set the ThresholdAsserted signal[2] and subscribed by phosphor-sel-logger[3] Which creates redfish events/messages.
> (2) New, used by others as specified in phosphor-dbus-sensors for Critical[4] and Warning[5]. Current sensor services which raise this signal:
> Phosphor-hwmon[6], phosphor-nvme, and phosphor-virtual-sensor raises a different set of signal[6], using the phosphor-dbus-interface
> 
> Phosphor-sel-logger subscribes to both these signals (Legacy[2] and New[3]) in different implementations both translating them to Redfish Message IDs:
> ```
> OpenBMC.0.1.SensorThresholdCriticalLowGoingLow
> OpenBMC.0.1.SensorThresholdCriticalLowGoingHigh
> OpenBMC.0.1.SensorThresholdWarningLowGoingLow
> OpenBMC.0.1.SensorThresholdWarningLowGoingHigh
> OpenBMC.0.1.SensorThresholdWarningHighGoingHigh
> OpenBMC.0.1.SensorThresholdWarningHighGoingLow
> OpenBMC.0.1.SensorThresholdCriticalHighGoingHigh
> OpenBMC.0.1.SensorThresholdCriticalHighGoingLow
> ```

By the way, I also found out today that there is a "sensor-monitor"
subset of phosphor-fan-presence repository that also creates a different
set of events.

> These messages export 3 args: Sensor name, Sensor Reading Value, Threshold Value.
> 
> While these provide value and have served us well, they have a main drawback:
> 
> They are not part of the redfish standard which specifies explicit messages around sensor threshold events.
> Having events emitted which are specified in the redfish standard message registry have very specific advantages
> for the client side who can use a consistent library.
> 
> Proposed Messages:
> I plan on creating new events which are based and intended to provide Redfish SensorEvent 1.0.0[7, ch2.14]. 
> ```
> SensorEvent.1.0.ReadingAboveLowerCriticalThreshold (Warning)
> SensorEvent.1.0.ReadingAboveLowerFatalThreshold (Critical)
> SensorEvent.1.0.ReadingAboveUpperCautionThreshold (Warning)
> SensorEvent.1.0.ReadingAboveUpperCriticalThreshold (Critical)
> SensorEvent.1.0.ReadingAboveUpperFatalThreshold (Critical)
> SensorEvent.1.0.ReadingBelowLowerCautionThreshold (Warning)
> SensorEvent.1.0.ReadingBelowLowerCriticalThreshold (Critical)
> SensorEvent.1.0.ReadingBelowLowerFatalThreshold (Critical)
> SensorEvent.1.0.ReadingBelowUpperCriticalThreshold (Warning)
> SensorEvent.1.0.ReadingBelowUpperFatalThreshold (Critical)
> SensorEvent.1.0.SensorReadingNormalRange (OK)
> ```
> All except the last one of these provide 4 arguments:
> string: The name or identifier of the sensor. This argument shall contain a string that identifies or describes the Sensor resource.
> number: The reading of the sensor. This argument shall contain a number that equals the value of the Reading property of the
> Sensor resource.
> string: The reading units of measure. This argument shall contain a string that equals the value of the ReadingUnits property
> of the Sensor resource. Unitless readings should use count .
> number: The threshold value. This argument shall contain a number that equals the value of the Reading property within the
> <threshold> property of the Sensor resource.
> SensorEvent.1.0.0.SensorReadingNormalRange would have only the first 3 arguments.

SGTM.


> (2) Have each of the sensor monitoring services (dbus-sensors[9], pldm [10] when it lands, virtual-sensors[11],
> phosphor-hwmon[12]) updated to use the appropriate new message/exceptions.
> We can track thresholds as they exceed and log.
> Each service will log an appropriate event as the value exceeds a threshold. (Example, reading exceeding Caution

Yes! Each service that implements Threshold interfaces should be logging
their own event for the threshold exceeded situations.  No more
phosphor-sel-logger / phosphor-fan-presence-sensor-monitor behavior of
some _other_ process logging the event.

> 
> Thanks,
> Amithash

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20240828/f86fa668/attachment.sig>