You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You aim to dynamically adjust the frequency and timing of chaos injection. For instance, in pre-production and test environments, it's sensible to consistently inject chaos. This proactive approach helps in preparing for potential failures. In production environments, however, you may prefer to limit chaos to certain users and tenants, ensuring that regular users remain unaffected. The chaos API offers the flexibility needed to manage these varying scenarios.
99
+
100
+
Additionally, you have the option to dynamically alter the injection rate and simulate extreme scenarios by setting the injection rate to *1.0 (100%)*. Exercise caution when applying this high rate, restricting it to a subset of tenants and users to avoid rendering the system unusable for regular users.
101
+
102
+
The following example illustrates how to configure chaos strategies accordingly:
// Enable chaos in development and staging environments.
115
+
if (environment.IsDevelopment() ||environment.IsStaging())
116
+
{
117
+
returnValueTask.FromResult(true);
118
+
}
119
+
120
+
// Enable chaos for specific users or tenants, even in production environments.
121
+
if (ShouldEnableChaos(args.Context))
122
+
{
123
+
returnValueTask.FromResult(true);
124
+
}
125
+
126
+
returnValueTask.FromResult(false);
127
+
},
128
+
InjectionRateGenerator=args=>
129
+
{
130
+
if (environment.IsStaging())
131
+
{
132
+
// 1% chance of failure on staging environments.
133
+
returnValueTask.FromResult(0.01);
134
+
}
135
+
136
+
if (environment.IsDevelopment())
137
+
{
138
+
// 5% chance of failure on development environments.
139
+
returnValueTask.FromResult(0.05);
140
+
}
141
+
142
+
// The context can carry information to help determine the injection rate.
143
+
// For instance, in production environments, you might have certain test users or tenants
144
+
// for whom you wish to inject chaos.
145
+
if (ResolveInjectionRate(args.Context, outdoubleinjectionRate))
146
+
{
147
+
returnValueTask.FromResult(injectionRate);
148
+
}
149
+
150
+
// No chaos on production environments.
151
+
returnValueTask.FromResult(0.0);
152
+
},
153
+
FaultGenerator=newFaultGenerator()
154
+
.AddException<TimeoutException>()
155
+
.AddException<HttpRequestException>()
156
+
});
157
+
});
158
+
```
159
+
<!-- endSnippet -->
160
+
161
+
We suggest encapsulating the chaos decisions and injection rate in a shared class, such as `IChaosManager`:
162
+
163
+
<!-- snippet: chaos-manager -->
164
+
```cs
165
+
publicinterfaceIChaosManager
166
+
{
167
+
boolIsChaosEnabled(ResilienceContextcontext);
168
+
169
+
doubleGetInjectionRate(ResilienceContextcontext);
170
+
}
171
+
```
172
+
<!-- endSnippet -->
173
+
174
+
This approach allows you to consistently apply and manage chaos-related settings across various chaos strategies by reusing `IChaosManager`. By centralizing the logic for enabling chaos and determining injection rates, you can ensure uniformity and ease of maintenance across your application and reuse it across multiple chaos strategies:
> An alternative method involves using [`Microsoft.Extensions.AsyncState`](https://www.nuget.org/packages/Microsoft.Extensions.AsyncState) for storing information relevant to chaos injection decisions. This can be particularly useful in frameworks like ASP.NET Core. For instance, you could implement a middleware that retrieves user information from `HttpContext`, assesses the user type, and then stores this data in `IAsyncContext<ChaosUser>`. Subsequently, `IChaosManager` can access `IAsyncContext<ChaosUser>` to retrieve this information. This approach eliminates the need to manually insert such data into `ResilienceContext` for each call within the resilience pipeline, thereby streamlining the process.
0 commit comments