Telemetry v0.3.0

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Telemetry v0.3.0

arkadiusz
Hello,

I’m happy to announce that Telemetry v0.3.0 is out! This release marks the conversion from Elixir to Erlang so that all the libraries and projects on the BEAM can expose useful instrumentation data via Telemetry events.

If you wish to learn more about Telemetry, see the README on GitHub (https://github.com/beam-telemetry/telemetry) or documentation on hexdocs (https://hexdocs.pm/telemetry/index.html), or just ask in this thread.

Many thanks to Tristan Sloughter for his work on the rewrite.

Arkadiusz

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Telemetry v0.3.0

Jay Nelson-2
I’m curious how this is different from gen_event (http://erlang.org/doc/man/gen_event.html) and how you deal with the need to supervise restart of failed handlers. I guess one big difference is that you crash the caller on the first handler error, skipping the remaining ones, whereas gen_event shields the caller and removes the callback on first failure. gen_event allows both asynchronous and synchronous notifications, and also the benefit of using the sys tools and debug that gen_event brings, plus the ability of handlers to invoke hibernate to save memory under specific circumstances.

I’m not sure at what point using ets over an in memory gen state is worthwhile in terms of number of callbacks. I assume that is the main point, but I’m guessing it would take 10K to 100K before it was noticeable during garbage collection. Adding handlers is bottlenecked on the gen_server the same as gen_event, so maybe there is a speedup when looking up a handler (although duplicate_bag may not be super fast depending on the key distribution).

Under what circumstances did gen_event fall short, and what benefits does telemetry offer over it? Is this for many, many notifications for each event, or for many, many different event types? I can see how gen_event can get clogged up with many pending callbacks, whereas telemetry relies on the concurrency of the existing processes. So maybe backpressure is the biggest benefit overall.

jay


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Telemetry v0.3.0

Tristan Sloughter-4
The plan for detaching on failure is to trigger an event that can be handled.

It is for many different event types. Maybe some of those will be handled by something that makes use of gen_event to manage the event, but for the general case of essentially hooking into many dynamically defined events it makes more sense to not require them all to be going through another process. The individual handlers themselves can then pass off to a process to serialize through if that handler requires it.

Tristan

On Tue, Jan 1, 2019, at 11:58, Jay Nelson wrote:
I’m curious how this is different from gen_event (http://erlang.org/doc/man/gen_event.html) and how you deal with the need to supervise restart of failed handlers. I guess one big difference is that you crash the caller on the first handler error, skipping the remaining ones, whereas gen_event shields the caller and removes the callback on first failure. gen_event allows both asynchronous and synchronous notifications, and also the benefit of using the sys tools and debug that gen_event brings, plus the ability of handlers to invoke hibernate to save memory under specific circumstances.

I’m not sure at what point using ets over an in memory gen state is worthwhile in terms of number of callbacks. I assume that is the main point, but I’m guessing it would take 10K to 100K before it was noticeable during garbage collection. Adding handlers is bottlenecked on the gen_server the same as gen_event, so maybe there is a speedup when looking up a handler (although duplicate_bag may not be super fast depending on the key distribution).

Under what circumstances did gen_event fall short, and what benefits does telemetry offer over it? Is this for many, many notifications for each event, or for many, many different event types? I can see how gen_event can get clogged up with many pending callbacks, whereas telemetry relies on the concurrency of the existing processes. So maybe backpressure is the biggest benefit overall.

jay

_______________________________________________
erlang-questions mailing list
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions