<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Lukas - that’s great news. <div class=""><br class=""></div><div class="">I see that discussions have already aired filtering, and I think that the main lesson for me from RELEASE was it’s crucial to find ways to deal with torrents of potential data. It’s no good to generate trace info which is filtered out downstream: if it can be filtered at source, so only generated when required, then that would be great.</div><div class=""><br class=""></div><div class="">Another facility which may be problematic to implement, but which could be really helpful, would be mechanisms to aggregate information as part of the BEAM: e.g. to be able to emit a trace message every time 1000 messages have passed from process A to process B, or node A to node B. Again this would push into the infrastructure something that currently needs to be done in trace processing.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Simon</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 21 Sep 2015, at 10:52, Lukas Larsson <<a href="mailto:lukas@erlang.org" class="">lukas@erlang.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hello everyone.<div class=""><br class=""></div><div class="">As you may know, one of the OTP teams focus areas for the coming year is make tracing better. At the moment we are gathering ideas and attempting to put together a vision of what we would like to have, before deciding what we can make. </div><div class=""><br class=""></div><div class="">I'm pretty sure that many of you have much more experience with using Erlang tracing while developing and in production than I do, which is we would love to have your input as to what you would like to change about tracing.</div><div class=""><br class=""></div><div class="">To set the scope of the discussion, when I say tracing I include; erlang tracing, dtrace/systemtap, trace outputs (stdout/file/IP), filtering through match specs, sequence tracing, tool integration (dbg, fprof, redbug, recon to mention some) and probably more.</div><div class=""><br class=""></div><div class="">To start the discussion, here are a few of my ideas in no particular order:</div><div class=""> * Allow multiple tracers. Today only one port/process can be the receiver of trace data.</div><div class=""> * Create a couple of scalable high throughput tracing output backends with different overflow mechanics. Today all tracing is funneled through one bottleneck and has no overflow handling at all.</div><div class=""> * Expose vm probes (today dtrace probes) to the erlang tracer.</div><div class=""> * Better integration of dtrace/lttngt/systemtap into the erlang trace.<br class=""></div><div class=""> * Allow the erlang tracer to be an Erlang callback module. Today only ports/processes are allowed.</div><div class=""> * Optimize trace output to file/ip. Maybe use something like the Common Trace Format (<a href="http://git.efficios.com/?p=ctf.git;a=blob_plain;f=common-trace-format-specification.md;hb=master" class="">http://git.efficios.com/?p=ctf.git;a=blob_plain;f=common-trace-format-specification.md;hb=master</a>), instead of the term_to_binary that we have today.</div><div class=""> * Write much much better documentation for dbg :)</div><div class=""><br class=""></div><div class="">We are looking for feedback from both beginners as well as seasoned veterans to make erlang tracing the best it can be. So if you have any thoughts or ideas, join the discussion to make Erlang tracing better for you and everyone else.</div><div class=""><br class=""></div><div class="">Thanks in advance,</div><div class="">Lukas</div><div class="">Erlang/OTP team</div></div>
_______________________________________________<br class="">erlang-questions mailing list<br class=""><a href="mailto:erlang-questions@erlang.org" class="">erlang-questions@erlang.org</a><br class="">http://erlang.org/mailman/listinfo/erlang-questions<br class=""></div></blockquote></div><br class=""><div apple-content-edited="true" class="">
Simon Thompson | Professor of Logic and Computation <br class="">School of Computing | University of Kent | Canterbury, CT2 7NF, UK<br class=""><a href="mailto:s.j.thompson@kent.ac.uk" class="">s.j.thompson@kent.ac.uk</a> | M +44 7986 085754 | W <a href="http://www.cs.kent.ac.uk/~sjt" class="">www.cs.kent.ac.uk/~sjt</a><br class=""><br class="">
</div>
<br class=""></div></body></html>