<div dir="ltr"><span class="gmail-im" style="color:rgb(80,0,80)">On Thu, May 20, 2021 at 04:29:09PM -0700, Nan Zhou wrote:<br></span><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)">> Hi all,<br></span><span class="gmail-im" style="color:rgb(80,0,80)">><br></span><span class="gmail-im" style="color:rgb(80,0,80)">> In the previous thread (<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> <a href="https://lists.ozlabs.org/pipermail/openbmc/2021-March/025234.html" rel="noreferrer" target="_blank">https://lists.ozlabs.org/pipermail/openbmc/2021-March/025234.html</a>), we<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> (engineers from Google and Quanta) discussed our attempt to share host<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> serial logs via Redfish, which includes polling logs via LogService and<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> streaming log bytes via EventService (e.g. SSE). We went with the event log<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> architecture<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>> and did the implementation.<br><span class="gmail-im" style="color:rgb(80,0,80)">><br></span><span class="gmail-im" style="color:rgb(80,0,80)">> We still want to reuse the phosphor-hostlogger and do some modification. We<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> believe it is better to try to reuse existing codes if possible and improve<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> them rather than creating new things that have similar functionalities (in<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> our case, it is a daemon that could collect logs and persist them).</span><span class="gmail-im" style="color:rgb(80,0,80)"><br></span>I agree, reusing code is a right choice, but only when it is really possible.<br>For now it looks like you want to remove most of the Hostlogger features to<br>transform it from buffer-like to stream-like service.</blockquote><div>Hostlogger will still consume bytes from obmc-console-server and persist logs in files. If the log itself has EOL, it will be splitted in the file as well. </div><div>I thought that is all things we want in the Hostlogger. </div><span class="gmail-im" style="color:rgb(80,0,80)"><br></span><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 want to do the following modification in phosphor-hostlogger (from the<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> input and output point of view, just very few things will be changed)<br></span><span class="gmail-im" style="color:rgb(80,0,80)">><br></span><span class="gmail-im" style="color:rgb(80,0,80)">> 1. One limitation of phosphor-hostlogger is that it will lose data in the<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> memory (the ring buffer maintained by hostlogger) when BMC gets force<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> restarted;</span><span class="gmail-im" style="color:rgb(80,0,80)"><br></span>When BMC goes to reboot it stops all services, at that moment hostlogger gets<br>a signal and flushes all gathered logs to a file.</blockquote><div>Yes, I understand hostlogger registers a sigterm handler. But what if BMC lost its power before sigterm gets sent? That's what I mean by "force restart".</div><span class="gmail-im" style="color:rgb(80,0,80)"><br>> we propose to remove the ring buffer and write to the log file<br>> as soon as some characters are received.<br><br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I am not sure it is a good idea.<br>The host can generate a lot of logs, but we have very limited free space. In<br>addition, such heavy traffic will lead to a quick breakdown of the flash (most<br>available products are guaranteed to withstand around 100,000 P/E cycles only).</blockquote><div>I would like to get input from Ed for this point. <a class="gmail_plusreply" id="plusReplyChip-1" href="mailto:edtanous@google.com" tabindex="-1">+Ed Tanous</a>. </div><span class="gmail-im" style="color:rgb(80,0,80)"><br></span><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)">> This implicitly removes the needs<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> of the ring buffer, and the persistence triggering (host reboot, sigterm,<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> etc) in hostlogger. We believe this keeps the same functionality but saves<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> hundreds of lines of codes in phosphor-hostlogger.</span><span class="gmail-im" style="color:rgb(80,0,80)"><br></span>You are suggesting to delete the buffer, DBus watcher, log rotate. How are you<br>going to keep the same functionality if you remove everything related to it?</blockquote><div>Log rotation is kept. Ring buffer and DBus watcher are great in the original design but become unnecessary if we persist logs immediately. Do we miss</div><div>anything that the previous hostlogger provides (transfer bytes from the unix socket to EOL-separated compressed logs)? I believe in this proposal we have </div><div>less data loss, simpler codes, and make it more performant for Redfish integration. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 20, 2021 at 11:10 PM Artem Senichev <<a href="mailto:artemsen@gmail.com">artemsen@gmail.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">On Thu, May 20, 2021 at 04:29:09PM -0700, Nan Zhou wrote:<br>
> Hi all,<br>
> <br>
> In the previous thread (<br>
> <a href="https://lists.ozlabs.org/pipermail/openbmc/2021-March/025234.html" rel="noreferrer" target="_blank">https://lists.ozlabs.org/pipermail/openbmc/2021-March/025234.html</a>), we<br>
> (engineers from Google and Quanta) discussed our attempt to share host<br>
> serial logs via Redfish, which includes polling logs via LogService and<br>
> streaming log bytes via EventService (e.g. SSE). We went with the event log<br>
> architecture<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>
> and did the implementation.<br>
> <br>
> We still want to reuse the phosphor-hostlogger and do some modification. We<br>
> believe it is better to try to reuse existing codes if possible and improve<br>
> them rather than creating new things that have similar functionalities (in<br>
> our case, it is a daemon that could collect logs and persist them).<br>
<br>
I agree, reusing code is a right choice, but only when it is really possible.<br>
For now it looks like you want to remove most of the Hostlogger features to<br>
transform it from buffer-like to stream-like service.<br>
<br>
> We want to do the following modification in phosphor-hostlogger (from the<br>
> input and output point of view, just very few things will be changed)<br>
> <br>
> 1. One limitation of phosphor-hostlogger is that it will lose data in the<br>
> memory (the ring buffer maintained by hostlogger) when BMC gets force<br>
> restarted;<br>
<br>
When BMC goes to reboot it stops all services, at that moment hostlogger gets<br>
a signal and flushes all gathered logs to a file.<br>
<br>
> we propose to remove the ring buffer and write to the log file<br>
> as soon as some characters are received.<br>
<br>
I am not sure it is a good idea.<br>
The host can generate a lot of logs, but we have very limited free space. In<br>
addition, such heavy traffic will lead to a quick breakdown of the flash (most<br>
available products are guaranteed to withstand around 100,000 P/E cycles only).<br>
<br>
> This implicitly removes the needs<br>
> of the ring buffer, and the persistence triggering (host reboot, sigterm,<br>
> etc) in hostlogger. We believe this keeps the same functionality but saves<br>
> hundreds of lines of codes in phosphor-hostlogger.<br>
<br>
You are suggesting to delete the buffer, DBus watcher, log rotate. How are you<br>
going to keep the same functionality if you remove everything related to it?<br>
<br>
> 2. We propose not to compress the latest log file. This saves us the<br>
> overhead of doing decompression when BMCWeb just needs to retrieve the most<br>
> recent logs. There are still going to be log rotations in the file level.<br>
> Files other than the latest log file are still going to be compressed. We<br>
> can modify existing codes to achieve this or use the linux logrotate<br>
> directly.<br>
> <br>
> Furthermore, we will add host serial logs into BMCWeb, both LogService and<br>
> EventService. In LogService, we will teach BMCWeb how to read the latest<br>
> log file that is not compressed and the other compressed old logs, and how<br>
> to assemble LogEntries out of raw serial logs. We will discuss EventService<br>
> in future threads but the very initial idea is to setup inotify on log<br>
> files and SSE to stream out new bytes to clients (like what the existing<br>
> event logging is doing).<br>
> <br>
> As we said above, for phosphor-hostlogger, the input is still the<br>
> obmc-server unix socket, and the output are still persisted log files. But<br>
> the functionality will get improved (less data loss), code gets simplified<br>
> (no ring buffer and persistence triggering), and it will become easier and<br>
> more performant to get BMCWeb hooked up for log streaming via Redfish.<br>
> <br>
> Please let us know what you think. We appreciate any feedback. Thank you<br>
> very much!<br>
> <br>
> Sincerely,<br>
> Nan<br>
<br>
-- <br>
Regards,<br>
Artem Senichev<br>
Software Engineer, YADRO.<br>
</blockquote></div>