telemetry
allows you to invoke certain functions whenever a
particular event is emitted.
telemetry
allows you to invoke certain functions whenever a
particular event is emitted.
attach/4
, attach_many/4
and execute/2
.
event_measurements() = map()
event_metadata() = map()
event_name() = [atom(), ...]
event_prefix() = [atom()]
event_value() = number()
handler() = #{id := handler_id(), event_name := event_name(), function := handler_function(), config := handler_config()}
handler_config() = term()
handler_function() = fun((event_name(), event_measurements(), event_metadata(), handler_config()) -> any())
handler_id() = term()
span_function() = fun(() -> {span_result(), event_metadata()})
span_result() = term()
attach/4 | Attaches the handler to the event. |
attach_many/4 | Attaches the handler to many events. |
detach/1 | Removes the existing handler. |
execute/2 | Equivalent to execute(EventName, Measurements, #{}). |
execute/3 | Emits the event, invoking handlers attached to it. |
list_handlers/1 | Returns all handlers attached to events with given prefix. |
span/3 | Emit start, and stop/exception events, invoking the handlers attached to each. |
attach(HandlerId, EventName, Function, Config) -> ok | {error, already_exists}
Attaches the handler to the event.
handler_id
must be unique, if another handler with the same ID already exists the
{error, already_exists}
tuple is returned.
See execute/3
to learn how the handlers are invoked.
Note: due to how anonymous functions are implemented in the Erlang VM, it is best to use
function captures (i.e. fun mod:fun/4
in Erlang or &Mod.fun/4
in Elixir) as event handlers
to achieve maximum performance. In other words, avoid using literal anonymous functions
(fun(...) -> ... end
or fn ... -> ... end
) or local function captures (fun handle_event/4
or &handle_event/4
) as event handlers.
attach_many(HandlerId, EventNames::[EventName], Function, Config) -> ok | {error, already_exists}
Attaches the handler to many events.
The handler will be invoked whenever any of the events in the event_names
list is emitted. Note
that failure of the handler on any of these invocations will detach it from all the events in
event_name
(the same applies to manual detaching using detach/1
).
Note: due to how anonymous functions are implemented in the Erlang VM, it is best to use
function captures (i.e. fun mod:fun/4
in Erlang or &Mod.fun/4
in Elixir) as event handlers
to achieve maximum performance. In other words, avoid using literal anonymous functions
(fun(...) -> ... end
or fn ... -> ... end
) or local function captures (fun handle_event/4
or &handle_event/4
) as event handlers.
detach(HandlerId::handler_id()) -> ok | {error, not_found}
Removes the existing handler.
If the handler with given ID doesn't exist,{error, not_found}
is returned.
execute(EventName, Measurements) -> ok
Equivalent to execute(EventName, Measurements, #{}).
execute(EventName, Measurements, Metadata) -> ok
Emits the event, invoking handlers attached to it.
When the event is emitted, the handler function provided toattach/4
is called with four
arguments:
attach/4
While you are able to emit messages of any event_name
structure, it is recommended that you follow the
the guidelines laid out in span/3
if you are capturing start/stop events.
list_handlers(EventPrefix::event_prefix()) -> [handler()]
Returns all handlers attached to events with given prefix.
Handlers attached to many events at once usingattach_many/4
will be listed once for each
event they're attached to.
Note that you can list all handlers by feeding this function an empty list.
span(EventPrefix::event_prefix(), StartMetadata::event_metadata(), SpanFunction::span_function()) -> span_result()
Emit start, and stop/exception events, invoking the handlers attached to each.
When this function is called, 2 events will be emitted viaexecute/3
. Those events will be one of the following
pairs:
EventPrefix ++ [start]
and EventPrefix ++ [stop]
EventPrefix ++ [start]
and EventPrefix ++ [exception]
However, note that in case the current processes crashes due to an exit signal of another process, then none or only part of those events would be emitted. Below is a breakdown of the measurements and metadata associated with each individual event.
A default span context is added to event metadata under thetelemetry_span_context` key if none is provided by
the user in the `StartMetadata`. This context is useful for tracing libraries to identify unique
executions of span events within a process to match start, stop, and exception events. Users
should ensure this value is unique within the context of a process at a minimum if overriding this key and
that the same value is provided to both `StartMetadata` and `StopMetadata`.
For `telemetry
events denoting the start of a larger event, the following data is provided:
EventPrefix ++ [start]
#{ % The current system time in native units from % calling: erlang:system_time() system_time => integer() }
#{ telemetry_span_context => term(), % User defined metadata ... }
telemetry
events denoting the stop of a larger event, the following data is provided:
EventPrefix ++ [stop]
#{ % The current monotonic time minus the start monotonic time in native units % by calling: erlang:monotonic_time() - start_monotonic_time duration => integer() }
#{ % An optional error field if the stop event is the result of an error % but not necessarily an exception. Additional user defined metadata can % also be added here. error => term(), telemetry_span_context => term(), ... }
telemetry
events denoting an exception of a larger event, the following data is provided:
EventPrefix ++ [exception]
#{ % The current monotonic time minus the start monotonic time in native units % derived by calling: erlang:monotonic_time() - start_monotonic_time duration => integer() }
#{ kind => throw | error | exit, reason => term(), stacktrace => list(), telemetry_span_context => term(), % User defined metadata from the start event ... }
Generated by EDoc