<div dir="ltr">Hi Brad,<div><br></div><div>Thanks for your reply!</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im" style="color:rgb(80,0,80)">>that phosphor-hostlogger collects host serial console logs via obmc-console<br>>and generates tarballs in a rotation manner. These tarballs are then<br>>consumed and exposed by a new node in bmcweb log service.<br><br></span>Is it one console line per LogEntry?<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im" style="color:rgb(80,0,80)">>We propose the following methods to improve it.<br></span><span class="gmail-im" style="color:rgb(80,0,80)">><br></span>> - Method 1: *D-Bus Signal*; phosphor-hostlogger implements an interface<br><span class="gmail-im" style="color:rgb(80,0,80)">> which contains a signal. The payload of the signal should contain<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> timestamps and log messages. BmcWeb registers as a listener and once it<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> receives a signal, it populates a new LogEntry. BmcWeb should implement its<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> own configurable ring buffer to store log entries received from D-Bus.<br></span>> - Method 2: *File Watcher*; add file watchers in BmcWeb to monitor the<br><span class="gmail-im" style="color:rgb(80,0,80)">> log files produced by phosphor-hostlogger. This method is similar to method<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> 1. But persistence is still a necessary condition.<br></span>> - Method 3: *obmc-console + bmcweb*: install the console collection and<br><span class="gmail-im" style="color:rgb(80,0,80)">> ring buffer parts of phosphor-hostlogger as a library. Use the library<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> directly in BmcWeb to collect console logs.<br></span>> - Method 4: *phosphor-hostlogger + journal + rsyslog + bmcweb*: this<br><span class="gmail-im" style="color:rgb(80,0,80)">> architecture is very similar to what the current OpenBMC uses for<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> redfish-event<br></span>> <<a href="https://github.com/openbmc/docs/blob/master/architecture/redfish-logging-in-bmcweb.md" rel="noreferrer" target="_blank">https://github.com/openbmc/docs/blob/master/architecture/redfish-logging-in-bmcweb.md</a>>.<br><span class="gmail-im" style="color:rgb(80,0,80)">> Add a new schema for log entries. Publish journal logs in<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> phosphor-hostlogger. Add file watchers in BmcWeb to monitor the log files<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> produced by rsyslog. rsyslog should have log rotation enabled. Persistence<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> is still a necessary condition.</span><span class="gmail-im" style="color:rgb(80,0,80)"><br></span>Perhaps a missing option here is a single dbus object per LogEntry? I'm<br>not necessarily advocating for that - can I assume that was not<br>considered because of performance/scaling concerns?</blockquote><div>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.</div><div><br></div><div>Sincerely,</div><div>Nan</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 9, 2021 at 6:30 AM Brad Bishop <<a href="mailto:bradleyb@fuzziesquirrel.com">bradleyb@fuzziesquirrel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Nan<br>
<br>
Thanks for this announcement. I don't have a lot of specific feedback <br>
for you, but this sort of introduction to new content is super helpful <br>
for the overall health of OpenBMC.<br>
<br>
On Mon, Mar 08, 2021 at 01:45:00PM -0800, Nan Zhou wrote:<br>
<br>
>Implementation for Phase 1 is in<br>
><a href="https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/39093" rel="noreferrer" target="_blank">https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/39093</a>. It is<br>
>based on obmc-console, phosphor-hostlogger, and bmcweb. The basic idea is<br>
<br>
I like how you are making use of these existing projects.<br>
<br>
>that phosphor-hostlogger collects host serial console logs via obmc-console<br>
>and generates tarballs in a rotation manner. These tarballs are then<br>
>consumed and exposed by a new node in bmcweb log service.<br>
<br>
Is it one console line per LogEntry?<br>
<br>
>We propose the following methods to improve it.<br>
><br>
> - Method 1: *D-Bus Signal*; phosphor-hostlogger implements an interface<br>
> which contains a signal. The payload of the signal should contain<br>
> timestamps and log messages. BmcWeb registers as a listener and once it<br>
> receives a signal, it populates a new LogEntry. BmcWeb should implement its<br>
> own configurable ring buffer to store log entries received from D-Bus.<br>
> - Method 2: *File Watcher*; add file watchers in BmcWeb to monitor the<br>
> log files produced by phosphor-hostlogger. This method is similar to method<br>
> 1. But persistence is still a necessary condition.<br>
> - Method 3: *obmc-console + bmcweb*: install the console collection and<br>
> ring buffer parts of phosphor-hostlogger as a library. Use the library<br>
> directly in BmcWeb to collect console logs.<br>
> - Method 4: *phosphor-hostlogger + journal + rsyslog + bmcweb*: this<br>
> architecture is very similar to what the current OpenBMC uses for<br>
> redfish-event<br>
> <<a href="https://github.com/openbmc/docs/blob/master/architecture/redfish-logging-in-bmcweb.md" rel="noreferrer" target="_blank">https://github.com/openbmc/docs/blob/master/architecture/redfish-logging-in-bmcweb.md</a>>.<br>
> Add a new schema for log entries. Publish journal logs in<br>
> phosphor-hostlogger. Add file watchers in BmcWeb to monitor the log files<br>
> produced by rsyslog. rsyslog should have log rotation enabled. Persistence<br>
> is still a necessary condition.<br>
<br>
Perhaps a missing option here is a single dbus object per LogEntry? I'm <br>
not necessarily advocating for that - can I assume that was not <br>
considered because of performance/scaling concerns?<br>
<br>
-brad<br>
</blockquote></div>