[erlang-questions] Erlang tracing

[Vlad Dumitrescu]

Hi!

On Mon, Sep 21, 2015 at 12:02 PM, Ulf Wiger <ulf@REDACTED> wrote:

> On 21 Sep 2015, at 10:52, Lukas Larsson <lukas@REDACTED> wrote:
>
> 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 :)
>
>
> +1 on the suggestions, esp. multiple tracers. The one-tracer restriction
> makes it hard to explore some very interesting monitoring and debugging
> ideas.
>

Those are very good starting points.

For multiple tracers, I would assume that they will be independent - i.e.
not all of them get all tracing events, but only the ones they are
interested in. The question is if the tracing engine can be made fast
enough, possibly only if the filtering criteria are restricted to term
matching (as opposed to arbitrary predicates provided by users).

Also, it might be interesting to consider having the configuration in a
declarative format that is easier to understand and maintain, while also
allowing to keep the configuration separate from the code (in an external
file). It's not difficult to implement that on top the current API, but a
common and official format would feel a lot better.



> One might fantasize about enabling migration from io:format() debugging to
> this, ideally by simply rewriting the debug macro: a handy wrapper that
> simulates the original printouts. There are some problems with this, so
> I’ve chosen not to go there.
>

Ulf, could you please sketch the issues that you encountered?

best regards,
Vlad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150921/21c506cb/attachment.htm>