<div dir="ltr">Hi Lukas,<div><br></div><div>One common use case for tracing I would like is the ability to trace a function call for just the next request in the system.</div><div><br></div><div>Currently the PidSpec in erlang:trace/3 allows for pid, existing, new or all.</div><div><br></div><div>We would use pid if we knew the pid of the next short lived process to call a function (but we don't).</div><div>We cannot use new either as tracing a function call for all new processes might mean that this function is traced 1000s times per second. </div><div><br></div><div>What I would like is some new PidSpec like 'next_pid' which would specify that I want to trace all new processes until the function call I am tracing has been triggered. Once the trace is triggered then it should turn off tracing on all processes.</div><div><br></div><div>e.g.</div><div>dbg:p(next_pid, call).</div><div>dbg:tp(M, F, x).</div><div><br></div><div>This would be a great help in my work where quite often I want to see the typical format of a request from a client and just capturing 1 request is enough. I believe that libraries such as redbug have this kind of ability, but perhaps the feature is fundamental enough to include as part of trace ?</div><div><br></div><div>Thanks for considering</div><div>Philip</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 23, 2015 at 4:42 PM, ILYA Khlopotov <span dir="ltr"><<a href="mailto:ilya.khlopotov@gmail.com" target="_blank">ilya.khlopotov@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><div><div><div><div><div><div><div><div><div><div>+1 for multiple independent tracers.<br><br></div>It would be also very helpful to support following:<br></div>1. Cluster avare seq_trace. Currently trace token is not send over erlang distribution protocol. It could be solved if new control message is added to distribution protocol for example. <br></div>2. There are a lot of different formats for trace messages and any tracing library need to be able to understand all of them. Almost any tracing librbary has to do something like:<br><a href="https://github.com/erlang/otp/blob/a2670f0822fc6729df956c8ec8c381340ff0a5fb/lib/et/src/et_selector.erl#L218" target="_blank">https://github.com/erlang/otp/blob/a2670f0822fc6729df956c8ec8c381340ff0a5fb/lib/et/src/et_selector.erl#L218</a><br><a href="https://github.com/erlang/otp/blob/a2670f0822fc6729df956c8ec8c381340ff0a5fb/lib/et/src/et_selector.erl#L268" target="_blank">https://github.com/erlang/otp/blob/a2670f0822fc6729df956c8ec8c381340ff0a5fb/lib/et/src/et_selector.erl#L268</a><br><a href="https://github.com/erlang/otp/blob/a2670f0822fc6729df956c8ec8c381340ff0a5fb/lib/runtime_tools/src/dbg.erl#L942" target="_blank">https://github.com/erlang/otp/blob/a2670f0822fc6729df956c8ec8c381340ff0a5fb/lib/runtime_tools/src/dbg.erl#L942</a><br><a href="https://github.com/ferd/recon/blob/master/src/recon_trace.erl#L482" target="_blank">https://github.com/ferd/recon/blob/master/src/recon_trace.erl#L482</a><br></div><div>It is problematic though since tuples are of different size.<br></div>Would it be better to send this info as an erlang record which anyone could import and use? It could be two records as well. Since every trace message has a meta info which describes where and what happend and list of arguments of the message. I.e. something like<br></div>meta: {<br></div> pid,<br></div> ts,<br></div> type,<br></div> serial,<br></div> ctx<br></div><div><div><div><div><div><div>}<br><div><br></div><div>event: {<br></div><div> meta :: #meta{},<br></div><div> args :: [],<br></div><div> sequence = 0<br></div><div>}<br></div><div><br>3. For seq_trace in particular it could be useful to be able to inject some context into the tracing process. Consider following use case. Let's say we have a notion of sessions. First user logins in order to start session, then he issues some commands using session_cookie as a mean to prove his identity. Since calls to login and command are independent http requests there is no way to link them together. We could have following:<br></div><div>maybe_trace_login(_User, _Cookie) -> <br> ok. %% function we use for dbg:fun2ms<br></div><div>login(User, Password) -><br></div><div> %% check password raise if it is invalid <br></div><div> Cookie = ...,<br></div><div> maybe_trace_login(User, Cookie),<br> ...<br></div><div>command(Cookie, Command, Args) -><br></div><div> %% check Cookie raise if unknown<br></div><div> do_command(Command, Args), %% we want to get trace of this<br> ...<br></div><div>However if we could store {User, Cookie} in the context of a tracer process from match spec. <br>We could produce nice trace messages for calls to command which would include user name. <div>This is the reason why ctx field is added in #meta{}. <br></div>We also would need to be able to initiate tracing of command when cookie match somehow.<br><br></div><div>BR,<br></div><div>ILYA<br></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Mon, Sep 21, 2015 at 1:52 AM, Lukas Larsson <span dir="ltr"><<a href="mailto:lukas@erlang.org" target="_blank">lukas@erlang.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Hello everyone.<div><br></div><div>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><br></div><div>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><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><br></div><div>To start the discussion, here are a few of my ideas in no particular order:</div><div> * Allow multiple tracers. Today only one port/process can be the receiver of trace data.</div><div> * 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> * Expose vm probes (today dtrace probes) to the erlang tracer.</div><div> * Better integration of dtrace/lttngt/systemtap into the erlang trace.<br></div><div> * Allow the erlang tracer to be an Erlang callback module. Today only ports/processes are allowed.</div><div> * 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" target="_blank">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> * Write much much better documentation for dbg :)</div><div><br></div><div>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><br></div><div>Thanks in advance,</div><div>Lukas</div><div>Erlang/OTP team</div></div>
<br></div></div><span class="">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">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></span></blockquote></div><br></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></div>