[erlang-questions] Erlang tracing

[Philip Clarke]

Hi Lukas,

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.

Currently the PidSpec in erlang:trace/3 allows for pid, existing, new or
all.

We would use pid if we knew the pid of the next short lived process to call
a function (but we don't).
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.

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.

e.g.
dbg:p(next_pid, call).
dbg:tp(M, F, x).

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 ?

Thanks for considering
Philip

On Wed, Sep 23, 2015 at 4:42 PM, ILYA Khlopotov <ilya.khlopotov@REDACTED>
wrote:

> +1 for multiple independent tracers.
>
> It would be also very helpful to support following:
> 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.
> 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:
>
> https://github.com/erlang/otp/blob/a2670f0822fc6729df956c8ec8c381340ff0a5fb/lib/et/src/et_selector.erl#L218
>
> https://github.com/erlang/otp/blob/a2670f0822fc6729df956c8ec8c381340ff0a5fb/lib/et/src/et_selector.erl#L268
>
> https://github.com/erlang/otp/blob/a2670f0822fc6729df956c8ec8c381340ff0a5fb/lib/runtime_tools/src/dbg.erl#L942
> https://github.com/ferd/recon/blob/master/src/recon_trace.erl#L482
> It is problematic though since tuples are of different size.
> 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
> meta: {
>    pid,
>    ts,
>    type,
>    serial,
>    ctx
> }
>
> event: {
>    meta :: #meta{},
>    args :: [],
>    sequence = 0
> }
>
> 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:
> maybe_trace_login(_User, _Cookie) ->
>     ok. %% function we use for dbg:fun2ms
> login(User, Password) ->
>    %% check password raise if it is invalid
>    Cookie = ...,
>    maybe_trace_login(User, Cookie),
>    ...
> command(Cookie, Command, Args) ->
>    %% check Cookie raise if unknown
>    do_command(Command, Args), %% we want to get trace of this
>    ...
> However if we could store {User, Cookie} in the context of a tracer
> process from match spec.
> We could produce nice trace messages for calls to command which would
> include user name.
> This is the reason why ctx field is added in #meta{}.
> We also would need to be able to initiate tracing of command when cookie
> match somehow.
>
> BR,
> ILYA
>
> On Mon, Sep 21, 2015 at 1:52 AM, Lukas Larsson <lukas@REDACTED> wrote:
>
>> Hello everyone.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> To start the discussion, here are a few of my ideas in no particular
>> order:
>>   * Allow multiple tracers. Today only one port/process can be the
>> receiver of trace data.
>>   * 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.
>>   * Expose vm probes (today dtrace probes) to the erlang tracer.
>>   * Better integration of dtrace/lttngt/systemtap into the erlang trace.
>>   * Allow the erlang tracer to be an Erlang callback module. Today only
>> ports/processes are allowed.
>>   * Optimize trace output to file/ip. Maybe use something like the Common
>> Trace Format (
>> http://git.efficios.com/?p=ctf.git;a=blob_plain;f=common-trace-format-specification.md;hb=master),
>> instead of the term_to_binary that we have today.
>>   * Write much much better documentation for dbg :)
>>
>> 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.
>>
>> Thanks in advance,
>> Lukas
>> Erlang/OTP team
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150924/d59fcaa1/attachment.htm>