The CSV provider collects metrics from CSV files and makes them available to Akamas. It offers a very versatile way to integrate custom data sources.

Prerequisites

This section provides the minimum requirements that you should match before using the CSV File telemetry provider.

Network requirements

The following requirements should be met to enable the provider to gather CSV files from remote hosts:

• Port 22 (or a custom one) should be open from Akamas installation to the host where the files reside.

• The host where the files reside should support SCP or SFTP protocols.

Permissions

• Read access to the CSV files target of the integration

Akamas supported version

• Versions < 2.0.0 are compatibile with Akamas until version 1.8.0

• Versions >= 2.0.0 are compatible with Akamas from version 1.9.0

Supported component types

The CSV File provider is generic and allows integration with any data source, therefore it does not come with support for a specific component type.

Setup the data source

To operate properly, the CSV file provider expects the presence of four fields in each processed CSV file:

• A timestamp field used to identify the point in time a certain sample refers to.

• A component field used to identify the Akamas entity.

• A metric field used to identify the name of the metric.

• A value field used to store the actual value of the metric.

These fields can have custom names in the CSV file, you can specify them in the provider configuration.

The Install CSV provider page describes how to get this Telemetry Provider installed. Once installed, this provider is shared with all users of your Akamas installation and can be used to monitor many different systems, by configuring appropriate telemetry provider instances as described in the Create a CSV provider instance page.

To install the CSV File provider, create a YAML file (called provider.yml in this example) with the specification of the provider:

# CSV File Telemetry Provider
name: CSV File
description: Telemetry Provider that enables to import of metrics from a remote CSV file
dockerImage: 485790562880.dkr.ecr.us-east-2.amazonaws.com/akamas/telemetry-providers/csv-file-provider:3.0.2

Then, you can then install the provider with the Akamas CLI:

akamas install telemetry-provider provider.yml

Install the Telemetry Provider

Skip this part if the Telemetry Provider is already installed.

To install the Dynatrace provider, create a YAML file (called provider.yml in this example) with the definition of the provider:

# Dynatrace Telemetry Provider
name: Dynatrace
description: Telemetry Provider that enables to import metrics from Dynatrace installations
dockerImage: 485790562880.dkr.ecr.us-east-2.amazonaws.com/akamas/telemetry-providers/dynatrace-provider:3.1.7

Then you can install the provider using the Akamas CLI:

akamas install telemetry-provider provider.yml

To install the Prometheus provider, create a YAML file (provider.yml in this example) with the definition of the provider:

name: Prometheus
description: Telemetry Provider that enables to import of metrics from Prometheus
dockerImage: 485790562880.dkr.ecr.us-east-2.amazonaws.com/akamas/telemetry-providers/prometheus-provider:3.2.6

Then you can install the provider using the Akamas CLI:

akamas install telemetry-provider provider.yml

The installed provider is shared with all users of your Akamas installation and can monitor many different systems, by configuring appropriate telemetry provider instances.

To install the Spark History Server provider, create a YAML file (called provider.yml in this example) with the definition of the provider:

# Spark History Server Telemetry Provider
name: SparkHistoryServer
description: Telemetry Provider that enables to import of metrics from Spark History Server instances
dockerImage: 485790562880.dkr.ecr.us-east-2.amazonaws.com/akamas/telemetry-providers/spark-history-server-provider:2.0.0

Then you can install the provider using the Akamas CLI:

akamas install telemetry-provider provider.yml

The installed provider is shared with all users of your Akamas installation and can monitor many different systems, by configuring appropriate telemetry provider instances.

Create a telemetry instance

To create an instance of the Spark History Server provider, build a YAML file (instance.yml in this example) with the definition of the instance:

provider: SparkHistoryServer
config:
  address: spark_master_node
  port: 18080
  importLevel: stage

Then you can create the instance for the system spark-system using the Akamas CLI:

akamas create telemetry-instance instance.yml spark-system

Configuration options

When you create an instance of the Spark History Server provider, you should specify some configuration information to allow the provider to correctly extract and process metrics from the Spark History server.

You can specify configuration information within the config part of the YAML of the instance definition.

Required properties

• address - hostname of the Spark History Server instance

Telemetry instance reference

The following YAML file describes the definition of a telemetry instance.

provider: SparkHistoryServer  # This is an instance of the Spark History Server provider
config:
  address: spark_master_node # The adress of Spark History Server
  port: 18080   # The port of Spark History Server
  importLevel: job  # The granularity of the imported metrics

The following table reports the reference for the config section within the definition of the Spark History Server provider instance:

Use cases

This section reports common use cases addressed by this provider.

Collect stage metrics of a Spark Application

Check Spark Application page for a list of all Spark application metrics available in Akamas

This example shows how to configure a Spark History Server provider in order to collect performance metrics about a Spark application submitted to the cluster using the Spark SSH Submit operator.

As a first step, you need to create a YAML file (spark_instance.yml) containing the configuration the provider needs to connect to the Spark History Server, plus the filter on the desired level of granularity for the imported metrics:

provider: SparkHistoryServer
config:
  address: spark_master_node
  port: 18080
  importLevel: stage

and then create the telemetry instance using the Akamas CLI:

akamas create telemetry-instance spark_instance.yml

Finally, you will need to define for your study a workflow that includes the submission of the Spark application to the cluster, in this case using the Spark SSH Submit operator:

name: spark_workflow
tasks:
  - name: Run Spark application
    operator: SSHSparkSubmit
    arguments:
      component: spark

Best practices

This section reports common best practices you can adopt to ease the use of this telemetry provider.

• configure metrics granularity: in order to reduce the collection time, configure the importLevel to import metrics with a granularity no finer than the study requires.

• wait for metrics publication: make sure in the workflow there is a few-minute interval between the end of the Spark application and the execution of the Spark telemetry instance, since the Spark History Server may take some time to complete the publication of the metrics.

To install the NeoLoad Web provider, create a YAML file (called provider.yml in this example) with the definition of the provider:

# NeoLoad Web Telemetry Provider
name: NeoLoadWeb
description: Telemetry Provider that enables to import of metrics from NeoLoad Web instances
dockerImage: 485790562880.dkr.ecr.us-east-2.amazonaws.com/akamas/telemetry-providers/neoload-web-provider:2.0.1

Then you can install the provider using the Akamas CLI:

akamas install telemetry-provider provider.yml

The installed provider is shared with all users of your Akamas installation and can monitor many different systems, by configuring appropriate telemetry provider instances.

