Thoughts on replacing mocks with Telemetry events

[ruslandoga]

👋

Originally posted in DockYard/flame_on#48

---

Similar to the issue above, what if eflambe starts and stops tracing on telemetry events?

Since telemetry:execute and telemetry:span run in the caller process, we have access to the current pid, and we can use the new trace module with very minimal effort for flamegraphs. Flamecharts (which is what FlameOn is doing, and I guess eflambe as well?) would require extra effort. With trace we might also be able to cross process boundary and start tracing the processes that the current process "calls".

The API could be just a telemetry event for which to start tracing, and an optional event for when to stop tracing.

ref = make_ref()
# or something like :eflambe.trace_once([:phoenix, :endpoint, :start])
:telemetry.attach("trace-phx-on", [:phoenix, :endpoint, :start], &:eflambe.start_tracing/4, sample: 0.01, ref: ref)
:telemetry.detach("trace-phx-on")
:eflambe.svg(:eflambe.report(ref))

Context:

• https://www.erlang.org/doc/apps/tools/tprof.html -- uses trace, can be used as example to implement flamecharts with heap alloc stats
• https://www.erlang.org/doc/apps/kernel/trace.html

[ruslandoga]

Small PoC: #47 (comment)

[Stratus3D]

flame_on and eflambe are separate project. flame_on used to use eflambe, but no longer does.

Can you explain what the benefit to stopping and starting via telemetry would be? Why not just use eflambe:capture/3?

[ruslandoga]

👋 @Stratus3D

flame_on and eflambe are separate project.

I realize that. I thought they could both benefit from this idea so I opened this issue in both.

Can you explain what the benefit to stopping and starting via telemetry would be?

It allows removing mocking from production :)