Re: Host Serial Console Logs via Redfish

[Nan Zhou <nanzhou@google.com>]

[-- Attachment #1: Type: text/plain, Size: 4703 bytes --]

Hi Brad,

Thanks for your reply!

>that phosphor-hostlogger collects host serial console logs via obmc-console
> >and generates tarballs in a rotation manner. These tarballs are then
> >consumed and exposed by a new node in bmcweb log service.
>
> Is it one console line per LogEntry?
>

Yes, one line per LogEntry. A line produced by phosphor-hostlogger in the
zip file has a timestamp + log message in it. The timestamp is then filled
into LogEntries.

>We propose the following methods to improve it.
> >
> >   - Method 1: *D-Bus Signal*; phosphor-hostlogger implements an interface
> >   which contains a signal. The payload of the signal should contain
> >   timestamps and log messages.  BmcWeb registers as a listener and once
> it
> >   receives a signal, it populates a new LogEntry. BmcWeb should
> implement its
> >   own configurable ring buffer to store log entries received from D-Bus.
> >   - Method 2: *File Watcher*; add file watchers in BmcWeb to monitor the
> >   log files produced by phosphor-hostlogger. This method is similar to
> method
> >   1. But persistence is still a necessary condition.
> >   - Method 3: *obmc-console + bmcweb*: install the console collection and
> >   ring buffer parts of phosphor-hostlogger as a library. Use the library
> >   directly in BmcWeb to collect console logs.
> >   - Method 4: *phosphor-hostlogger + journal + rsyslog + bmcweb*: this
> >   architecture is very similar to what the current OpenBMC uses for
> >   redfish-event
> >   <
> https://github.com/openbmc/docs/blob/master/architecture/redfish-logging-in-bmcweb.md
> >.
> >   Add a new schema for log entries. Publish journal logs in
> >   phosphor-hostlogger. Add file watchers in BmcWeb to monitor the log
> files
> >   produced by rsyslog. rsyslog should have log rotation enabled.
> Persistence
> >   is still a necessary condition.
> Perhaps a missing option here is a single dbus object per LogEntry?  I'm
> not necessarily advocating for that - can I assume that was not
> considered because of performance/scaling concerns?

Yes, one DBus object per LogEntry is an option. But as you said, this
option might not scale. We want to mimic a near real-time console via
Redfish and we care about latency.

Sincerely,
Nan

On Tue, Mar 9, 2021 at 6:30 AM Brad Bishop <bradleyb@fuzziesquirrel.com>
wrote:

> Hi Nan
>
> Thanks for this announcement.  I don't have a lot of specific feedback
> for you, but this sort of introduction to new content is super helpful
> for the overall health of OpenBMC.
>
> On Mon, Mar 08, 2021 at 01:45:00PM -0800, Nan Zhou wrote:
>
> >Implementation for Phase 1 is in
> >https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/39093. It is
> >based on obmc-console, phosphor-hostlogger, and bmcweb. The basic idea is
>
> I like how you are making use of these existing projects.
>
> >that phosphor-hostlogger collects host serial console logs via
> obmc-console
> >and generates tarballs in a rotation manner. These tarballs are then
> >consumed and exposed by a new node in bmcweb log service.
>
> Is it one console line per LogEntry?
>
> >We propose the following methods to improve it.
> >
> >   - Method 1: *D-Bus Signal*; phosphor-hostlogger implements an interface
> >   which contains a signal. The payload of the signal should contain
> >   timestamps and log messages.  BmcWeb registers as a listener and once
> it
> >   receives a signal, it populates a new LogEntry. BmcWeb should
> implement its
> >   own configurable ring buffer to store log entries received from D-Bus.
> >   - Method 2: *File Watcher*; add file watchers in BmcWeb to monitor the
> >   log files produced by phosphor-hostlogger. This method is similar to
> method
> >   1. But persistence is still a necessary condition.
> >   - Method 3: *obmc-console + bmcweb*: install the console collection and
> >   ring buffer parts of phosphor-hostlogger as a library. Use the library
> >   directly in BmcWeb to collect console logs.
> >   - Method 4: *phosphor-hostlogger + journal + rsyslog + bmcweb*: this
> >   architecture is very similar to what the current OpenBMC uses for
> >   redfish-event
> >   <
> https://github.com/openbmc/docs/blob/master/architecture/redfish-logging-in-bmcweb.md
> >.
> >   Add a new schema for log entries. Publish journal logs in
> >   phosphor-hostlogger. Add file watchers in BmcWeb to monitor the log
> files
> >   produced by rsyslog. rsyslog should have log rotation enabled.
> Persistence
> >   is still a necessary condition.
>
> Perhaps a missing option here is a single dbus object per LogEntry?  I'm
> not necessarily advocating for that - can I assume that was not
> considered because of performance/scaling concerns?
>
> -brad
>

[-- Attachment #2: Type: text/html, Size: 7182 bytes --]