Replacing statsd with ActiveSupport notifications #5512
Replies: 4 comments
-
Sidekiq Pro already has a metrics adapter so it could support Statsd and Dogstatsd. I wonder if we could create an ActiveSupport adapter… |
Beta Was this translation helpful? Give feedback.
-
As a concrete example in sidekiq-ent periodic there is a counter that is incremented when a job is enqueued like
If that logic was replaced so that the entire enqueue_job operation were wrapped in an ActiveSupport notification like
Not only could a statsd subscriber add statsd metrics in response to that event, but a prometheus subscriber could add entirely different types metrics for that operation (maybe someone wants a histogram instead of a counter). And those same notifications could be used to create something else entirely like open telemetry trace data in addition to metrics. Personally I would prefer a generic event system to hook into (with some optional out of the box subscribers provided by sidekiq-pro) instead of having native metrics hardcoded into the gems |
Beta Was this translation helpful? Give feedback.
-
https://twitter.com/getajobmike/status/1567531347539001344 Kinda lame that github doesn't support embedding tweets. |
Beta Was this translation helpful? Give feedback.
-
Statsd is the overwhelming industry choice. I’m happy to see Sidekiq-prometheus and hope it works well for you in the future but I’m not seeing any real need to change things. |
Beta Was this translation helpful? Give feedback.
-
We prefer to use prometheus' ruby sdk for application metrics rather than statsd. We leveraged fastly/sidekiq-prometheus as our starting point which implements a good baseline set of metrics via the server middleware. However, there are two problems with this approach.
Sidekiq pro and enterprise features that track metrics are expecting a statsd client, which means we have to provide an adapter that quacks enough like the statsd interface sidekiq pro/ent use but is actually is a prometheus client
The client middleware approach tries to use internals of the sidekiq gems for some features which are liable to break with no notice. Example the senate class was being used to capture additional global metrics but the api on that class was changed
I would suspect that we are not alone in preferring prometheus as a metrics solution. It would be nice to get first class support in the gem internals for ActiveSupport notifications so we could have a reliable event API to implement metrics against and is not limited to only job processing events like the middleware chain. (I would be interested in working on a draft PR for this feature if this is a vision you support)
Beta Was this translation helpful? Give feedback.
All reactions