Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Statix feature-parity #24

Open
1 of 4 tasks
arkgil opened this issue Dec 25, 2019 · 5 comments
Open
1 of 4 tasks

Statix feature-parity #24

arkgil opened this issue Dec 25, 2019 · 5 comments
Milestone

Comments

@arkgil
Copy link
Collaborator

arkgil commented Dec 25, 2019

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:

  • measurement sampling (can be configured per-metric with addition of reporter options to Telemetry.Metrics Implement reporter options telemetry_metrics#52)
  • a non-standard (as in not included in Telemetry.Metrics) "set" metric, although I'd personally prefer to somehow gague interest in this one before adding it

Apart from that, we're gonna need:

  • documentation describing the transition (especially because Statix provides functions for relatively changing counters, i.e. decrement/.., increment/.. )
  • possibly a benchmark comparing the performance of two libraries
@benwilson512
Copy link

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.

@arkgil
Copy link
Collaborator Author

arkgil commented Jan 19, 2020

@benwilson512 you're right, that's what we're currently doing. Thanks for the suggestion! I'll look into it 👍

@arkgil arkgil added this to the 0.4.0 milestone Feb 13, 2020
@lexmag
Copy link

lexmag commented Mar 9, 2020

I wonder if it would be more beneficial to adjust Statix if needed to work nicer with telemetry instead of reimplementing? :bowtie:

@arkgil
Copy link
Collaborator Author

arkgil commented May 13, 2020

@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.

@thousandsofthem
Copy link

Can the library just translate calls from Metrics? Listening to metrics' events and firing Statix calls.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants