Introduce ResilienceStrategyBuilder.InstanceName
and use it in telemetry
#1392
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.
Details on the issue fix or feature implementation
The main purpose of
InstanceName
is to differentiate between multiple instances that have the sameBuilderName
. It defaults tonull
.Previously, we had the
strategy-key
dimension that was not easy to configure using the API. It was also ambiguous withstrategy-name
andstrategy-type
.Now, every resilience event has the following dimension that can identify by wich resilience strategy is was produced:
builder-name
: the name of the builder, when using theAddResilienceStrategy
extension this becomes the key identifierbuilder-instance
: the instance of the builder. Generally, it'snull
and consumer can set it up manually or configure theInstanceNameFormatter
delegate to fill it when using complex keys (Demonstrate how to create dynamic strategies with complex keys #1366).strategy-type
: hard-coded strategy type (Retry, Hedging, Timeout)strategy-name
: consumer can set it up to add more details to the telemetry. Defaults to null.As a part of this change I have also simplified the log messages to make them shorter.
Confirm the following