-
Notifications
You must be signed in to change notification settings - Fork 362
Description
Component
OpenTelemetry.Instrumentation.Hangfire
Is your feature request related to a problem?
I would like to contribute a PR here, but before starting i would like to start the discussion here.
The current metrics implementation uses quite a lot of statics and less DI.
I would especially like to configure/extend the StateMapping which currently only supports the default hangfire states, maybe with an own StateMapper implementation.
Also I would like to extend some metric tags with custom tags.
Due to the current implementation this is not possible to configure as in this case both implementations HangfireStateMapper and HangfireTagBuilder are static.
What is the expected behavior?
Changing the HangfireMetricsInstrumentation to be created from DI, instead of calling new
and also getting the HangFire metric filters from DI.
Making the HangfireStateMapper and HangfireTagBuilder non static, abstract (or interface) and TryAddSingleton DefaultHangfireStateMapper and DefaultHangfireTagBuilder into the service collection.
This would allow to either replace the default HangfireStateMapper and HangfireTagBuilder with Custom ones.
Or extending the default implementation by allowing them to consume custom tagger implementation(s) which will be called to extend the tags.
Which alternative solutions or features have you considered?
Custom hangfire filter with own metric.
Additional context
No response
Tip
React with π to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.