[Docs] Add telemetry section to chaos strategies documentation pages #2071
Conversation
|
I was playing with the Behavior Chaos and I've just realized if the var builder = new ResiliencePipelineBuilder<int>()
{
Name = "MyPipeline",
InstanceName = "MyPipelineInstance"
};
var pipeline = builder
.AddChaosBehavior(new ChaosBehaviorStrategyOptions()
{
InjectionRate = 1,
Enabled = true,
BehaviorGenerator = static args =>
{
Console.WriteLine("Custom Behavior Injected");
//throw new CustomException(); // uncomment to reproduce
return default;
},
OnBehaviorInjected = static args =>
{
Console.WriteLine("OnBehaviorInjected, Operation: {0}.", args.Context.OperationKey);
return default;
}
})
.ConfigureTelemetry(new TelemetryOptions
{
LoggerFactory = LoggerFactory.Create(builder => builder.AddConsole())
})
.Build();
ResilienceContext resilienceContext = ResilienceContextPool.Shared.Get("MyBehaviorInjectedOperation");
try
{
await pipeline.ExecuteAsync<int>(ctx => { return ValueTask.FromResult<int>(1); }, resilienceContext);
}
catch(Exception ex)
{
Console.WriteLine(ex.Message);
}
ResilienceContextPool.Shared.Return(resilienceContext);Dotnet fiddle link: https://dotnetfiddle.net/EaycSE The standard strategies do report telemetry even in a case of exception. They also call the Does this strategy behave differently intentional? cc: @martincostello , @martintmk |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2071 +/- ##
=======================================
Coverage 83.69% 83.69%
=======================================
Files 312 312
Lines 7114 7114
Branches 1054 1054
=======================================
Hits 5954 5954
Misses 789 789
Partials 371 371
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
I hope I do something really silly but for me the Outcome Chaos strategy does not seem to inject exception. var pipeline = new ResiliencePipelineBuilder<int>()
.AddChaosOutcome(new ChaosOutcomeStrategyOptions<int>()
{
InjectionRate = 1,
Enabled = true,
OutcomeGenerator = static args =>
{
//throw new Exception("A");
return ValueTask.FromResult<Outcome<int>?>(Outcome.FromException<int>(new Exception()));
},
//OutcomeGenerator = new OutcomeGenerator<int>().AddException<Exception>(),
})
.ConfigureTelemetry(new TelemetryOptions
{
LoggerFactory = LoggerFactory.Create(builder => builder.AddConsole())
})
.Build();
var resilienceContext = ResilienceContextPool.Shared.Get();
try
{
var result = await pipeline.ExecuteAsync<int>(ctx => { return ValueTask.FromResult<int>(1); }, resilienceContext);
//var result = await pipeline.ExecuteAsync<int>(ctx => { return ValueTask.FromException<int>(new CustomException()); }, resilienceContext);
result.Dump();
}
catch(Exception ex)
{
Console.WriteLine(ex.Message);
}
ResilienceContextPool.Shared.Return(resilienceContext);Then the output is Dotnet fiddle: https://dotnetfiddle.net/82Chpg cc: @vany0114 |
|
Based on my experience the What do you guys think? |
There was a problem hiding this comment.
I'm happy but let's see what @vany0114 thinks before merging.
|
Sorry for the delay here guys, will take a look as soon as I can. |
@peter-csala you're right! And I it is because of the way we're handling the outcome when it is an exception since originally the outome strategy wasn't designed to return an exception as an outcome, so instead it is returning the default value ot I added the OnOutcomeInjected delegate to the fiddle you shared and look at the results: We would need to do a change in the One caveat there that underscores this usage as an anti-pattern is that the telemetry event was registered as an empty result, instead of the exception, we could also do something like this before returning the exception to mitigate it: _telemetry.Report(new(ResilienceEventSeverity.Information, ChaosOutcomeConstants.OnOutcomeInjectedEvent), context, outcome.Value.Exception); |
@peter-csala Yep that's intended, if the generator throws an exception we're not handling that, we just let the exception to bubble up, I spot-checked a couple of Polly strategies and I couldn't see that they are handling errors in the generators and tracking those as telemetry events 🤔 can you please provide an example when you say that the standard strategies report telemetry even in a case of exception? |
|
I will create a dedicated discussion thread for each question just to keep the PR focused. I'll update this comment with the links: |
Here is an example in case of Fallback, both the telemetry is reported as well as the var pipeline = new ResiliencePipelineBuilder<int>()
.AddFallback(new FallbackStrategyOptions<int>
{
ShouldHandle = static args => PredicateResult.True(),
FallbackAction = static args => throw new Exception("Fallback boom"),
OnFallback = static args =>
{
Console.WriteLine("OnFallback is called");
return default;
}
})
.ConfigureTelemetry(new TelemetryOptions
{
LoggerFactory = LoggerFactory.Create(builder => builder.AddConsole())
})
.Build();
var resilienceContext = ResilienceContextPool.Shared.Get();
try
{
var result = await pipeline.ExecuteAsync<int>(ctx => { return ValueTask.FromResult<int>(1); }, resilienceContext);
result.Dump();
}
catch(Exception ex)
{
Console.WriteLine(ex.Message);
}
ResilienceContextPool.Shared.Return(resilienceContext); |
|
@vany0114 Are you fine with this documentation PR? |
| --- | ||
|
|
||
| > [!IMPORTANT] | ||
| > Please note that if the calculated latency is negative (regardless if it's fixed or dynamic) then it will not be injected. |
Pull Request
The issue or feature being addressed
Follow up of the following PRs:
Details on the issue fix or feature implementation
Confirm the following