When you create an instance of the NeoLoad Web provider, you should specify some configuration information to allow the provider to correctly extract and process metrics from NeoLoad Web.

You can specify configuration information within the config part of the YAML of the instance definition.

Required properties

• accountToken - NeoLoad Web API access token.

Telemetry instance reference

The following YAML file describes the definition of a telemetry instance.

provider: NeoLoadWeb  # this is an instance of the NeoLoad Web provider
config:
  neoloadApi: http://neoload-api.mydomain.com     # API host
  accountToken: d2d9d8c6064b35209d7f6912db986a6e  # access token
  actions:    # the list of User Paths to import
    - 01 - Home page
  metrics:    # the list of metrics to import
    - transactions_response_time
    - transactions_throughput
    - pages_response_time
    - users

The following table provides the reference for the config section within the definition of the NeoLoad Web provider instance:

Notice: the NeoLoadWeb provider imports data points matching at least one of the configured values for both metrics and actions.

Use cases

This section reports common use cases addressed by this provider.

Collect Web Application metrics

Check the Web Application page for a list of all web application metrics available in Akamas

This example shows how to configure the NeoLoad Web provider in order to collect performance metrics published on the SaaS web API.

You must create a YAML file with the definition of a telemetry instance (neoload_instance.yml) of the NeoLoad Web provider:

provider: NeoLoadWeb
config:
  accountToken: d2d9d8c6064b35209d7f6912db986a6e

and then create the telemetry instance using the Akamas CLI:

akamas create telemetry-instance neoload_instance.yml

You can then configure the workflow in order to trigger the execution of a NeoLoad test using the NeoLoadWeb provider, as in the following example:

name: neoloadweb_wf
tasks:
- name: Run NeoLoadWeb
  operator: NeoLoadWeb

  arguments:
    accountToken: d2d9d8c6064b35209d7f6912db986a6e
    controllerZoneId: mlmEt
    lgZones: mlmEt:1

    scenarioName: test
    projectFile:
      http:
        url: https://files.akamas.io/neoload/project00.zip
        verifySSL: false

Best practices

This section reports common best practices you can adopt to ease the use of this telemetry provider.

• filter the imported metrics: import only the required metrics using the metrics and actions filters, in order to avoid throttling on the NeoLoad Web instance.

The LoadRunner Enterprise provider collects metrics from a LoadRunner Enterprise instance and makes them available to Akamas.

Prerequisites

This section provides the minimum requirements that you should match before using the LoadRunnerEnterprise telemetry provider.

Supported versions

• LoadRunner Enterprise 12.60, 12.63 and 2020 SP3

• InfluxDB 1.7 and 1.8

Network requirements

• Port 8086 between Akamas VM to InfluxDB host, opened in both directions. This port is used to gather metrics.

Permissions

• The provider requires a user that can access InfluxDB.

• The user must have read permission on the database containing the LoadRunner metrics.

Supported component types

• Web Application

You can check LoadRunner provider metrics mapping to see how component-types metrics are extracted by this provider.

Workflow requirements

This section lists the workflow operators this provider depends on.

• LoadRunnerEnterprise operator

Setup the data source

To set up the integration between Loadrunner Enterprise and InfluxDB please follow the official Microfocus documentation. Akamas does not require any additional setup on the data source.

Components configuration

Akamas reasons in terms of a system to be optimized and in terms of parameters and metrics of components of that system. To understand the link between metrics collected from LoadRunnerEnterprise through InfluxDB and a specific component, the LoadRunnerEnterprise provider looks up some properties in the components of a system:

• loadrunnerenterprise

You can use this example to start building your component specification:

# Specification for a component, whose metrics should be collected by the Prometheus Provider
name: "WebApp1" # name of the component
description: "WebApp for payment services" # description of the component
properties:
  loadrunnerenterprise: ""

To install the LoadRunner provider, create a YAML file (called provider.yml in this example) with the definition of the provider:

# LoadRunner Telemetry Provider
name: LoadRunner
description: Telemetry Provider that enables to import of metrics from LoadRunner installations
dockerImage: 485790562880.dkr.ecr.us-east-2.amazonaws.com/akamas/telemetry-providers/loadrunner-provider:2.0.0

Then you can install the provider using the Akamas CLI:

akamas install telemetry-provider provider.yml

The installed provider is shared with all users of your Akamas installation and can monitor many different systems, by configuring appropriate telemetry provider instances.

To create an instance of the CSV provider, build a YAML file (instance.yml in this example) with the definition of the instance:

# AWS Telemetry Instance
provider: AWS
config:
  accessKeyId: access_key_id
  secretAccessKey: secret_access_key

Then you can create the instance for the aws-system using the Akamas CLI:

akamas create telemetry-instance instance.yml aws-system

Configuration options

When you create an instance of the AWS provider, you should specify some configuration information to allow the provider to correctly extract and process metrics from your CSV files.

You can specify configuration information within the config part of the YAML of the instance definition.

Required properties

• accessKeyId - the access key id of your chosen IAM use

• secretAccessKey - the secret access key of your chosen IAM user

Telemetry instance reference

The following represents the complete configuration reference for the telemetry provider instance.

provider: AWS                                # This is an instance of the AWS provider
config:
  accessKeyId: access_key_id                 # The access key id of your IAM user
  secretAccessKey: secret_access_key         # The secret access key of your IAM user

Then you can create the instance for the aws-system using the Akamas CLI:

akamas create telemetry-instance instance.yml aws-system

Configuration options

When you create an instance of the AWS provider, you should specify some configuration information to allow the provider to correctly extract and process metrics from your CSV files.

You can specify configuration information within the config part of the YAML of the instance definition.

Required properties

• accessKeyId - the access key id of your chosen IAM use

• secretAccessKey - the secret access key of your chosen IAM user

Telemetry instance reference

The following YAML file represents a template to define the telemetry provider instance.

provider: AWS                                # This is an instance of the AWS provider
config:
  accessKeyId: access_key_id                 # The access key id of your IAM user
  secretAccessKey: secret_access_key         # The secret access key of your IAM user

The following table describes the configuration reference for the config section

The Prometheus provider collects metrics from a Prometheus instance and makes them available to Akamas.

This provider includes support for several technologies. In any case, you can specify your own queries to gather any metric you want.

Prerequisites

This section provides the minimum requirements that you should match before using the Prometheus provider.

Supported versions

• Prometheus 1.x and 2.x.

Network requirements

• Prometheus is reachable at a provided URL or IP address and port (the default Prometheus port is 9090)

Supported Prometheus exporters

