Redfish EventService Implementation

Puli, Apparao apparao.puli at
Thu Feb 20 06:19:20 AEDT 2020


   I am sorry for late response as this mail is buried under and got 
struck back of my mind.

As i did mentioned in EventService design document, EventLog Monitor 
service is not common across the organizations( Example: Intel uses the 
redfish event logs file and inotify mechanism for monitoring the event 
logs. Where as IBM uses d-bus event log mechanism and they can relay on 
match rules). That said challenges with ResourceType mapping will be 
different in both monitoring mechanisms. This is good point. Initially 
when i started EventService design, i thought we can have mapping in 
bmcweb for ResourceTypes with set of MessageID's for Logged events ( As 
per Intel design) but not sure that may become difficult when we expand 
supported ResourceTypes.

As per my reading from below query, You are looking at d-bus match rules 
and ResourceTypes mapping which is more specific to d-bus event 
logging(IBM way of implementing event logging). reading it from journal 
logs will give more information but that will impact the performance to 
large extent. This might be one of the reason why we (Intel) uses 
Redfish message ID while logging redfish events logs to journal(You can 
refer design document for same at 
In opinion, in your d-bus if you are using some kind of filter(Example 
REDFISH_MESSAGE_ID) while logging in journal logs for all events and 
figure out the way to monitor the journal logs without impacting the 
performance, that should be ok as long as match filters are satisfied 
for Redfish EventService subscriptions and supported Types(Again differs 
with implementation).



> ApparaRao.
> As you have shown interest in this feature and submitted the design 
> document, do you have any opinion on this? Do you see any merit in 
> using D-Bus match in bmcweb to create event logs for life cycle 
> events?  Please feel free to weigh in.
> Thanks,
> Rajes
> On 01-02-2020 02:23, RAJESWARAN THILLAIGOVINDAN wrote:
>> Hi,
>> I am going through the bmcweb code for implementing Redfish 
>> EventService based on the design document 
>> This 
>> design is hooked to the journal based Redfish Event Logging. For life 
>> cycle events(ResourceAdded, ResourceRemoved, ResourceUpdated),  using 
>> D-Bus match, bmcweb can create an event log. This requires a JSON 
>> dictionary, comprising an array of Redfish Resource Name and the 
>> D-Bus path. This approach works only in case of one to one mapping of 
>> Redfish Resource Name and the D-Bus path. For propertiesChanged 
>> events, if the Redfish Resource property is not on the same D-Bus 
>> path or the Redfish Resource property name is different from the 
>> D-Bus property name, then an additional JSON dictionary to maintain 
>> this information is required. With D-Bus match alone in the bmcweb, 
>> Redfish EventService can't be fully supported. For the Message 
>> Registers and the Resource Types that are supported, the relevant 
>> OpenBMC application must create an event log in the journal using 
>> either the phosphor::logging::entry or sd_journal_send() command.
>> After realizing that with D-Bus match in the bmcweb alone can't help 
>> to fully implement EventService, I prefer to avoid using D-Bus match 
>> in bmcweb. Instead, I prefer to modify the OpenBMC application that 
>> generated the event to create an event log in the journal. Do you see 
>> any advantage of using combination of D-Bus match in the bmcweb 
>> wherever it is possible and changes to OpenBMC application in other 
>> cases to create an event log ?
>> Your views are highly appreciated.
>> Thanks,
>> Rajes

More information about the openbmc mailing list