[erlang-questions] Erlang tracing

[Garrett Smith]

My wish for tracing in Erlang is that it be dead simple to use. Maybe
this has changed or my impression is just wrong, but I've found the
tracing facilities to be quite complex to jump in with.

e2 has e2_debug, which I use all the time:

https://github.com/gar1t/e2/blob/master/src/e2_debug.erl

This simplifies the interface to tracing (at least it's suitable for
my general needs) and cleans up the output (IMO).

I really like redbug's ability to install a trace for a period of time
and automatically remove it. redbug is a damn nice tool that's seen
heavy production use (from what I understand). It could perhaps serve
as a point of inspiration.

On Mon, Sep 21, 2015 at 3: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
>