• Node exporter (Linux system metrics)

• JMX exporter (Java metrics)

• cAdvisor (Docker container metrics)

• CloudWatch exporter (AWS resources metrics)

• Jmeter (Web application metrics)

Akamas supported version

• Versions < 2.0.0 are compatibile with Akamas untill version 1.8.0

• Versions >= 2.0.0 are compatible with Akamas from version 1.9.0

Supported component types

• Ubuntu-16.04, Rhel-7.6

• java-openjdk-8, java-openjdk-11

• java-ibm-j9vm-6, java-ibm-j9vm-8, java-eclipse-openj9-11

• Container

• ec2

• Web Application

You can check Prometheus provider metrics mapping to see how component-types metrics are extracted by this provider

Setup the data source

The Prometheus provider does not require a specific configuration of the Prometheus instance it uses, except for the need for setting the value of the instance label of each data point so that it matches the value of the instance property in a component; in this way, the Prometheus provider can know which data point refers to which component in a system.

Here’s an example configuration for Prometheus that sets the instance label:

# Custom global config
global:
  scrape_interval:     5s   # Set the scrape interval to every 15 seconds. The default is every 1 minute.
  evaluation_interval: 5s   # Evaluate rules every 15 seconds. The default is every 1 minute.
  # scrape_timeout is set to the global default (10s).

# A scrape configuration containing exactly one endpoint to scrape:
scrape_configs:
# Node Exporter
- job_name: 'node'
  static_configs:
  - targets: ["localhost:9100"]
  relabel_configs:
  - source_labels: ["__address__"]
    regex: "(.*):.*"
    target_label: instance
    replacement: value_of_instance_property_in_the_component_the_data_points_should_refer_to

Component configuration

Akamas reasons in terms of a system to be optimized and in terms of parameters and metrics of components of that system. To understand which metrics collected from Prometheus should refer to which component, the Prometheus provider looks up some properties in the components of a system grouped under prometheus property. These properties are:

• instance, which tells the provider "where" a component is

• job (optional), which filters the imported metrics by exporter identifier, useful when different components run on the same instance. If not provided, this value defaults to the one configured globally in the telemetry-instance definition.

Nested under this property you can also include any additional field your use case may require to further filter the imported metrics. These fields will be appended in queries to the list of label matches in the form field_name=~'field_value', and can specify either exact values or patterns.

Notice: you should configure your Prometheus instances so that the Prometheus provider can leverage the instance property of components, as described in the Setup datasource section here above.

It is important that you add instance and, optionally, the job properties to the components of a system so that the Prometheus provider can gather metrics from them:

# Specification for a component, whose metrics should be collected by the Prometheus Provider
name: jvm1 # name of the component
description: jvm1 for payment services    # description of the component
properties:
  prometheus:
    instance: service0001  # instance of the component: where the component is located from the point of view of prom
    job: jmx               # job of the component: which prom exporter is gathering metrics from the component

The AWS provider collects price metrics for Amazon Elastic Compute Cloud (EC2) from Amazon’s own APIs.

Prerequisites

This section provides the minimum requirements that you should match before using the AWS telemetry provider.

AWS users and policies requirements

• A IAM user that has been granted the AWSPriceListServiceFullAccess policy, that is the following permissions:

  • DescribeServices

  • GetAttributeValues

  • GetProducts

You may find more information on AWS cost permissions here.

Akamas supported version

• Versions >= 2.0.0 are compatible with Akamas from version 1.9.0

Supported component types

• EC2

Components configuration

In order to gather price information about a component you’re required to input an extra field in its definition:

• region, which tells the provider the AWS region of the modeled instance

Please note this field is mandatory and must be specified as follows:

# Specification for a component, whose metrics should be collected by the AWS Provider
name: aws_1 # name of the component
description: aws_1 instance to tune # description of the component
properties:
    ec2:
        region: us-east-1 # AWS region of the component

Here is a complete list of AWS region names, together with their Akamas-compatible codes:

This page describes how to set up an OracleDB exporter in order to gather metrics regarding an Oracle Database instance through the Prometheus provider.

Installation

The OracleDB exporter repository is available on the official project page. The suggested deploy mode is through a Docker image, since the Prometheus instance can easily access the running container through the Akamas network.

Use the following command line to run the container, where cust-metrics.toml is your configuration file defining the queries for additional custom metrics (see paragraph below) and DATA_SOURCE_NAME an environment variable containing the Oracle EasyConnect string:

docker run -d --name oracledb_exporter --restart always \
  --network akamas -p 9161:9161 \
  -v ~/oracledb_exporter/cust-metrics.toml:/cust-metrics.toml \
  -e CUSTOM_METRICS=/cust-metrics.toml \
  -e DATA_SOURCE_NAME="username/password@//oracledb.mycompany.com/service" \
  iamseth/oracledb_exporter

You can refer to the official guide for more details or alternative deployment modes.

Custom queries

It is possible to define additional queries to expose custom metrics using any data in the database instance that is readable by the monitoring user (see the guide for more details about the syntax).

Custom Configuration file

The following is an example of exporting system metrics from the Dynamic Performance (V$) Views used by the Prometheus provider default queries for the Oracle Database optimization pack:

[[metric]]
context= "memory"
labels= [ "component" ]
metricsdesc= { size="Component memory extracted from v$memory_dynamic_components in Oracle." }
request = '''
SELECT component, current_size as "size"
FROM V$MEMORY_DYNAMIC_COMPONENTS
UNION
SELECT name, bytes as "size"
FROM V$SGAINFO
WHERE name in ('Free SGA Memory Available', 'Redo Buffers', 'Maximum SGA Size')
'''

[[metric]]
context = "activity"
metricsdesc = { value="Generic counter metric from v$sysstat view in Oracle." }
fieldtoappend = "name"
request = '''
SELECT name, value
FROM V$SYSSTAT WHERE name IN (
  'execute count',
  'user commits', 'user rollbacks',
  'db block gets from cache', 'consistent gets from cache', 'physical reads cache', /* CACHE */
  'redo log space requests'
 )
 '''

[[metric]]
context = "system_event"
labels = [ "event", "wait_class" ]
request = '''
SELECT
  event, wait_class,
  total_waits, time_waited
FROM V$SYSTEM_EVENT
'''
[metric.metricsdesc]
  total_waits= "Total number of waits for the event as per V$SYSTEM_EVENT in Oracle."
  time_waited= "Total time waited for the event (in hundredths of seconds) as per V$SYSTEM_EVENT in Oracle."

