mudasobwa
Telemetría - telemetry convenient wrapper
I am glad to announce the first Telemetria release. telemetria v0.22.1 — Documentation
It takes care of event registration (through compilation manifest), runtime and release configs (through config provider), and basically allows to wrap any expressions and/or functions to “telemetryized” calls.
If you hesitated to add telemetry to your project, it’s a great time. Example from docs:
defmodule MyMod do
import Telemetria
defpt pi, do: 3.14
deft answer, do: 42 - pi()
def inner do
short_result = t(42 * 42)
result =
t do
# long calculations
:ok
end
end
end
Enjoy. Mode details are in the linked above docs. Feedback is very welcome, as always.
Most Liked
mudasobwa
Just blogged on why Telemetría, what is it, what is it not, how to use etc.
mudasobwa
It’s been another while.
Telemetría became a backend agnostic (telemetry and opentelemetry are supported out of the box, custom backends might be added.) It also supports sending a desired events to “messengers” like slack. Also, local variables can now be effortlessly propagated to the emitted events.
0.22.0—- [UPD] support for external messengers (slack)
- [UPD] support for nested spans in open telemetry
- [UPD]
reshape/1everywhere to make a result transformable - [UPD]
OpenTelemetrysupport through backend abstraction - [UPD]
locals: [:foo, :bar]to export local vars from functions - [UPD] Configurable throttling groups
mudasobwa
Being a wrapper, telemetría itself has nothing to do with OTel, there is an example within the project, and it’s config is here: telemetria/examples/otel/config/config.exs at v0.24.0 · am-kantox/telemetria · GitHub
Once you have OTel configured, telemetría should just work.
Please let me know if that helped and don’t hesitate to create issues directly on GH if in doubt.
mudasobwa
OK, I will try.
deft/2 and defpt/2 are simply wrappers for Kernel.def/2 and Kernel.defp/2 respectively. They are somewhat similar to AOP around aspect, mesauring the time spent in the function itself and sending the telemetry event.
t/2 does the same for anonymous functions and expressions. The latter also allows to pass context as the second parameter to be attached to the event.
Events automatically get the names based on modules / functions (configurable) and the events are registered within :telemetry automagically by a compiler.
In general, it allows to have zero boilerplate when working with complicated/huge set of :telemetry events.
I hope it became a bit clearer.
mudasobwa
Thanks, fixed!
Sounds reasonable. I’d love to collect more opinions, but atm I think that’s the way to go.
Basically one might configure functions that would be excluded from wrapping into :telemetry despite they are still declared with deft/defpt with zero overhead (compile-time purge.)
I honestly thought :telemetry is something like Jason nowadays, everyone should have at least read about; Phoenix docs mention it, Ecto docs do, etc.
I will try to add a couple of sentences, but I definitely want to avoid being DHH here. If one have never heard about :telemetry, they probably should have started with :telemetry itself to understand how it works in a nutshell, and only then come for libraries hiding the boilerplate.
:telemetry is a side effect. Both would behave exactly as def/2 and defp/2 from the consumer point of view. Only side effect of sending :telemetry events would happen under the hood.
Popular in Libraries
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Catch errors, track performance, monitor hosts and more.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
Enabling companies to succeed by building software people love.
Courses that'll move you from confusion to "Aha, now I get it!"