<div dir="ltr">I think this is an excellent idea, as it will revive a zombie thread from before 2010:<div><br></div><div><a href="http://erlang.2086793.n4.nabble.com/log-mf-h-and-rb-do-not-handle-terms-over-65k-td2220104.html">http://erlang.2086793.n4.nabble.com/log-mf-h-and-rb-do-not-handle-terms-over-65k-td2220104.html</a><br></div><div><br></div><div>even with Kenneth/OTP making an apperance :)</div><div><br></div><div>The reason I like log_mf_h and rb is because I think it is a very good way of doing log information, especially in space constrained environments where a ring-buffer is good. I would have used this a lot were it not for the fact that it doesn't log anything above 64k in size, but then kills the whole log with that number afterwards. So I drifted toward lager instead. But had this been able to handle that situation gracefully, I'd definitely have used it in many situations. I would have fixed it long ago, were it not for the fact that it takes some effort to actually do correctly, and my 4-byte non-backwards-compatible hack worked back in the day.</div><div><br></div><div>The linux world is moving to binary logging in journald, but I'm not entirely sure I like it since garbled logs in binary are harder to save. On the other hand, given a binary log and an index, searching through logs is *much* faster. There is also an old project of mine which uses machine learning to autoclassify errors into groups, which is based on log_mf_h:</div><div><br></div><div><a href="http://jlouisramblings.blogspot.dk/2011/01/errlxperimentation-clustering-of-erlang.html">http://jlouisramblings.blogspot.dk/2011/01/errlxperimentation-clustering-of-erlang.html</a><br></div><div><br></div><div>these kind of things are far harder to do on textual logs, where you have no erlang term structure readily available.</div><div><br></div><div>The other question though: should this be part of OTP? I think it is an excellent library to have *outside* OTP because it should only rely on an error_logger inside OTP. That way, we can evolve the library in another development cycle than the OTP system, which is good. One problem with OTP currently is that adding functionality has a latency of roughly 0.75 years on average. You write the feature, but it is only available 0.75 years later. This is far too slow for most people. But were the things separate, it might be easier to release an intermediate version between major releases.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 1, 2016 at 12:43 PM, Siri Hansen <span dir="ltr"><<a href="mailto:erlangsiri@gmail.com" target="_blank">erlangsiri@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello list!</div><div><br></div>log_mf_h is an error_logger event handler which logs events to disk and does log rotation. rb (report browser) is the tool for reading and formatting the logs. The implementation of both modules is quite old and outdated. The fact that there is a size field for the events of only 16 bits, which we haven't got any complaints for, has made us believe that there might not be many users of these tools. I'm writing to the list to find out if this is correct... <div><br></div><div>Are you using log_mf_h (e.g. by setting environment variables 'error_logger_mf_*' in sasl) and rb? If so, why - is it the log rotation or the binary logging (or both) that you are really after? Have you considered alternative tools?</div><div><br></div><div>Kind Regards</div><div>/siri@otp</div></div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">J.</div>
</div>