This page describes how to set up a CloudWatch exporter in order to gather AWS metrics through the Prometheus provider. This is especially useful to monitor system metrics when you don’t have direct SSH access to AWS resources like EC2 Instances or if you want to gather AWS-specific metrics not available in the guest OS.

AWS policies

In order to fetch metrics fromCloudWatch, the exporter requires an IAM user or role with the following privileges:

• cloudwatch:GetMetricData

• cloudwatch:GetMetricStatistics

• cloudwatch:ListMetrics

• tag:GetResources

You can assign AWS-managed policies CloudWatchReadOnlyAccess and ResourceGroupsandTagEditorReadOnlyAccess to the desired user to enable these permissions.

Exporter configuration

The CloudWatch exporter repository is available on the official project page. It requires a minimal configuration to fetch metrics from the desired AWS instances. Below is a short list of the parameters needed for a minimal configuration:

• region: AWS region of the monitored resource

• metrics: a list of objects containing filters for the exported metrics

  • aws_namespace: the namespace of the monitored resource

  • aws_metric_name: the name of the AWS metric to fetch

  • aws_dimensions: the dimension to expose as labels

  • aws_dimension_select: the dimension to filter over

  • aws_statistics: the list of metric statistics to expose

  • aws_tag_select: optional tags to filter on

    • tag_selections: map containing the list of values to select for each tag

    • resource_type_selection: resource type to fetch the tags from (see: Resource Types)

    • resource_id_dimension: dimension to use for the resource id (see: Resource Types)

For a complete list of possible values for namespaces, metrics, and dimensions please refer to the official AWS CloudWatch User Guide.

Notice: AWS bills CloudWatch usage in batches of 1 million requests, where every metric counts as a single request. To avoid unnecessary expenses configure only the metrics you need.

region: us-east-2
metrics:
  - aws_namespace: AWS/EC2
    aws_metric_name: CPUUtilization
    aws_statistics: [Average]
    aws_dimensions: [InstanceId]
    # aws_dimension_select:
    #   InstanceId: [i-XXXXXXXXXXXXXXXXX]
    aws_tag_select:
      tag_selections:
        Name: [server1, server2]
      resource_type_selection: ec2:instance
      resource_id_dimension: InstanceId

  - aws_namespace: AWS/EC2
    aws_metric_name: NetworkIn
    aws_statistics: [Sum]
    aws_dimensions: [InstanceId]
    # aws_dimension_select:
    #   InstanceId: [i-XXXXXXXXXXXXXXXXX]
    aws_tag_select:
      tag_selections:
        Name: [server1, server2]
      resource_type_selection: ec2:instance
      resource_id_dimension: InstanceId

  - aws_namespace: AWS/EC2
    aws_metric_name: NetworkOut
    aws_statistics: [Sum]
    aws_dimensions: [InstanceId]
    # aws_dimension_select:
    #   InstanceId: [i-XXXXXXXXXXXXXXXXX]
    aws_tag_select:
      tag_selections:
        Name: [server1, server2]
      resource_type_selection: ec2:instance
      resource_id_dimension: InstanceId

  - aws_namespace: AWS/EC2
    aws_metric_name: NetworkPacketsIn
    aws_statistics: [Sum]
    aws_dimensions: [InstanceId]
    # aws_dimension_select:
    #   InstanceId: [i-XXXXXXXXXXXXXXXXX]
    aws_tag_select:
      tag_selections:
        Name: [server1, server2]
      resource_type_selection: ec2:instance
      resource_id_dimension: InstanceId

  - aws_namespace: AWS/EC2
    aws_metric_name: NetworkPacketsOut
    aws_statistics: [Sum]
    aws_dimensions: [InstanceId]
    # aws_dimension_select:
    #   InstanceId: [i-XXXXXXXXXXXXXXXXX]
    aws_tag_select:
      tag_selections:
        Name: [server1, server2]
      resource_type_selection: ec2:instance
      resource_id_dimension: InstanceId

  - aws_namespace: AWS/EC2
    aws_metric_name: CPUCreditUsage
    aws_statistics: [Sum]
    aws_dimensions: [InstanceId]
    # aws_dimension_select:
    #   InstanceId: [i-XXXXXXXXXXXXXXXXX]
    aws_tag_select:
      tag_selections:
        Name: [server1, server2]
      resource_type_selection: ec2:instance
      resource_id_dimension: InstanceId

  - aws_namespace: AWS/EC2
    aws_metric_name: CPUCreditBalance
    aws_statistics: [Average]
    aws_dimensions: [InstanceId]
    # aws_dimension_select:
    #   InstanceId: [i-XXXXXXXXXXXXXXXXX]
    aws_tag_select:
      tag_selections:
        Name: [server1, server2]
      resource_type_selection: ec2:instance
      resource_id_dimension: InstanceId

  - aws_namespace: AWS/EC2
    aws_metric_name: EBSReadOps
    aws_statistics: [Sum]
    aws_dimensions: [InstanceId]
    # aws_dimension_select:
    #   InstanceId: [i-XXXXXXXXXXXXXXXXX]
    aws_tag_select:
      tag_selections:
        Name: [server1, server2]
      resource_type_selection: ec2:instance
      resource_id_dimension: InstanceId

  - aws_namespace: AWS/EC2
    aws_metric_name: EBSWriteOps
    aws_statistics: [Sum]
    aws_dimensions: [InstanceId]
    # aws_dimension_select:
    #   InstanceId: [i-XXXXXXXXXXXXXXXXX]
    aws_tag_select:
      tag_selections:
        Name: [server1, server2]
      resource_type_selection: ec2:instance
      resource_id_dimension: InstanceId

  - aws_namespace: AWS/EC2
    aws_metric_name: EBSReadBytes
    aws_statistics: [Sum]
    aws_dimensions: [InstanceId]
    # aws_dimension_select:
    #   InstanceId: [i-XXXXXXXXXXXXXXXXX]
    aws_tag_select:
      tag_selections:
        Name: [server1, server2]
      resource_type_selection: ec2:instance
      resource_id_dimension: InstanceId

  - aws_namespace: AWS/EC2
    aws_metric_name: EBSWriteBytes
    aws_statistics: [Sum]
    aws_dimensions: [InstanceId]
    # aws_dimension_select:
    #   InstanceId: [i-XXXXXXXXXXXXXXXXX]
    aws_tag_select:
      tag_selections:
        Name: [server1, server2]
      resource_type_selection: ec2:instance
      resource_id_dimension: InstanceId

  - aws_namespace: AWS/EC2
    aws_metric_name: EBSIOBalance%
    aws_statistics: [Average]
    aws_dimensions: [InstanceId]
    # aws_dimension_select:
    #   InstanceId: [i-XXXXXXXXXXXXXXXXX]
    aws_tag_select:
      tag_selections:
        Name: [server1, server2]
      resource_type_selection: ec2:instance
      resource_id_dimension: InstanceId

  - aws_namespace: AWS/EC2
    aws_metric_name: EBSByteBalance%
    aws_statistics: [Average]
    aws_dimensions: [InstanceId]
    # aws_dimension_select:
    #   InstanceId: [i-XXXXXXXXXXXXXXXXX]
    aws_tag_select:
      tag_selections:
        Name: [server1, server2]
      resource_type_selection: ec2:instance
      resource_id_dimension: InstanceId

