Historical Sensor Information

Brad Bishop bradleyb at fuzziesquirrel.com
Sat Aug 17 05:54:49 AEST 2019


at 1:02 PM, Joseph Reynolds <jrey at linux.ibm.com> wrote:

>
>
> On 8/15/19 5:50 PM, Wilfred Smith wrote:
>> Many thanks to Emily, Milton and Kun Yi for their quick responses and  
>> pointers.
>>
>> Among the reasons for local historical data collection are independent  
>> auditing, disaster recovery, debugging and increasing availability  
>> during periods of intermittent network connectivity.
>>
>> Vijay is already participating in the Telemetry workgroup, so I’ll try  
>> to get a download from him to see what can be leveraged.
>>
>> The requirement at Facebook includes the ability to retrieve historical  
>> sensor information for a user-defined period and interval on the BMC  
>> console (through sensor-util, and in the same format). Based on my  
>> cursory review of collectd, its lossy multicast network protocol  
>> wouldn’t allow this information to be re-synthesized with fidelity on the
>
> I share this concern and would prefer to have a more reliable way to get  
> sensor data off the BMC.  This data may be valuable to help detect when  
> the BMC is being attacked.

I don’t think anyone intended to use the collectd network plugin to publish  
the sensor data (although you could).  IIUC the intent was to use collectd  
only in the capacity of collecting the sensor data into an rrd database on  
the BMC flash.  From there you can get the data out of the BMC however you  
like.  IPMI<->rrd.  Redfish<->rrd.  ssh+cli<->rrd.  Do I have it right Kun?


More information about the openbmc mailing list