<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, 21 Sep 2015 at 10:52 Lukas Larsson <<a href="mailto:lukas@erlang.org">lukas@erlang.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>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></blockquote><div><br></div><div>I've spent many hours trying to build "always on" instrumentation tools, that you can even run in busy production systems. The biggest challenge in Erlang compared to other languages / virtual machines is that it's more or less impossible to follow the execution of a request due to the "use processes for everything" designs many systems adopt. seq_trace has the potential to help with this without requiring changes to code, but falls on it's face as soon as a process talks to a port driver, which happens all the time in most systems.</div><div><br></div><div>If after calling gen_tcp:send/receive the seq_trace token is still around, it would be possible to build such an instrumentation tool.</div><div><br></div><div>If the seq_trace token could be transferred as part of a message to another node, that would be incredibly useful.</div><div><br></div><div>To give some context, New Relic provides agent libraries for many languages and relies on thread locals to trace typically a HTTP request as it calls different libraries, different databases, etc. This agent periodically sends aggregated data back to New Relic, which has a nice web app where you can view what is going on inside your systems.</div><div><br></div><div>Regards</div><div>Knut</div><div> <br></div></div></div>