The suggested deployment mode for the exporter is through a Docker image. The following snippet provides a command line example to run the container (remember to provide your AWS credentials if needed and the path of the configuration file):

docker run -d --name cloudwatch_exporter \
  -p 9106:9106 \
  -v $(pwd)/cloudwatch-exporter.yaml:/config/config.yml \
  -e AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID} -e AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY} \
  prom/cloudwatch-exporter

You can refer to the official guide for more details or alternative deployment modes.

Prometheus configuration

In order to scrape the newly created exporter add a new job to the configuration file. You will also need to define some relabeling rules in order to add the instance label required by Akamas to properly filter the incoming metrics. In the example below the instance label is copied from the instance’s Name tag:

Notice: AWS bills CloudWatch usage in batches of 1 million requests, where every metric counts as a single request. To avoid unnecessary expenses configure an appropriate scraping interval.

scrape_configs:
  - job_name: cloudwatch_exporter
    scrape_interval: 60s
    scrape_timeout: 30s
    static_configs:
      - targets: [cloudwatch_exporter:9106]
    metric_relabel_configs:
      - source_labels: [tag_Name]
        regex: '(.+)'
        target_label: instance

Additional workflow task

Once you configured the exporter in the Prometheus configuration you can start to fetch metrics using the Prometheus provider. The following sections describe some scripts you can add as tasks in your workflow.

Wait for metrics

It’s worth noting that CloudWatch may require some minutes to aggregate the stats according to the configured granularity, causing the telemetry provider to fail while trying to fetch data points not available yet. To avoid such issues you can add at the end of your workflow a task using an Executor operator to wait for the CloudWatch metrics to be ready. The following script is an example of implementation:

METRIC=aws_rds_cpuutilization_sum   # metric to check for
DELAY_SEC=15
RETRIES=60

NOW=`date +'%FT%T.%3NZ'`

for i in `seq $RETRIES`; do
  sleep $DELAY_SEC
  curl -sS "http://prometheus_host/api/v1/query?query=${METRIC}&time=${NOW}" | jq -ce '.data.result[]' && exit 0
done

exit 255

Start/stop the exporter as needed

Since Amazon bills your CloudWatch queries is wise to run the exporter only when needed. The following script allows you to manage the exporter from the workflow by adding the following tasks:

• start the container right before the beginning of the load test (command: bash script.sh start)

• stop the container after the metrics publication, as described in the previous section (command: bash script.sh stop).

#!/bin/bash

set -e

CMD=$1
CONT_NAME=cloudwatch_exporter

stop_cont() {
  [ -z `docker ps -aq -f "name=${CONT_NAME}"` ] || (echo Removing ${CONT_NAME} && docker rm -f ${CONT_NAME})
}

case $CMD in
  stop|remove)
    stop_cont
    ;;

  start)
    stop_cont

    AWS_ACCESS_KEY_ID=`awk 'BEGIN { FS = "=" } /aws_access_key_id/ {print $2 }' ~/.aws/credentials | tr -d '[:space:]'`
    AWS_SECRET_ACCESS_KEY=`awk 'BEGIN { FS = "=" } /aws_secret_access_key/ {print $2 }' ~/.aws/credentials | tr -d '[:space:]'`

    echo Starting container $CONT_NAME
    docker run -d --name $CONT_NAME \
      -p 9106:9106 \
      -v ~/oracle-database/utils/cloudwatch-exporter.yaml:/config/config.yml \
      -e AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID} -e AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY} \
      prom/cloudwatch-exporter
    ;;

    *)
    echo Unrecognized option $CMD
    exit 255
    ;;
esac

Custom Configuration file

The example below is the Akamas-supported configuration, fetching metrics of EC2 instances named server1 and server2.

