Redfish EventService Implementation
ratagupt at linux.vnet.ibm.com
Mon Feb 24 17:37:42 AEDT 2020
On 2/20/20 12:49 AM, Puli, Apparao wrote:
> 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
* 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
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
> 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).
> On 2/10/2020 1:52 AM, RAJESWARAN THILLAIGOVINDAN wrote:
>> 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.
>> On 01-02-2020 02:23, RAJESWARAN THILLAIGOVINDAN wrote:
>>> I am going through the bmcweb code for implementing Redfish
>>> EventService based on the design document
>>> https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/24749. 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openbmc