Hi folks!

We have just released Telemetry 0.4.0. With this version, Telemetry events now carry a map of measurements instead of a single measurement. This is useful in cases when there are multiple values describing what just happened, e.g. in case of HTTP request the event might include decompression time, payload size, and processing time:

:telemetry.execute(
  [:http, :request],
  %{payload_size: 12874, processing_time: 120, decompression_time: 5},
  %{status: 200, path: "/..."}
)

Previously, each measurement needed to be emitted in a dedicated event. Now the event tells that a thing happened, and measurements and metadata describe its properties.

This change is backwards-compatible for event publishers, i.e. you can still call :telemetry.execute/3 with a single value. However, event handlers need to handle a map of measurements now.

Last but not least, thanks for the awesome feedback from the community which lead to this release!

Hey, I’ve just implemented InfluxDB reporter for Telemetry:

True, and I do see the appeal of wanting to something for “free” if the information is already there in some form.

But keep in mind how much influence you’ll have with the Elixir community with this library and the documentation around it. And since it is mostly new, not something existing in people’s code they can simply tap into today but will instead be instrumenting in the future, it can start for the “right place”. Meaning instead of creating spans have a lib for annotating spans through different libs like opencensus/ex_ray/etc, and documentation for Telemetry explaining how its events can be used to annotate spans in a distributed trace.

Because of the influence on the community to come from a library with backing like telemetry has this will help guide people to checkout distributed tracing solutions.

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

@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