region: us-east-2
metrics:
  - aws_namespace: AWS/EC2
    aws_metric_name: CPUUtilization
    aws_statistics: [Average]
    aws_dimensions: [InstanceId]
    # aws_dimension_select:
    #   InstanceId: [i-XXXXXXXXXXXXXXXXX]
    aws_tag_select:
      tag_selections:
        Name: [server1, server2]
      resource_type_selection: ec2:instance
      resource_id_dimension: InstanceId

  - aws_namespace: AWS/EC2
    aws_metric_name: NetworkIn
    aws_statistics: [Sum]
    aws_dimensions: [InstanceId]
    # aws_dimension_select:
    #   InstanceId: [i-XXXXXXXXXXXXXXXXX]
    aws_tag_select:
      tag_selections:
        Name: [server1, server2]
      resource_type_selection: ec2:instance
      resource_id_dimension: InstanceId

  - aws_namespace: AWS/EC2
    aws_metric_name: NetworkOut
    aws_statistics: [Sum]
    aws_dimensions: [InstanceId]
    # aws_dimension_select:
    #   InstanceId: [i-XXXXXXXXXXXXXXXXX]
    aws_tag_select:
      tag_selections:
        Name: [server1, server2]
      resource_type_selection: ec2:instance
      resource_id_dimension: InstanceId

  - aws_namespace: AWS/EC2
    aws_metric_name: NetworkPacketsIn
    aws_statistics: [Sum]
    aws_dimensions: [InstanceId]
    # aws_dimension_select:
    #   InstanceId: [i-XXXXXXXXXXXXXXXXX]
    aws_tag_select:
      tag_selections:
        Name: [server1, server2]
      resource_type_selection: ec2:instance
      resource_id_dimension: InstanceId

  - aws_namespace: AWS/EC2
    aws_metric_name: NetworkPacketsOut
    aws_statistics: [Sum]
    aws_dimensions: [InstanceId]
    # aws_dimension_select:
    #   InstanceId: [i-XXXXXXXXXXXXXXXXX]
    aws_tag_select:
      tag_selections:
        Name: [server1, server2]
      resource_type_selection: ec2:instance
      resource_id_dimension: InstanceId

  - aws_namespace: AWS/EC2
    aws_metric_name: CPUCreditUsage
    aws_statistics: [Sum]
    aws_dimensions: [InstanceId]
    # aws_dimension_select:
    #   InstanceId: [i-XXXXXXXXXXXXXXXXX]
    aws_tag_select:
      tag_selections:
        Name: [server1, server2]
      resource_type_selection: ec2:instance
      resource_id_dimension: InstanceId

  - aws_namespace: AWS/EC2
    aws_metric_name: CPUCreditBalance
    aws_statistics: [Average]
    aws_dimensions: [InstanceId]
    # aws_dimension_select:
    #   InstanceId: [i-XXXXXXXXXXXXXXXXX]
    aws_tag_select:
      tag_selections:
        Name: [server1, server2]
      resource_type_selection: ec2:instance
      resource_id_dimension: InstanceId

  - aws_namespace: AWS/EC2
    aws_metric_name: EBSReadOps
    aws_statistics: [Sum]
    aws_dimensions: [InstanceId]
    # aws_dimension_select:
    #   InstanceId: [i-XXXXXXXXXXXXXXXXX]
    aws_tag_select:
      tag_selections:
        Name: [server1, server2]
      resource_type_selection: ec2:instance
      resource_id_dimension: InstanceId

  - aws_namespace: AWS/EC2
    aws_metric_name: EBSWriteOps
    aws_statistics: [Sum]
    aws_dimensions: [InstanceId]
    # aws_dimension_select:
    #   InstanceId: [i-XXXXXXXXXXXXXXXXX]
    aws_tag_select:
      tag_selections:
        Name: [server1, server2]
      resource_type_selection: ec2:instance
      resource_id_dimension: InstanceId

  - aws_namespace: AWS/EC2
    aws_metric_name: EBSReadBytes
    aws_statistics: [Sum]
    aws_dimensions: [InstanceId]
    # aws_dimension_select:
    #   InstanceId: [i-XXXXXXXXXXXXXXXXX]
    aws_tag_select:
      tag_selections:
        Name: [server1, server2]
      resource_type_selection: ec2:instance
      resource_id_dimension: InstanceId

  - aws_namespace: AWS/EC2
    aws_metric_name: EBSWriteBytes
    aws_statistics: [Sum]
    aws_dimensions: [InstanceId]
    # aws_dimension_select:
    #   InstanceId: [i-XXXXXXXXXXXXXXXXX]
    aws_tag_select:
      tag_selections:
        Name: [server1, server2]
      resource_type_selection: ec2:instance
      resource_id_dimension: InstanceId

  - aws_namespace: AWS/EC2
    aws_metric_name: EBSIOBalance%
    aws_statistics: [Average]
    aws_dimensions: [InstanceId]
    # aws_dimension_select:
    #   InstanceId: [i-XXXXXXXXXXXXXXXXX]
    aws_tag_select:
      tag_selections:
        Name: [server1, server2]
      resource_type_selection: ec2:instance
      resource_id_dimension: InstanceId

  - aws_namespace: AWS/EC2
    aws_metric_name: EBSByteBalance%
    aws_statistics: [Average]
    aws_dimensions: [InstanceId]
    # aws_dimension_select:
    #   InstanceId: [i-XXXXXXXXXXXXXXXXX]
    aws_tag_select:
      tag_selections:
        Name: [server1, server2]
      resource_type_selection: ec2:instance
      resource_id_dimension: InstanceId

To create an instance of the CSV provider, build a YAML file (instance.yml in this example) with the definition of the instance:

# CSV Telemetry Provider Instance
provider: CSV File
config:
 address: host1.example.com
 authType: password
 username: akamas
 auth: akamas
 remoteFilePattern: /monitoring/result-*.csv
 componentColumn: COMPONENT
 timestampColumn: TS
 timestampFormat: YYYY-MM-dd'T'HH:mm:ss
metrics:
 - metric: cpu_util
   datasourceMetric: user%

Then you can create the instance for the system using the Akamas CLI:

akamas create telemetry-instance instance.yml system

timestampFormat format

Regarding the timestamp format, please notice that while the week-year format YYYY is compliant with the ISO-8601 specification, but you should replace it with the year-of-era format yyyy if you are specifying a timestampFormat different from the ISO one. For example:

• Correct: yyyy-MM-dd HH:mm:ss

• Wrong: YYYY-MM-dd HH:mm:ss

You can find detailed information on timestamp patterns in the Patterns for Formatting and Parsing section on the DateTimeFormatter (Java Platform SE 8) page.

Configuration options

When you create an instance of the CSV provider, you should specify some configuration information to allow the provider to correctly extract and process metrics from your CSV files.

You can specify configuration information within the config part of the YAML of the instance definition.

Required properties

• address - a URL or IP identifying the address of the host where CSV files reside

• username - the username used when connecting to the host

• authType - the type of authentication to use when connecting to the file host; either password or key

• auth - the authentication credential; either a password or a key according to authType. When using keys, the value can either be the value of the key or the path of the file to import from

• remoteFilePattern - a list of remote files to be imported

Optional properties

• protocol - the protocol to use to retrieve files; either scp or sftp. Default is scp

• fieldSeparator - the character used as a field separator in the csv files. Default is ,

• componentColumn - the header of the column containing the name of the component. Default is COMPONENT

• timestampColumn - the header of the column containing the timestamp. Default is TS

• timestampFormat - the format of the timestamp (e.g. yyyy-MM-dd HH:mm:ss zzz). Default is YYYY-MM-ddTHH:mm:ss

You should also specify the mapping between the metrics available in your CSV files and those provided by Akamas. This can be done in the metrics section of the telemetry instance configuration. To map a custom metric you should specify at least the following properties:

• metric - the name of a metric in Akamas

• datasourceMetric - the header of a column that contains the metric in the CSV file

The provider ignores any column not present as datasourceMetric in this section.

The sample configuration reported in this section would import the metric cpu_util from CSV files formatted as in the example below:

TS,                   COMPONENT,  user%
2020-04-17T09:46:30,  host,       20
2020-04-17T09:46:35,  host,       23
2020-04-17T09:46:40,  host,       32
2020-04-17T09:46:45,  host,       21

Telemetry instance reference

The following represents the complete configuration reference for the telemetry provider instance.

