[erlang-questions] Erlang tracing

[Lukas Larsson]

On Mon, Sep 21, 2015 at 10:08 PM, Simon Thompson <s.j.thompson@REDACTED>
wrote:

>
> I see that discussions have already aired filtering, and I think that the
> main lesson for me from RELEASE was it’s crucial to find ways to deal with
> torrents of potential data. It’s no good to generate trace info which is
> filtered out downstream: if it can be filtered at source, so only generated
> when required, then that would be great.
>

Filtering close to the source is indeed important. My hope is that if you
can implement the tracer as a nif, you can in the backend inspect the data
that is to be outputted without having to copy it anywhere and from there
make smarter decisions on what you actually want to trace on. We still need
match specs to do the initial filtering from erlang, but for those of us
having to deal with very specific tracing scenarios we could write a
specialized backend that takes care of the filtering. Unfortunately I have
not yet come up with a way to make the tracer backend be a pure erlang
module and still be fast.


> Another facility which may be problematic to implement, but which could be
> really helpful, would be mechanisms to aggregate information as part of the
> BEAM: e.g. to be able to emit a trace message every time 1000 messages have
> passed from process A to process B, or node A to node B. Again this would
> push into the infrastructure something that currently needs to be done in
> trace processing.
>

My hope is again that the more flexible nif tracer backends will help in
creating sampling profilers. If for instance you want to only trace the
stack of every 1000th call, you would just have a counter in the nif
backend and extract the stack only if you need it. There will of course be
some overhead, but it will be minuscule compared to what there is today.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150922/06a7977c/attachment.htm>