kemko/nomad
1
0
Fork 0
mirror of https://github.com/kemko/nomad.git synced 2026-01-10 12:25:42 +03:00
Code Issues Packages Projects Releases Wiki Activity

docs: clarify autoscaling factor and threshold for target-value plugin (#15418)

Browse Source
This commit is contained in:
Luiz Aoqui
2022-11-30 10:56:16 -05:00
committed by GitHub
parent 717fddb521
commit bdf2085099
1 changed files with 35 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

44
website/content/tools/autoscaling/plugins/strategy/target-value.mdx
View File

@@ -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