provider: CSV File            # this is an instance of the Csv provider
config:
 address: host1.example.com   # the adress of the host with the csv files
 port: 22                     # the port used to connect
 authType: password           # the authentication method
 username: akamas             # the username used to connect
 auth: akamas                 # the authentication credential
 protocol: scp                # the protocol used to retrieve the file
 fieldSeparator: ","          # the character used as field separator in the csv files
 remoteFilePattern: /monitoring/result-*.csv    # the path of the csv files to import
 componentColumn: COMPONENT                     # the header of the column with component names
 timestampColumn: TS                            # the header of the column with the time stamp
 timestampFormat: YYYY-mm-ddTHH:MM:ss         # the format of the timestamp
metrics:
 - metric: cpu_util                             # the name of the Akamas metric
   datasourceMetric: user%                      # the header of the column with the original metric
   staticLabels:
    mode: user                                  # (optional) additional labels to add to the metric

The following table reports the configuration reference for the config section

The following table reports the configuration reference for the metrics section

Use cases

Here you can find common use cases addressed by this provider.

Linux SAR

In this use case, you are going to import some metrics coming from SAR, a popular UNIX tool to monitor system resources. SAR can export CSV files in the following format.

hostname, interval,     timestamp, 		        %user,	%system,      %memory
machine1, 600,		2018-08-07 06:45:01 UTC,	30.01,	20.77,		96.21
machine1, 600,		2018-08-07 06:55:01 UTC,	40.07,	13.00,		84.55
machine1, 600,		2018-08-07 07:05:01 UTC,	5.00,	90.55,		89.23

Note that the metrics are percentages (between 1 and 100), while Akamas accepts percentages as values between 0 and 1, therefore each metric in this configuration has a scale factor of 0.001.

You can import the two CPU metrics and the memory metric from a SAR log using the following telemetry instance configuration.

provider: CSV File
config:
  remoteFilePattern: /csv/sar.csv
  address: 127.0.0.1
  port: 22
  username: user123
  auth: password123
  authType: password
  protocol: scp
  componentColumn: hostname
  timestampColumn: timestamp
  timestampFormat: yyyy-MM-dd HH:mm:ss zzz
metrics:
- metric: cpu_util
  datasourceMetric: %user
  scale: 0.001
  staticLabels:
    mode: user
- metric: cpu_util
  datasourceMetric: %system
  scale: 0.001
  staticLabels:
    mode: system
- metric: mem_util
  scale: 0.001
  datasourceMetric: %memory

Using the configured instance, the CSV File provider will perform the following operations to import the metrics:

1. Retrieve the file "/csv/sar.csv" from the server "127.0.0.1" using the SCP protocol authenticating with the provided password.

2. Use the column hostname to lookup components by name.

3. Use the column timestamp to find the timestamps of the samples (that is expected to be in the format specified by timestampFormat).

4. Collect the metrics (two with the same name, but different labels, and one with a different name):

   • cpu_util: in the CSV file is in the column %user and attach to its samples the label "mode" with value "user".

   • cpu_util: in the CSV file is in the column %system and attach to its samples the label "mode" with value "system".

   • mem_util: in the CSV file is in the column %memory.

Supported versions

• Dynatrace SaaS or Managed version 1.187 or later

  • Versions < 2.0.0 are compatible with Akamas until version 1.8.0

  • Versions >= 2.0.0 are compatible with Akamas from version 1.9.0

Supported component types

• Linux

  • Ubuntu-16.04, Rhel-7.6

• JVM

  • java-openjdk-8, java-openjdk-11

  • java-ibm-j9vm-6, java-ibm-j9vm-8, java-eclipse-openj9-11

• Web Application

• Kubernetes and Docker

Refer to Dynatrace provider metrics mapping to see how component-types metrics are extracted by this provider.

Prerequisites

• a valid Dynatrace license

• Dynatrace OneAgent installed on the servers where the Dynatrace entities to be monitored are running

• Connectivity between:

  • Akamas server and Dynatrace server over port 443 (if Dynatrace is deployed on-premises)

  • Akamas server and internet (over https) if Dynatrace is managed as a SaaS platform

• URL (+ port if it is not the default one) of your Dynatrace server (SaaS or Managed)

• API token from your Dynatrace server (Saas or Managed) with the rights to "Access problems and event feed, metrics, and topology" - see more details here

• A Dynatrace user belonging to the group "Monitoring viewer", which allows access to the environment in read-only mode, without being able to change settings, download or install OneAgent

Permissions

The Dynatrace provider needs a Dynatrace API token with the following privileges:

• metrics.read (Read entities)

• entities.read (Read metrics)

• DataExport (Access problem and event feed, metrics, and topology)

• DataImport (Data ingest, e.g.: metrics and events)

• ReadSyntheticData (Read synthetic monitors, locations, and nodes)

To generate an API Token for your Dynatrace installation you can follow these steps.

Component configuration

To map metrics collected from Dynatrace to Akamas component, the Dynatrace provider looks up some properties in the components of a system grouped under dynatrace.

These properties give you access to different strategies to map Akamas components onto Dynatrace entities:

• Map by id

• Map by name

• Map by tags

Map by id

You can map a component to a Dynatrace entity by leveraging the unique id of the entity, which you should put under the id property in the component:

name: MyComponent
properties:
 dynatrace:
  id: HOST-12345YUAB1

You can find the id of a Dynatrace entity by looking at the URL of a Dynatrace dashboard relative to the entity. Watch out that the "host" key is valid only for Linux components, other components (e.g. the JVM) require to drill down into the host entities to get the PROCESS_GROUP_INSTANCE or PROCESS_GROUP id

Map by name

You can map a component to a Dynatrace entity by leveraging the entity’s display name which you should put under the name property in the component definition:

name: MyComponent
properties:
 dynatrace:
  name: host-1

Map by tags

You can map a component to a Dynatrace entity by leveraging Dynatrace tags that match the entity, tags which you should put under the tags property in the component definition. If multiple tags are specified all instances matching any of the specified tags will be selected.

name: MyComponent
properties:
 dynatrace:
  tags:
     environment: test
     [AWS]dynatrace-monitored: true

In the case of a key-only tag, the example above would be:

name: MyComponent
properties:
 dynatrace:
  tags:
     environment: test
     myKeyOnlyTag: ""

Improve component mapping with type

You can improve the matching of components with Dynatrace by adding a type property in the component definition, this property will help the Provider match only those Dynatrace entities of the given type.

