We’ve just pushed Telemetry.Metrics 0.2.0 to Hex. Version 0.1.0 has been published for a while now, but this version finally makes the library compatible with Telemetry 0.4.0 and brings many other improvements.
In short, Telemetry.Metrics allows you to define how you wish the Telemetry events to be aggregated. For example, the following metric definition
sum("http.request.payload_size")
means that you want to sum up :payload_size measurement of the [:http, :request] Telemetry events.
Telemetry.Metrics doesn’t aggregate the metrics itself, rather it relies on reporters to subscribe to relevant events and aggregate the metrics in a way that makes the most sense for the monitoring system they report to.
I recommend checking out the docs since they contain way more information. Since this version we also have a guide for writing reporters
Big thank you to all the people involved in discussions around the design and ideas for improvement - we wouldn’t have made it without you
Out of interest, why use string specification instead of array of atoms? These would be equivalent in the idea, but would save on the parsing and restricting separators (for example OpenCensus often uses / to separate metric segments).
Another thing is whether this will be rewritten in Erlang (with possible Elixir wrapper) for allowing it to be used with rest of the community?
Out of interest, why use string specification instead of array of atoms? These would be equivalent in the idea, but would save on the parsing and restricting separators (for example OpenCensus often uses / to separate metric segments).
It’s just a matter of preference, I think that it just looks nicer. But you can use a list of atoms for both the metric and event name as well.
Another thing is whether this will be rewritten in Erlang (with possible Elixir wrapper) for allowing it to be used with rest of the community?
I personally believe that it should, you and other folks have done a lot of awesome work on opencensus stuff, which means we could have really solid integration without much effort, I suppose. Although I really wish we could generate nicer documentation from the Erlang source code
