Introduce support for connection instrumentation #3864
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit adds functionality that allows to add a relatively fine instrumentation to our connection types by providing an essentially call back based pattern for instrumentation. The implemented setup calls the provided instrumentation type with different events. This allows the instrumentation to decide on it's own which events are important and which are unimportant. It also enables to skip most of the work (like constructing the sql of an inspected query) if the event is not handled as we just pass down an opaque wrapper that can be evaluated by the instrumentation implementation. This commit includes: * A default instrumentation implementation that does nothing * A global way to set the instrumentation implementation used by new connections * A connection specific setter to change the instrumentation implementation for a specific connection * A wild card instrumentation implementation for closures that accept the event type This commit does not include any "advanced" instrumentation implementations (based on `log` or `tracing`, etc). The idea is that these live in their own crates as it is might depend on the actual use case how the different events should be handled. The implementation of `InstrumentationEvent` is decoupled form specific backend types to allow reusing the same instrumentation for different connection types. The definition of `Instrumentation` does not depend on any connection specific stuff so that it is possible to use the same implementation for `diesel-async` as well.
weiznich
added
the
run-benchmarks
weiznich
added
run-benchmarks
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit adds functionality that allows to add a relatively fine instrumentation to our connection types by providing an essentially call back based pattern for instrumentation. The implemented setup calls the provided instrumentation type with different events. This allows the instrumentation to decide on it's own which events are important and which are unimportant. It also enables to skip most of the work (like constructing the sql of an inspected query) if the event is not handled as we just pass down an opaque wrapper that can be evaluated by the instrumentation implementation.
This commit includes:
This commit does not include any "advanced" instrumentation implementations (based on
logortracing, etc). The idea is that these live in their own crates as it is might depend on the actual use case how the different events should be handled.The implementation of
InstrumentationEventis decoupled form specific backend types to allow reusing the same instrumentation for different connection types. The definition ofInstrumentationdoes not depend on any connection specific stuff so that it is possible to use the same implementation fordiesel-asyncas well.This is currently marked as draft as there are some details that needs to be resolved for the row by row based postgres connection implementation. I decided to open this PR anyway to gather some feedback on the design.