Open arkgil opened 4 years ago
Note on performance: as I read it, this library serializes fetching the UDP socket through a single genserver https://github.com/beam-telemetry/telemetry_metrics_statsd/blob/master/lib/telemetry_metrics_statsd/event_handler.ex#L113
Statix's tactic is to Process.register(conn.sock, __MODULE__)
so that the socket can be retrieved by the client processes without serializing. That's probably going to be a tactic this library wants to copy.
@benwilson512 you're right, that's what we're currently doing. Thanks for the suggestion! I'll look into it 👍
I wonder if it would be more beneficial to adjust Statix if needed to work nicer with telemetry instead of reimplementing? :bowtie:
@lexmag Initially I went for a new library due to different models that Telemetry.Metrics
and Statix assume. With Telemetry.Metrics you declare all of your metrics in one place, feed them to the reporter and that's it - they are updated whenever a corresponding telemetry event is fired. With Statix, you imperatively update a metric all around your codebase.
Since this project was the first Telemetry.Metrics reporter, it was simply easier and faster to implement it from scratch than try to find a way to integrate Statix with Telemetry.Metrics.
That said, there are parts of Statix that I'd love to see in this library as well. My only concern is if it's possible to merge the two without introducing confusion.
Can the library just translate calls from Metrics? Listening to metrics' events and firing Statix calls.
This is a tracking issue for items that need to be completed In order to make TelemetryMetricsStatsd a complete alternative to Statix.
The following features need to be added to achieve a feature parity:
Apart from that, we're gonna need:
decrement/..
,increment/..
)