From bdf208509961e39bcdf3901ca79c7779884075cf Mon Sep 17 00:00:00 2001 From: Luiz Aoqui Date: Wed, 30 Nov 2022 10:56:16 -0500 Subject: [PATCH] docs: clarify autoscaling factor and threshold for target-value plugin (#15418) --- .../plugins/strategy/target-value.mdx | 44 +++++++++++++++---- 1 file changed, 35 insertions(+), 9 deletions(-) diff --git a/website/content/tools/autoscaling/plugins/strategy/target-value.mdx b/website/content/tools/autoscaling/plugins/strategy/target-value.mdx index 41c9c24e0..13ef0a2aa 100644 --- a/website/content/tools/autoscaling/plugins/strategy/target-value.mdx +++ b/website/content/tools/autoscaling/plugins/strategy/target-value.mdx @@ -15,27 +15,53 @@ instances need to be added or removed. More specify, the new scaling value is calculated as: ``` -new_count = (current_metric_value / target) * current_count +factor = current_metric_value / target +new_count = factor * current_count ``` As an example, a policy that tracks memory usage with target defined as `70` -(representing 70% of memory usage) and there are `10` instances running will -generate a scaling action to add `2` new instances when the metric reaches `80` +(representing 70% of memory usage) and in a scenario where there are `10` +instances running will generate a scaling action with scaling factor of +`1.1428571429`, which will add `2` new instances when the metric reaches `80` (80% of memory usage) because: ``` -new_count = (80/70) * 10 = 11.43 ~= 12 +factor = 80/70 = 1.1428571429 +new_count = 1.1428571429 * 10 ~= 12 ``` In other words, if with 10 instances the memory usage in 80%, it's expected -that with 12 instances the memory usage is lower and closer to the target value -of 70%. +that with 12 instances the memory usage will be lower and closer to the target +value of 70%. -~> **Note:** In some situations this inverse relationship may not be true, - meaning that _more_ instances causes the metric value to _grow_. Make sure - you have a good grasp of your query result dynamic when the number of +This means that this strategy expects your infrastructure to have the following +characteristics: + +- **inverse relationship** between metric and number of instances, meaning that + adding _more_ instances will cause your metric value to go _down_. + +- **linear response** to infrastructure changes, meaning that a _2x_ increase + in instance count will cut the metric value approximately in _half_. + +~> **Note:** These properties may not be true for your infrastructure. Make + sure you have a good grasp of your query result dynamic as the number of instances changes. +To fine-tune scaling decisions you can adjust the `threshold` configuration. +This value defines a range between `1 ± threshold` where scaling actions with a +scaling factor within this range are ignored. For example, with the default +value of `0.01` only scaling actions with a factor lower than `0.99` and larger +than `1.01` are taken into account. + +With a low `threshold` you are expected to observe more scaling actions with +smaller changes, while a high `threshold` value is expected to generate fewer +scaling actions with bigger changes in count. + +Since `threshold` is compared against the computed scaling factor, and the +factor is based on your expected metric values and specified `target`, +adjusting the `threshold` value can take some time and a few trial and error +attempts. + ## Agent Configuration Options ```hcl