Redfish EventService Implementation

Ratan Gupta ratagupt at
Mon Feb 24 17:37:42 AEDT 2020

Hi Apparao,

On 2/20/20 12:49 AM, Puli, Apparao wrote:
> Hi,
>   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.

If I am getting correctly, Here is the flow which Intel uses.

 1. Individual repo have to push the logs using sd_journal_send which
    will write to the file(/var/log/redfish) by using rsyslog daemon

sd_journal_send("MESSAGE=%s","journal text","PRIORITY=%i", <LOG_LEVEL>,

      * How you would populate the "OriginOfCondition" during sending of
        event? (

      * Any plan to add resource path in this journal message which
        tells that this is the path for which resource created event

      * Would the path be "Redfish Path/ D-bus Path"?

      * Where the mapping would be done between D-busPath/Redfish
        Resource path?

          Cons: Every application have to make the change(use sd_journal_send).
          My thought is backend application should not be aware of the redfish terminlogy.

*2.* Some application(bmcweb) would do the Inotify on the 
path(/var/log/redfish) and send the event once there is any activity on 
this file.

> I thought we can have mapping in bmcweb for ResourceTypes with set of MessageID's for Logged events ( As 
per Intel design)

     Can you explain more here. What is your plan? How you would do the Resource Type based event filtering?REDFISH_MESSAGE_ID is different than the resource type.

> 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).
> Thanks,
> -Appu
> On 2/10/2020 1:52 AM, RAJESWARAN THILLAIGOVINDAN wrote:
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openbmc mailing list