Telemetría - telemetry convenient wrapper

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.

Hi @mudasobwa

I was just checking out Telemetria and it looks nice. But browsing through the documentation, I can’t seem to find how to configure open telemetry endpoints on where to send the data to?

Any changes of an example for this?

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/1 everywhere to make a result transformable
  • [UPD] OpenTelemetry support through backend abstraction
  • [UPD] locals: [:foo, :bar] to export local vars from functions
  • [UPD] Configurable throttling groups

It’s been a while. Three features and several bugfixes:

• 0.14.0 —
  • [ENH] Allow if: runtime_function in @telemetria attribute in the form &Mod.fun/1,
    which will receive the result and emit the telemetry event if it returns true
• 0.13.0 —
  • [ENH] Allow if: compile_time_boolean in @telemetria attribute
• 0.12.0 —
  • [ENH] Allow [transform: [args: M.f/1, result: {M, :f}]] coercers in @telemetria attribute

The above means @telemetria hooks can be optional both in compile time (purged from the resulting code) and runtime (no event if the condition is not met.)

@telemetria level: :info, if: Application.compile_env(:foo, :bar, true)
def foo, do: 42

Just blogged on why Telemetría, what is it, what is it not, how to use etc.

UPD

• 0.5.0 —
  • [ENH] annotation @telemetria true as a synonym to deft/2
  • [FIX] polling is off by default
• 0.4.0 —
  • [ENH] default polling of system / vm states for free
  • [ENH] starting in phases ensuring proper instrumenter setup
• 0.3.0 —
  • [ENH] no need for any config in any environment
  • [BUG] proper handling of guards in compiler, correct event names

The module attribute @telemetria accepts true only ATM, but it will be extended to accept additional context, levels and specific handler.

Thanks!

I thought about allowing to declare telemetry aspects through module attributes, but I frankly don’t see any reason to include decorators in the library itself. Whether one wants to use a decorator, or any other implementation of AOP, t/2 is already there, exported, and nothing can prevent from doing somewhat like

@decorator telemetria()
def my_fun, do: my_code

with a decorator delegating to t/2. SRP

OTOH, maybe you are right and I should think about optional support when decorators are already used in the target application.

Thank you, merged. Appreciate it.

Please feel free to open issues as they arise.

This is pretty cool, @mudasobwa! Thanks for sharing.

Thoughts on the decorator pattern for something like this?

@decorator telemetria # the decorator could be anything. t, track, emit, report, etc.
def my_function() do
  my code |> my other code
end

It’s a pattern I use regularly and makes code pretty easy-to-read. Spandex uses it too.

Code & docs.

Looks neat! Just submitted a PR to fix a couple typos, look forward to trying out!