<div dir="ltr"><div><div>Would it be possible to split out the binary data so it could be used as an option with the rotating files? I don't know if this would be interesting as such but you colud maybe still use rb to view the logs.<br><br></div>Another benefit of doing this would be to break out the formatting of the log messages outside of the erlang system. This would give all the speed benefits and still provide text logs for those who want it. It would also make it easier to provide different text formats.<br><br></div>Robert<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 2 April 2016 at 09:05, Vance Shipley <span dir="ltr"><<a href="mailto:vances@motivity.ca" target="_blank">vances@motivity.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Apr 1, 2016 12:44 PM, "Siri Hansen" <<a href="mailto:erlangsiri@gmail.com">erlangsiri@gmail.com</a>> wrote:<br>
</span><span class="">> Are you using log_mf_h (e.g. by setting environment variables 'error_logger_mf_*' in sasl) and rb?<br>
<br>
</span>Yes, this is part of my default configuration for embedded systems.<br>
<span class=""><br>
> If so, why - is it the log rotation or the binary logging (or both) that you are really after?<br>
<br>
</span>Both.<br>
<span class=""><br>
> Have you considered alternative tools?<br>
<br>
</span>I've considered application specific versions of this scheme.<br>
<span class=""><br>
On Sat, Apr 2, 2016 at 1:23 AM, Robert Raschke <<a href="mailto:rtrlists@googlemail.com">rtrlists@googlemail.com</a>> wrote:<br>
> Unfortunately, straight logged binary data and formatting it at read time appears to be majorly out of fashion :-(<br>
<br>
</span>Stupidly so IMHO.  I often see systems with a mission of moving<br>
massive amounts of message traffic logging data orders of magnitude<br>
larger than the size of the actual message.  Doing so naively results<br>
in the servers spending much more time logging than doing the work<br>
they're intended to do.  Logging is important and at this rate it<br>
costs real money to accomplish so it deserves to be engineered<br>
sensibly.  My rational is that where a gen_fsm is spawned for each<br>
transaction it should simply do it's work and before terminating send<br>
it's State variable term, usually a record, directly to a log handler<br>
(e.g. disk_log).  To have the worker for traffic doing string<br>
processing for an human to possibly read a long time later makes no<br>
sense.  Log binary data to disk and format just the data requested, at<br>
request time, formatted for the requestor.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
     -Vance<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br></div>