Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Telemetry Providers are defined using a YAML manifest with the following structure:
with the following properties:
Refer to the page Integrating Telemetry Providers which describes the out-of-the-box Telemetry Providers that are created automatically at Akamas install time.
Name | Type | Description | Mandatory |
---|---|---|---|
name
string
The name of the Telemetry Provider. This name will be used to reference the Telemetry Provider in the Telemetry Provider Instances. This is unique in an Akamas instance
yes
description
string
A description for the Telemetry Provider
yes
dockerImage
string
The docker image of the Telemetry Provider.
yes
This section describes all the structures that can be used to define resources and objects in Akamas.
Field | Type | Value restrictions | Is required | Default value | Description |
---|---|---|---|---|---|
Resource | Construct template |
---|
name
string
should match the following regexp:
^[a-zA-Z][a-zA-Z0-9_]*$
that is only letters, number and underscores, no initial number of underscore
Notice: this should not match the name of another component
TRUE
The name of the component.
description
string
TRUE
A description to characterize the component.
componentType
string
notice: this should match the name of an existing component-type
TRUE
The name of the component-type that defines the type of the component.
properties
object
FALSE
General custom properties of the component. These properties can be defined freely and usually have the purpose to expose information useful for configuring the component.
Parameters are defined using a YAML manifest with the following structure:
with the following properties:
Notice that parameter definitions are shared across all the workspaces on the same Akamas installation, and require an account with administrative privileges to manage them.
The following represents a set of parameters for a JVM component
The following represents a set of CPU-related parameters for the Linux operating system
Metrics are defined using a YAML manifest with the following structure:
and properties:
The supported units of measure for metrics are:
Notice that supported units of measure are automatically scaled for visualization purposes. In particular, for units of information, Akamas uses a base 2 scaling for bytes, i.e., 1 kilobyte = 1024 bytes, 1 megabyte = 1024 kilobytes, and so on. Other units of measure are only scaled up using millions or billions (e.g., 124000000 custom units become 124 Mln custom units).
The most important thing when designing custom optimization packs is to choose the correct unit of measure for every metric. In the previous paragraph you were given a full listing of the supported units of measure and the way they are scaled by Akamas UI (e.g. you may notice that, when viewing study or optimization charts memory bytes are scaled to megabytes or gigabytes, whenever needed). There is another scaling involved and this happens inside telemetry providers. Akamas integrates with several telemetry providers (such as Neoload, Loadrunner, Dynatrace, etc). The purpose of these Akamas providers is to mask the differences between scaling units used by the various telemetry providers (again: Neoload, Loadrunner, etc) and to perform a specific scaling on these measures in order to guarantee that all metrics are homogeneous when they are finally fed to the Akamas engine.
Let's take Akamas provider for Dynatrace, for example. Here's a snippet of the internal metrics mapping between Dynatrace and Akamas:
This means that values coming from Dynatrace metric builtin:service.response.time
will be mapped to Akamas metric requests_response_time
but since Dynatrace returns microseconds with that metric, Akamas provider code will scale it multiplying by 0.001
to convert it to nanoseconds. Similarly, values coming from Dynatrace metric builtin:service.errors.total.rate
which are percent values but range from 0 to 100, must be scaled (scale factor is 0,01
) in order to convert them to domain [0.0, 1.0]
used by Akamas
So when designing a custom optimization pack you should make sure that:
memory unit is bytes
cpu unit is CPUs
when real hardware is involved
cpu unit is millicores
when docker/Kubernetes containers are involved
cpu utilization unit is percent
(100% being 1.00)
throughput unit is XXX/sec (e.g.: bytes/sec
, responses/sec
, collections/sec
)
temporal unit for CPU-related metrics is nanoseconds
temporal unit for web-related metrics is milliseconds
temporal unit for human-related metric is seconds
(unless otherwise noted by the telemetry provider)
Component types are defined using a YAML manifest with the following structure:
and properties for the general section:
The parameter section describes the relationship between the component type and already defined parameters with the following properties:
The metric section describes the relationship between the component type and already defined metrics with the following properties:
Notice that component type definitions are shared across all the workspaces on the same Akamas installation, and require an account with administrative privileges to manage them.
Example of a component for the Cassandra component type:
Example of a component for the Linux operating component type:
Telemetry instances are defined using a YAML manifest with the following structure:
with the following properties for the global section
and the metrics section
Optimization studies are defined using a YAML manifest with the following structure:
with the following mandatory properties:
Some of these optional properties depend on whether the study is an offline or live optimization study.
It is possible to perform more than one trial per experiment in order to validate the score of a configuration under test, e.g. to take into account noisy environments.
The following fragment of the YAML definition of a study sets the number of trials to 3:
Notice: This is a global property of the study which can be overwritten for each step.
The trial aggregation policy defines how trial scores are aggregated to form experiment scores.
There are three different types of strategies to aggregate trial scores:
AVG: the score of an experiment is the average of the scores of its trials - this is the default
MIN: the score of an experiment is the minimum among the scores of its trials
MAX: the score of an experiment is the maximum among the scores of its trial
The following fragment of the YAML definition of a study sets the trial aggregation to MAX:
The following system refers to an offline optimization study for a system modeling an e-commerce service, where a windowing strategy is specified:
The following offline study refers to a tuning initiative for a Cassandra-based system (ID 2)
The following offline study is for tuning another Cassandra-based system (ID 3) by acting only on JVM and Linux parameters
Field | Type | Value restrictions | Is required | Default Value | Description |
---|---|---|---|---|---|
Field | Type | Value restrictions | Is required | Default Value | Description |
---|---|---|---|---|---|
Type | Units |
---|---|
Field | Type | Value restrictions | Is required | Default value | Description |
---|
Field | Type | Value restrictions | Is required | Default value | Description |
---|
Field | Type | Value restrictions | Is required | Default value | Description |
---|
Name | Type | Value Restrictions | Required | Default | Description |
---|
The full list of Operators and related options is provided on the pages.
Name | Type | Description | Mandatory |
---|
Name | Type | Description | Mandatory |
---|
Field | Type | Value restrictions | Is required | Default Value | Description |
---|
Field | Type | Value restrictions | Is required | Default Value | Description |
---|
name
string
It should contain only lower/uppercase letters, numbers or underscores. It should start only with a letter. No spaces are allowed.
TRUE
The name of the parameter
description
string
TRUE
A description characterizing the parameter
unit
string
A supported unit or a custom unit (see supported units of measure)
FALSE
empty unit
The unit of measure of the parameter
restart
boolean
FALSE
FALSE
If the use of the parameters for changing the configuration of a system should cause the system to be restarted.
name
string
No spaces are allowed
TRUE
The name of the metric
unit
string
A supported unit or a custom unit (see supported units of measure)
The unit of measure of the metric
description
string
TRUE
A description characterizing the metric
| string | should match the following regexp:
that is only letters, number and underscores, no initial number of underscore Notice: this should not match the name of another component | Yes | The name of the component. |
| string | Yes | A description to characterize the component. |
| string | notice: this should match the name of an existing component-type | Yes | The name of the component-type that defines the type of the component. |
| object | No | General custom properties of the component. These properties can be defined freely and usually have the purpose to expose information useful for configuring the component. |
name | string | It should match the name of an existing metric | Yes | The name of the metric that should be related to the component type |
name | string | - | yes | - | The name of the task. |
operator | string | - | yes | - | The operator the task implements: the chosen operator affects available arguments. |
critical | boolean | - | no |
| When set to true, task failure will determine workflow failure. |
alwaysRun | boolean | - | no |
| When set to true, task will be executed regardless of workflow failure. |
collectMetricsOnFailure | boolean | - | no |
| When set to true, failure of the task will not prevent metrics collection. |
arguments | list | Determined by operator choice | yes | - | Arguments list required by operators to run. |
| string | The name of the Telemetry Provider | Yes |
| object | Provider-specific configuration in a key-value format (see specific provider documentation for details) | Yes |
| object | This section is used to specify the metrics to extract. This section is specific for each Telemetry Provider (see specific provider documentation for details) | No |
| string | Name of the metric in Akamas. This metric must exists in at least one of the referred by the System associated with the Telemetry Provider Instance | Yes |
| string | Name of the metric (or extraction query) in the data source. The value of this parameter is specific to the data source. | Yes |
| double | Default value that, if specified, is used to create metrics in time-intervals where no other valid datapoint is available. | No |
| List of strings | List of labels. For the specific usage of this parameter, see the documentation of the specific Telemetry Provider | No |
| List of key-value pair | List of Key-Value pairs that are interpreted as a pair of labels name and value. This "static labels" are copied directly in each sample of the specific metric and sent to the Metric Service | No |
| string |
| TRUE |
| The name of the system |
| string |
| TRUE |
| A description to characterize the system |
The MetricSelection
field in a study specifies the metrics of the system. Such selection has only the purpose to specify which metrics need to be tracked while running the study and does not affect the optimization.
In case this selection is not specified, all metrics are considered.
A metrics selection can either assume the value of all
to indicate that all the available metrics of the system of the study should be tracked, or can assume the value of a list of the names of metrics of the system that should be tracked prepended with the name of the component.
The following fragment is an example:
The Windowing
field in a study specifies the windowing policy to be adopted to score the experiments of an optimization study.
The two available windowing strategies have different structures:
Trim windowing: trim the temporal interval of a trial, both from the start and the end of a specified temporal amount - this is the default strategy
Stability windowing: discard temporal intervals in which a given metric is not stable and selects the temporal interval in which a metric is maximized or minimized.
In case the windowing strategy is not specified, the entire time window is considered.
Temporal units
nanoseconds
microseconds
milliseconds
seconds
minutes
hours
Units of information
bits
kilobits
megabits
gigabit
terabit
petabit
bytes
kilobytes
megabytes
gigabytes
terabytes
petabytes
Others
percent
| string | It should match the name of an existing parameter. | Yes | - | The name of the parameter that should be related to the component-type |
| string | {real, integer, categorical} | Yes | - | The type of domain to be set for the parameter in relationship with the component-type |
| array of numbers | The numbers should be either all integers or real numbers(do not omit the " . ") depending on The size of the array must be 2. | No | - | The bounds to be used to define the domain of the parameter. These bounds are inclusive |
| array of strings | No | - | The possible categories that the parameter could possess |
| string, integer, real | The value must be included in the domain, for real and integer types and must be a value included in the categories | Yes | - | The default value of the parameter |
| integer | [0-255] | No | 5 | The number of decimal digits rendered for this parameter |
| object | Yes | - | Specify what operators can be used to apply the parameter |
| object reference | TRUE | The system the study refers to |
| string | TRUE | The name of the study |
| object | TRUE |
| list | FALSE |
| integer | FALSE | 1 | The number of trials for each experiment - see below |
| string |
| FALSE |
| The aggregation used to calculate the score across multiple trials - see below |
| list | FALSE |
|
| list | FALSE |
|
| object array | FALSE |
| string | FALSE |
|
| object reference | TRUE | The workflow the study refers to |
| list | TRUE |
Optimization goals and constraints are defined using a YAML manifest with the following structure:
where:
The function
field of the Goal of a Study details the characteristics of the function Akamas should minimize or maximize to reach the desired performance objective.
The function
field has the following structure:
Where:
The formula
field represents the mathematical expression of the performance objective for the Study and contains variables and operators with the following characteristics:
Valid operators are: +
-
*
/
^
sqrt(variable)
log(variable)
max(variable1, variable2)
min(variable1, variable2)
Valid variables are in the form:
<component_name>.<metric_name>, which correspond directly to metrics of Components of the System under test
<variable_name>, which should match variables specified in the variables
field
Each metric that is directly or indirectly part of the formula of the function of the Goal is aggregated by default by average; more specifically, Akamas computes the average of each metric within the time window specified by the windowing strategy of the Study.
The variables
field contains the specification of additional variables present in the formula, variables that can offer more flexibility with respect to directly specifying each metric of each Component in the formula
.
Notice: each subfield of variables specifies a variable with its characteristics, the name of the subfield is the name of the variable.
The variable subfield has the following structure:
It is possible to use the notation <component_name>.<metric_name> in the metric
field to automatically filter the metric’s data point by that component name is applied.
The constraints
field specifies constraints on the metrics of the components of the system under test that need to be satisfied for a configuration to be valid with respect to the defined goal.
Constraints always consider the average value of specified metrics within the time window specified by the windowing strategy of the Study.
Each constraint has the form of:
mathematical_operation
comparison_operator
value_to_compare
where valid mathematical operations include:
+
-
*
/
^
min
max
sqrt
log
(log is a natural logarithm)
valid comparison operators include:
>
<
<=
>=
==
!=
(equality, inequality)
and valid values to compare include:
absolute values (e.g, 104343)
percentage values relative to the baseline (e.g, 20%)
The following example refers to a study whose goal is to optimize the throughput of a Java service (jpetstore), that is to maximize the throughput (measured as elements_per_second) while keeping errors (error_rate) and latency (avg_duration, max_duration) under control (absolute values):
The following example refers to a study whose goal is to optimize the memory consumption of Docker containers in a microservices application, that is to minimize the average memory consumption of Docker containers within the application of appId="app1" by observing memory limits, also normalizing by the maximum duration of a benchmark (container_benchmark_duration).
A windowing policy of type trim trims the temporal interval of a trial, both from the start and from the end of a specified temporal amount (e.g., 3 seconds).
The trim windowing has the following structure:
In case a windowing policy is not specified, the default windowing corresponding to trim[0s,0s]
is considered.
The following fragment shows a windowing strategy of type "trim" where the time window is specified to start 10s after the beginning of the trial and to end immediately before the end of the trial:
The workloadsSelection
is a structure used to define the metrics that are used by Akamas to model workloads as part of a live optimization study.
with the following fields:
Notice that workload metrics must have been defined in the metricsSelection
.
The following refers to a workload represented by the metric transactions_throughput
of the konakart
component:
A windowing policy of type stability discards temporal intervals in which a given metric is not stable, and selects, among the remaining intervals, the ones in which another target metric is maximized or minimized. Stability windowing can be sample-based or time-frame based.
The stability windowing has the following structure:
and for the comparison metric section
The following fragment is an example of stability windowing (time-frame based):
The ParameterSelection
field in a study specifies which parameters of the system should be tuned while running the optimization study.
In case this selection is not specified, all parameters are considered.
A parameter selection can either assume the value of all
to indicate that all the available parameters of the system of the study should be tuned, or can assume the value of a list with items of the shape like the one below:
Notice that, by default, every parameter specified in the parameters selection of a study is applied. This can be modified, by leveraging the Parameter rendering options.
The following fragment is an example:
The Steps
field in a study specifies the sequence of steps executed while running the study. These steps are run in exactly the same order in which they will be executed.
The following types of steps are available:
Notice that the structure corresponding to the steps is different for the different types of steps.
A baseline step performs an experiment (a baseline experiment) and marks it as the initial experiment of a study. The purpose of the step is to build a reference configuration that Akamas can use to measure the effectiveness of an optimization conducted towards a system.
When a bootstrap step imports an experiment from another study, the step copies not only the experiment but also its trials and the system metrics generated during its execution.
The bootstrap step has the following structure:
where the from
field should have the following structure:
with:
study
contains the name or id of the study from which to import experiments
experiments
contains the numbers of the experiments from which to import
The following is an example of a bootstrap step that imports four experiments from two studies:
You can also import all the experiments of a study by omitting the experiments
field:
A baseline step performs an experiment (a baseline experiment) and marks it as the initial experiment of a study. The purpose of the step is to build a reference configuration that Akamas can use to measure the effectiveness of an optimization conducted towards a system.
A baseline step offers three options when it comes to selecting the configuration of the baseline experiment:
Use a configuration made with the default values of the parameters taken from the system of the study
Use a configuration taken from an experiment of another study
Use a custom configuration
The baseline step has the following structure:
where the from
field should have the following structure:
with
study
contains the name or id of the study from which to take the configuration
experiments
contains the number of the experiment from which to take the configuration
Default values for the baseline configuration only require setting the name
and type
fields:
The configuration taken from another study to be used as a baseline only requires setting the from
field:
Notice: the from
and experiments
fields are defined as an array, but can only contain one element.
The custom configuration for the baseline only requires setting the values
field:
An optimize step generates optimized configurations according to the defined optimization strategy. During this step, Akamas AI is used to generate such optimized configurations.
The optimize step has the following structure:
The optimizer
field allows selecting the desired optimizer:
AKAMAS
identifies the standard AI optimizer used by Akamas
RANDOM
identifies an optimization that generates configurations using random numbers
Notice that SOBOL and RANDOM optimizers do not perform initialization experiments, hence the field numberOfInitExperiments
is ignored.
The optimize step is fault-tolerant and tries to relaunch experiments on failure. Nevertheless, the step imposes a limit on the number of failed experiments: if too many experiments fail, then the entire step fails too. By default, at most 30 experiments can fail while Akamas is optimizing systems. An experiment is considered failed when it either failed to run (i.e., there is an error in the workflow) or violated some constraint.
The optimize step launches some initialization experiments (by default 10) that do not apply the AI optimizer and are used to find good configurations. By default, the step performs 10 initialization experiments.
Initialization experiments take into account bootstrapped experiments, experiments executed in preset steps, and baseline experiments.
The following snippet shows an optimization step that runs 50 experiments using the SOBOL optimizer:
A preset step performs a single experiment with a specific configuration. The purpose of this step is to help you quickly understand how good is a particular configuration.
A preset step offers two options when selecting the configuration of the experiment to be executed:
Use a configuration taken from an experiment of a study (can be the same study)
Use a custom configuration
The preset step has the following structure:
where the from
field should have the following structure:
with
study
contains the name or id of the study from which to take the configuration. in case this is omitted, the same study of the step is considered for experiments from which taking configurations
experiments
contains the number of the experiment from which to take the configuration
You can provide a custom configuration by setting values
:
You can select a configuration taken from another study by setting from
:
You can select a configuration taken from the same study by setting from
but by omitting the study
field:
Notice: the from
and experiments
fields are defined as an array, but can only contain one element.
The renderParameters
and doNotRenderParameters
can be used to specify which configuration parameters should be rendered when doing experiments within a step.
Parameter rendering can be defined at the step level for baseline, preset, and optimize steps. This is not possible for bootstrap steps as bootstrapped experiments are not executed.
The following baseline step specifies that every parameter of the component 'os' should not be rendered while the parameter 'cpu_limit' of the component 'docker' should be rendered:
The following preset step specifies that the parameter 'cpu_limit' of the component 'docker' should be rendered:
The following optimize step specifies that every parameter of the component 'os' should not be rendered:
The kpis
field in a study specifies which metrics should be considered as KPI for an offline optimization study.
In case this selection is not specified, all metrics mentioned in the goal and constraint of the optimization study are considered.
A KPI is defined as follows:
Notice that the textual badge displayed in the Akamas UI use "Best name".
The following fragment is an example of a list of KPIs:
The Optimizer Options is a set of parameters used to fine-tune the study optimization strategy during the optimize step.
Optimizer options have the following structure:
The safetyFactor
field specifies how much the optimizer should stay on the safe side in evaluating a candidate configuration with respect to the goal constraints. A higher safety factor corresponds to a safer configuration, that is a configuration that is less likely to violate goal constraints.
Acceptable values are all the real values ranging between 0 and 1, with (safetyFactor
- 0.5) representing the allowed margin for staying within the defined constraint:
0 means "no safety", as with this value the optimizer totally ignores goal constraint violations;
0.5 means "safe, but no margin", as with this value the optimizer only tries configurations that do not violate the goal constraints, by remaining as close as possible to them;
1 means "super safe", as with this value the optimize only tries configurations that are very far from goal constraints.
For live optimization studies, 0.6 is the default value, while for offline optimization studies, the default value is 0.5.
where experimentsWithBeta
can be:
A percentage between 0 and 100%
A number less than or equal to numberOfExperiments
For live optimization studies, the optimizerOptions
field can be used to specify several important parameters governing the live optimization:
The onlineMode
field specifies how the Akamas optimizer should operate:
RECOMMEND
: configurations are recommended to the user by Akamas and are only applied after having been approved (and possibly modified) by the user;
FULLY AUTONOMOUS MODE
: configurations are immediately applied by Akamas.
The safetyMode
field describes how the Akamas optimizer should evaluate the goal constraints on a candidate configuration for that configuration to be considered valid:
GLOBAL
: the constraints must be satisfied by the configuration under all observed workloads in the configuration history - this is the value taken in case onlineMode
is set to RECOMMEND
;
LOCAL
: the constraints are evaluated only under the workload selected according to the workload strategy - this should be used with onlineMode
set to FULLY_AUTONOMOUS
.
Notice that when setting the safetyMode
to LOCAL
, the recommended configuration is only expected to be good for the specific workload selected under the defined workload strategy, but it might violate constraints under another workload.
The workloadOptimizedForStrategy
field specifies the workload strategy that drives how Akamas leverages the workload information when looking for the next configuration:
MAXIMIN
: the optimizer looks for a configuration that maximizes the minimum improvements for all the already observed workloads;
MOST_VIOLATED
: for each workload, the workload of the configuration with more violations is considered.
The explorationFactor
field specifies how much the optimizer explores the (unknown) optimization space when looking for new configurations. For any parameter, this factor measures the difference between already tried values and the value of a new possible configuration. A higher exploration factor corresponds to a broader exploration of never-tried-before parameter values.
Acceptable values are all the real values ranging between 0 and 1, plus the special string FULL_EXPLORATION
:
0 means "no exploration", as with this value the optimizer chooses a value among the previously seen values for each parameter;
1 means "full exploration, except for categories", as with this value the optimizer for a non-categorical parameter any value among all its domain values can be chosen, while only values (categories) that have already been seen in previous configurations are chosen for a categorical parameter;
FULL_EXPLORATION
means "full exploration, including categories" as with this value the optimizer chooses any value among all its domain values, including categories, even if not already seen in previous configurations.
The following fragment refers to an optimization study that runs 100 experiments using the SOBOL optimizer and forces 50% of the experiments to use the beta-warping option, enabling a more sophisticated but longer optimization:
The name and the parameters of a supported
The goal and constraint description - see
The KPIs description - see
The list of parameters to be tuned - see
The list of metrics - see
The list of defined workloads - this only applies to live optimization studies - see
The windowing strategy - this only applies to offline optimization studies - see
The description of the steps - see
Field | Type | Value restriction | Is Required | Default value | Description |
---|---|---|---|---|---|
Field | Type | Value restrictions | Is required | Default value | Description |
---|---|---|---|---|---|
Field | Type | Value restrictions | Is required | Default value | Description |
---|---|---|---|---|---|
Filed | Type | Value restrictions | Is required | Default value | Description |
---|---|---|---|---|---|
Field | Type | Value restriction | Is required | Default value | Description |
---|---|---|---|---|---|
Field | Type | Value restrictions | Is required | Default value | Description |
---|---|---|---|---|---|
Field | Type | Value restrictions | Is required | Default value | Description |
---|---|---|---|---|---|
Field | Type | Value restriction | Is required | Default value | Description |
---|---|---|---|---|---|
: performs an experiment and sets it as a baseline for all the other ones
: imports experiments from other studies
: performs an experiment with a specific configuration
: performs experiments and generates optimized configurations
Field | Type | Value restrictions | Is required | Default value | Description |
---|
Field | Type | Value restriction | Is required | Default value | Description |
---|
Field | Type | Value restrictions | Is required | Default value | Description |
---|
SOBOL
identifies an optimizer that generates configurations using
Refer to page for more configuration options for the optimizer
Field | Type | Value restrictions | Is required | Default value | Description |
---|
Field | Type | Value restrictions | Is required | Description |
---|
Field | Type | Value restriction | Is required | Default value | Description |
---|
Field | Type | Value restrictions | Description |
---|
For , the optimizerOptions
field can be used to specify whether beta-warping optimization (a more sophisticated optimization that requires a longer time) should be used and for how many experiments (as a percentage):
Notice that while available as independent options, the optimizer options onlineMode
(described ), workloadOptimizedForStrategy
() and the safetyFactor
() work in conjunction according to the following schema:
Online Mode | Safety Mode | Workload strategy |
---|
All these optimizer options can be changed at any time, that is while the optimization study is running, to become immediately effective. The page in the reference guide provides these specific update commands.
LAST
: for each workload, the last observed workload is considered - this works well to find a configuration that is good for the last workloads - it is often used in conjunction with a LOCAL
safety mode (see );
In case the desired explorationFactor
is 1 but there are some specific parameters that also need to be explored with respect to all its categories, then PRESET steps (refer to the page) can be used to run an optimization study with these values. For an example of a live optimization study where this approach is adopted see .
nanoseconds
microseconds
milliseconds
seconds
minutes
hours
bits
kilobits
megabits
gigabit
terabit
petabit
bytes
kilobytes
megabytes
gigabytes
terabytes
petabytes
objective
String
minimize
maximize
Yes
How Akamas should evaluate the goodness of a generated configuration: if it should consider good a configuration generated that maximizes function
, or a configuration that minimizes it.
function
Object
It should have a structure like the one described in Goal function
Yes
The specification of the function to be evaluated to assess the goodness of a configuration generated by Akamas. This function is a function of the metrics of the different Components of the System under test.
constraints
List of objects
It should have a structure like the one described in Goal constraints
No
A list of constraints on aggregated metrics of the Components of the System under test for which a generated configuration should not be considered valid.
formula
String
See formula
Yes
The mathematical expression of what to minimize or maximize to reach the objective of the Study.
variables
Object
See below
No
The specification of additional variables present in the formula
.
metric
String
should match the name of a metric defined for the Components of the System under test
Yes
The name of the metric of the Components of the System under test that maps to the variable.
labels
A set of key-value pairs
No
A set of filters based on the values of the labels that are attached to the different data points of the metric
. One of these labels is componentName, which contains the name of the Component the metric refers to.
aggregation
String
MAX
MIN
AVG
No
AVG
The strategy through which data points of the metric
should be aggregated within the window produced by the application of the selected windowing strategy. By default, an average is taken.
type
string
{trim}
TRUE
the type of windowing strategy
trim
array of strings
The length of the array should be two.
Valid values should have the form of a whole number followed by either "s", "m", or "h"
TRUE
How to trim the temporal interval of a trial to get the window. ["0s", "10m"] means trim 0 seconds from the start of the interval, 10 minutes from the end. ["0s", "1h"] means trim 0 seconds from the start, 1 hour from the end
task
string
The name of a task of the workflow associated with the study
FALSE
If the field is specified, the trim offset calculation for the window will be applied from the start time of the assigned task. Otherwise, it will be calculated from the start time of the trial.
name
string
should match the following syntax:
component_name.metric_name<:aggregation>
where component_name
is an existing component, metric_name
is an existing metric associated with the component-type of the component component_name
, and aggregation is an optional aggregation (default avg)
TRUE
The metric of the component that represents the workload
type
string
{stability}
TRUE
The type of windowing.
stability->metric
string
It should match the name of an existing metric monitored by AKAMAS
TRUE
The metric whose stability is going to be verified to exclude some temporal intervals over the duration of a trial.
stability->labels
set of key-value pairs
FALSE
A set of key-value pairs that represent filtering conditions for retrieving the value of the metric
. This conditions can be used to consider the right metric of the right component, you can in fact filter by componentName or by other custom properties defined in the components of the system of the study.
stability->resolution
string
Valid values are in the form 30s
40m
2h
where s
refers to seconds, m
to minutes, h
to hours
FALSE
0s
The temporal resolution at which Akamas aggregate data points to determine feasible windows.
stability->width
integer string
stability->width
> 1
Valid values are in the form 30s
40m
2h
as specified in stability->resolution
TRUE
The width of temporal intervals over the duration trial which are checked for the stability of the metric
.
Width can be sample-based (integer) or time frame-based (string).
stability->maxStdDev
double
TRUE
The stability condition, i.e, the maximum amount of standard deviation among the value of the data point of the metric tolerated for a temporal interval of size width
, otherwise, the temporal interval will be discarded
metric
string
It should match the name of an existing metric monitored by Akamas
TRUE
The metric whose value is analyzed to include or exclude temporal intervals over the duration of a trial, when another reference metric is stable.
labels
set of key-value pairs
FALSE
A set of key-value pairs that represent filtering conditions for retrieving the value of the metric
. This conditions can be used to consider the right metric of the right component, you can in fact filter by componentName or by other custom properties defined in the components of the system of the study.
is
string
{min,max}
TRUE
If the value of the metric should be maximum or minimum to include or exclude temporal intervals over the duration of a trial when another reference metric is stable.
name
string
should match the following syntax:
component_name.parameter_name
where component_name
is an existing component, where parameter_name
is an existing parameter that is associated with the component-type of the component component_name
TRUE
The name of the parameter to be tuned including the name of the component it refers to
domain
array of numbers
should be of size 2, contain either all integers or real numbers(do not omit the "."), be set only if the parameter has a domain of type integer
or real,
and be compatible with the domain defined in the component-type the component_name
refers to
FALSE
A custom domain for the parameter to be used only for the study
categories
array of string
should be set only if the parameter has a domain of type categorical
, and be compatible with the domain defined in the component-type the component_name
refers to.
FALSE
A custom set of categories for the parameter to be used only for the study.
| string |
| yes | The type of the step, in this case, |
| string | yes | The name of the step |
| boolean |
| no |
| The execution policy of the step:
|
| array of objects | Each object should have the structure described below | yes | The experiments to import in the current study In case this is not set, this step imports every experiment of a study |
| Array of strings | should contain strings in the form component.parameter or component. component. means every parameter of the component | No | Which configuration parameters should be rendered or applied when doing experiments/trials in addition to ones in the parameters selection or in the values if the step is of type baseline or preset |
| Array of strings | should contain strings in the form component.parameter or component. component. means every parameter of the component | No | Which configuration parameters should not be rendered or applied when doing experiments/trials |
| string | should match a component metric | no |
| Label that will be used in the UI |
| string | Must be defined as | yes | The metric name associated to a component |
| string |
| yes | The direction corresponding to the metric |
| string |
| no |
| A valid metric aggregation |
| string |
| Changes are approved automatically or must be edited/approved by the user |
| string |
| Defines how Akamas optimizer evaluates goal constraints |
| decimal | between 0 and 1 | Parameter that impacts the distance from goal constraints for new configurations |
| string |
| Selects the computation strategy to generates future configurations |
| decimal, string | between 0 and 1 or | Set the tendency to explore toward unexplored configuration values |
| decimal / string | if string must be a percentage between 0% and 100%. If numeric must be less than or equal to | Percentage/number of experiments that will be computed with beta-warping optimization |
|
|
|
|
|
|
| string |
| yes | The type of the step, in this case, |
| string | yes | The name of the step |
| boolean |
| no |
| The execution policy of the step:
|
| array of objects | Each object should have the structure described below | no | The study and the experiment from which to take the configuration of the baseline experiment The This can be set only if |
| object | The keys should match existing parameters | no | The configuration with which execute the baseline experiment This can be set only if |
| string | this cannot be used when using a from option since no experiment is actually executed | no |
| string | this cannot be used when using a from option since no experiment is actually executed | no |
| string |
| yes | The type of the step, in this case, |
| string | yes | The name of the step |
| boolean |
| no |
| The execution policy of the step:
|
| integer |
| yes | The number of experiments to execute - see below |
| integer |
| no | 1 | The number of trials to execute for each experiment |
| integer |
| no | 10 | The number of initialization experiment to execute - see below. |
| integer |
| no | 30 | The number of experiment failures (as either workflow errors or constraint violations) to accept before the step is marked as failed |
| string |
| no |
| The type of optimizer to use to generate the configuration of the experiments - see below |
| string | no |
| string | no |
| string |
| yes | The type of the step, in this case, |
| string | yes | The name of the step |
| boolean |
| no |
| The execution policy of the step:
|
| array of objects | Each object should have the structure described below | no | The study and the experiment from which to take the configuration of the experiment The This can be set only if |
| object | The keys should match existing parameters | no | The configuration with which execute the experiment This can be set only if |
| string | this cannot be used when using a from option since no experiment is actually executed | no |
| string | this cannot be used when using a from option since no experiment is actually executed | no |
Parameters not to be rendered. - see
Parameters to be rendered. - see
Parameters not to be rendered. - see
Parameters to be rendered. - see
Parameters not to be rendered. - see
Parameters to be rendered. - see