name: MyComponent
properties:
 dynatrace:
  type: service     # here the type helps the mapping by tags by filtering down entities that are only services
  tags:
     environment: test
     "[AWS]dynatrace-monitored": true

The type of an entity can be retrieved from the URL of the entity’s dashboard

Available entities types can be retrieved, from your Dynatrace instance, with the following command:

curl 'https://<Your Dynatrace host>/api/v2/entityTypes/?pageSize=500' --header 'Authorization: Api-Token <API-TOKEN>'

Kubernetes specific properties

A set of Kubernetes-specific properties can be used to allow users to retrieve data related to the monitored Kubernetes clusters.

Please note, that the property type is required to retrieve Kubernetes entities. Currently, the supported types in Dynatrace are the following

The following Kubernetes object can be retrieved from Dynatrace.

Container

The following properties are supported for containers:

Example

dynatrace:
  type: CONTAINER_GROUP_INSTANCE
  kubernetes:
    namespace: boutique
    containerName: server
    basePodName: ak-frontend-*

Pod

The following properties are supported for pods

Example

dynatrace:
  type: CLOUD_APPLICATION_INTSTANCe
  namePrefix: ak-frontend-
  kubernetes:
    state: RUNNING
    labels:
      app: ak-frontend
      product: hipstershop

The LoadRunner provider collects metrics generated by a LoadRunner instance (converted to their JSON format and placed in CIFS network share) and makes them available to Akamas.

Prerequisites

This section provides the minimum requirements that you should match before using the LoadRunner telemetry provider.

Supported versions

• Micro Focus LoadRunner 12.60 or 2020

Network requirements

• The network share is reachable at port 445/TCP

• The network share is reachable at port 139/UDP

Permissions (optional)

• Username, domain (if required), and password of the network share.

• Read permission on the network share.

Supported component types

• Web Application

You can check LoadRunner provider metrics mapping to see how component-types metrics are extracted by this provider.

Setup the data source

The provider expects that its required data are on a CIFS share. If you are using the LoadRunner operator, please follow the instruction on here below on how to export LoadRunner results in a network share by setup a share on the LoadRunner Controller.

Share a Controller folder

To share a folder on Windows, please follow these steps:

1. Right-click on the folder, then select Properties

2. Go to Sharing tab, then select Advanced Sharing

3. In the opened window, enable Share this folder

4. In the "Share name" textbox type the name of the share. This is the name of the share over the network
5. Then click on Permissions, then Add

6. In the textbox type the name of the user or the group (with the domain if required) that you want to grant access to the share, then click OK
7. Select the added user (or group) and grant the required permissions
8. Click OK, OK, and then Close

Mount network share on the controller

1. Open "This PC" from the Start menu, then click on "Map network drive"
2. In the "Map Network Drive" window, select a suitable drive letter name and enter the remote folder path of the network share that has been given to you by your storage admin (it should be something with the format \\mycompanyshareserver.mycompany\foldername)
3. Make sure to check "Reconnect at sign-in" and "Connect using different credentials".

4. Click Finish

5. In the "Windows Security" window enter the username (with the domain, if required) and the password for the network share and check "Remember my credentials".

6. Click Ok

Components configuration

Akamas reasons in terms of a system to be optimized and in terms of parameters and metrics of components of that system. To understand the link between metrics collected from LoadRunner and a specific component, the LoadRunner provider looks up the property loadrunner in the components of a system:

# Specification for a component, whose metrics should be collected by the Prometheus Provider
name: "WebApplication1" # name of the component
description: "LoadRunner controller" # description of the component
properties:
  loadrunner: ""   # the presence of this property helps akamas discriminate metrics imported using loadrunner from the ones provided by other providers

The installed provider is shared with all users of your Akamas installation and can monitor many different systems, by configuring appropriate telemetry provider instances.

To create an instance of the Dynatrace provider, build a YAML file (instance.yml in this example) with the definition of the instance:

# Dynatrace Telemetry Provider Instance
provider: Dynatrace
config:
  url: https://wuy711522.live.dynatrace.com
  token: XbERgThisIsAnExampleToken

Then you can create the instance for the system using the Akamas CLI:

akamas create telemetry-instance instance.yml system

Configuration options

When you create an instance of the Dynatrace provider, you should specify some configuration information to allow the provider to correctly extract and process metrics from Dynatrace.

You can specify configuration information within the config part of the YAML of the instance definition.

Required properties

• url - URL of the Dynatrace installation API (see https://www.dynatrace.com/support/help/extend-dynatrace/dynatrace-api/ to retrieve the URL of your installation)

• token - A Dynatrace API Token with the proper permissions

Collect additional metrics

You can collect additional metrics with the Dynatrace provider by using the metrics field:

config:
  url: https://wuy71982.live.dynatrace.com
  token: XbERgkKeLgVfDI2SDwI0h
metrics:
- metric: "akamas_metric"                     # extra akamas metrics to monitor
  datasourceMetric: builtin:host:new_metric   # query to execute to extract the metric
  labels:
  - "method"      # the "method" label will be retained within akamas

Configure a proxy for Dynatrace

In the case in which Akamas cannot reach directly your Dynatrace installation, you can configure an HTTP proxy by using the proxy field:

config:
  url: https://wuy71982.live.dynatrace.com
  token: XbERgkKeLgVfDI2SDwI0h
  proxy:
    address: https://dynaproxy  # the URL of the HTTP proxy
    port: 9999                  # the port the proxy listens to

Telemetry instance reference

This section reports the complete reference for the definition of a telemetry instance.

provider: Dynatrace  # this is an instance of the <name> provider
config:
  url: https://wuy71982.live.dynatrace.com
  token: XbERgkKeLgVfDI2SDwI0h
  proxy:
    address: https://dynaproxy # the URL of the HTTP proxy
    port: 9999            # the port the proxy listens to
    username: myusername  # http basic auth username if necessary
    password: mypassword  # http basic auth password if necessary
  tags:
    Environment: Test       # dynatrace tags to be matched for every component

metrics:
- metric: "cpu_usage"  # this is the name of the metric within Akamas
  # The dynatrace metric name
  datasourceMetric: "builtin:host.cpu.usage"
  extras:
      mergeEntities: true  # instruct the telemetry to aggregate the metric over multiple entities
  aggregation: avg  # The aggregation to perform if the mergeEntities property is set to true

This table shows the reference for the config section within the definition of the Dynatrace provider instance:

Proxy options reference

This table reports the reference for the config → proxy section within the definition of the Dynatrace provider instance:

Metrics options reference