Telemetry - Dynamic dispatching library for metrics and instrumentations (v0.3.0 released!)

arkgil

Hi all!

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!

This version is not compatible with the previous versions, below you will find the description of how to move from 0.2.0 to 0.3.0.

For those who publish

The only change in how the events are emitted is the module name:

# 0.2.0
Telemetry.execute([:my, :event], 20, %{some: :metadata})

# 0.3.0
:telemetry.execute([:my, :event], 20, %{some: :metadata})

For those who subscribe

The attach and attach_many have been changed a bit - now they accept an anonymous function as the handler function instead of a module/function pair.

# 0.2.0
Telemetry.attach("my-handler", [:my, :event], EventHandler, :handle, %{some: :config})

# 0.3.0
:telemetry.attach("my-handler", [:my, :event], &EventHandler.handle/4, %{some: :config})

To see all the changes please check out the change log.

Credits

Many thanks to @tristan for all of his help on the rewrite We wouldn’t have made it in 2018 without him

Also, a big thank you to all people supporting and using the project, asking questions and submitting feedback!

Feedback

Please let us know what you think about the release here or on the issue tracker.

Links

25 comments

#library #telemetry

19 5663 25

2019-10-06 11:24:33 UTC

Showing Posts 1 to 10

Show Best Posts
Show All (oldest first)
Show All (newest first)

tristan

Rebar3 Core Team

You should send this out to the Erlang mailing list as well

Post #1

blatyo

Conduit Core Team

What is necessary for this to become 1.0.0?

Post #2

hauleth

Polishing the edges, finding “the best API for the job” and overall live-code testing I believe.

Post #3

arkgil

To add to what @hauleth said, marking 1.0.0 means that we’re sure there will be no breaking changes for a while. To do that, we need to know if the API suits the use cases we had in mind and those we didn’t predict. For that, we need feedback - if you have any suggestions, or you have found any problems, please open up an issue on Github

Unfortunately, I don’t think I can give you more specific answer at the moment.

Post #4

jsm

Hi there! I’ve recently started to add monitoring support (with Prometheus and Grafana) to my Phoenix application. I stumbled accross your Telemetry project and also Prometheus Elixir by @deadtrickster. It is not entirely clear to me, however, how the two libraries complement one another, although I vaguely sense that they do

Specifically, when I use Prometheus.ex, isn’t it already possible to add custom metrics? Which is kind of what Telemetry is for as well? Or is it for example possible to achieve better decoupling by using Telemetry “backed” by Prometheus.Ex, so that it is simpler to swap out Prometheus for another monitoring solution? I would appreciate it if you could help me understand the two libraries’ specific purpose a bit better

Post #5

arkgil

@jsm great question! And you’re right, Prometheus.ex lets you define all the custom metrics you want. However, Telemetry tries to achieve another objective.

The goal of Telemetry project is to have a single interface for exposing instrumentation data across the whole ecosystem. Libraries can publish events with this data, and you can subscribe to them and build metrics using these values.

For example, Ecto already uses Telemetry to publish an event on each query. You could subscribe to this event and bump the Prometheus metric without having to instrument every database query yourself. Soon Telemetry events will be also published by Plug and Phoenix.

Today we’ve also released another project, Telemetry.Metrics, which provides a common interface for metric aggregations, like counters, sums, etc. If libraries like Prometheus.ex would integrate with it, setting up metrics which are based on Telemetry events will be even more simple.

Note that neither Telemetry nor Telemetry.Metrics is able to export metrics to external systems. You will always need a library like Prometheus.ex to translate the events to some useful representation

Post #6

deadtrickster

As I understand it - I instrumented Ecto via Logger, I instrumented Phoenix via instrumenter. Now when they integrated with Telemetry, I work with the same interface and concepts for both Ecto and Phoenix. This is true for all other libs utilizing Telemetry. In a way, it’s a “hooks” library, just with more defined domain. But having “real” counters/exposition still required.

For your own projects, Telemetry abstraction will help when you decide to switch to other monitoring system.

@arkgil please confirm

Post #7