[erlang-questions] Erlang tracing

[Lukas Larsson]

On Mon, Sep 21, 2015 at 3:41 PM, Vlad Dumitrescu <vladdu55@REDACTED> wrote:

> 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).
>

Yes, they would be independent. I envision filtering being done as today,
i.e. through match specs that are run for when a trace pattern that has
been triggered. Each tracer would have it's own filter that has to be
executed before a decision is made whether a trace should be generated or
not, so having multiple tracers will be more expensive than one. Luckily it
is quite hard to write long match specs, so normally each filter is very
fast to be checked :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150921/9942789f/attachment.htm>