More granular config for assaults

[jonatan-ivanov]

I would like to configure assaults in a more granular way. I guess the rabbit hole is deep but here are a few examples:

• Being able to set different level for the latency and the exceptions assault
• Being able to set different watchers for the latency and the exceptions assault (e.g.: componentA has latency-only, componentB exceptions-only and componentC both)
• I would like to set different behavior (or multiple behaviors) for the exceptions assault for different components (e.g.: componentA throws exceptionA, componentB throws exceptionB)
• I would like to set different behavior (or multiple behaviors) for the latency assault for different components (e.g.: componentA: level=100, range=100-500; componentB: level=1000, range=1000-5000; componentC: level=100, range=100-500 and level=1000, range=1000-5000)

My exact real-world use-case is simulating a latency behavior which is closer to reality. Randomly picking a value from a range and sleeping is challenging for simulating a scenario when smaller slowdowns occur more frequently and bigger slowdowns occur less frequently. E.g.: something like this:

if (Math.random() < 0.001) { // larger latency, less frequent
    Thread.sleep(1_000);
}
else if (Math.random() < 0.01) { // smaller latency, more frequent
    Thread.sleep(100);
}

[F43nd1r]

This would need bigger structural changes, so not sure if it'll actually happen, but I'm just dumping some thoughts on configuration here:

Simpler solution would be to provide overrides for specific beans like this:

chaos.monkey.override.beans:
  "de.codecentric.HelloBean.sayHello":
    level: 3
    latency-active: true

However, to solve all cases mentioned in OP we'd need to allow multiple of these configurations to be active at the same time, something like this

chaos.monkey.configure.beans:
  - name: de.codecentric.HelloBean.sayHello
    level: 3
    latency-active: true
  - name: de.codecentric.HelloBean.sayHello
    level: 5
    exceptions-active: true

which then means order matters because youd probably want latency to happen before exception etc. Also this makes the implementation of ChaosMonkeyRequestScope hard.

[F43nd1r]

We've decided to not go for a generally more flexible configuration for two reasons:

• performance concerns: more complex config means more complex checks on every method call
• the configuration I envisioned is too complex for both spring-boot-configuration-processor and intelliJ autocomplete. Losing config IDE support would be a downgrade for all users.

Instead #324 opens up the determineLatency method in LatencyAssault for you to override with your own implementation to solve your real-world use-case specifically.