The Dynatrace provider collects metrics from Dynatrace and makes them available to Akamas.
This provider includes support for several technologies. In any case, custom queries can be defined to gather the desired metrics.
Dynatrace SaaS/Managed version 1.187 or later
Kubernetes and Docker
Web Application
Ubuntu-16.04, Rhel-7.6
java-openjdk-8, java-openjdk-11
java-ibm-j9vm-6, java-ibm-j9vm-8, java-eclipse-openj9-11
Refer to Dynatrace provider metrics mapping to see how component-types metrics are extracted by this provider.
This section provides the minimum requirements that you should match before using the Prometheus provider.
Dynatrace SaaS/Managed version 1.187 or later
A valid Dynatrace license
Dynatrace OneAgent installed on the servers where the Dynatrace entities to be monitored are running
Connectivity between Akamas and the Dynatrace server on port 443
A Dynatrace API token with the privileges described here.
The Dynatrace provider needs a Dynatrace API token with the following privileges:
metrics.read (Read metrics)
entities.read (Read entities and tags)
DataExport (Access problem and event feed, metrics, and topology)
ReadSyntheticData (Read synthetic monitors, locations, and nodes)
DataImport (Data ingest, e.g.: metrics and events). This permission is used to inform Dynatrace about configuration changes.
To generate an API Token for your Dynatrace installation you can follow these steps.
To instruct Akamas from which Dynatrace entities (e.g. Workloads, Services, Process Groups) metrics should be collected you can some specific properties on components.
Different strategies can be used to map Dynatrace entities to Akamas components:
By id
By name
By tags
By Kubernetes properties
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. This strategy is best used for long-lived instances whose ID does not change during the optimization such as Hosts, Process Groups or Services.
Here is an example of how to setup host monitoring via id:
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.
You can map a component to a Dynatrace entity by leveraging the entity’s display name. This strategy is similar to the map by id but provides a more friendly way to identify the mapped entity. Beware that id multiple entities in your Dynatrace installation share the same name they will all be mapped to the same component. The Dynatrace display name should be put under the name
property in the component definition:
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, instances matching any of the specified tags will be selected.
This sample configuration maps to the component all Dynatrace entities with tag environment: test
or [AWS]dynatrace-monitored: true
Dynatrace supports both key-value and key-only tags. Key-only tags can be specified as Key-value tags with an empty value as in the following example
You can map a component to a Dynatrace entity referring to a Kubernetes cluster (e.g. a Pod or a Container) by leveraging dedicated properties.
In order to properly identify the set of containers to be mapped, you can specify the following properties. Any container matching all the properties will be mapped to the component.
You can retrieve all the information to setup the properties on the top of the Dynatrace container dashboard.
The following example shows how to map a component to a container running in Kubernetes:
In order to properly identify the set of pods to be mapped, you can specify the following properties. Any pod matching all the properties will be mapped to the component.
If you need to further narrow your pod selection you can also specify a set of tags as described in the by tags. Note that tags for Kubernetes resources are called Labels in the Dynatrace dashboard.
Labels are specified as key-value in the Akamas configuration. In Dynatrace’s dashboard key and value are separated by a column (:
)
The following example shows how to map a component to a pod running in Kubernetes:
Please note, that when you are mapping components to Kubernetes entities the property type
is required to instruct Akamas on which type of entity you want to map.
Dynatrace maps Kubernetes entities to the following types:
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.
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:
Akamas property | Dynatrace property | Location |
---|---|---|
Akamas property | Dynatrace property | Location |
---|---|---|
Kubernetes type | Dynatrace type |
---|---|
namespace
Kubernetes namespace
Container dashboard
containerName
Kubernetes container name
Container dashboard
basePodName
Kubernetes base pod name
Container dashboard
state
State
Pod dashboard
namespace
Namespace
Pod dashboard
workload
Workload
Pod dashboard
Docker container
CONTAINER_GROUP_INSTANCE
Pod
CLOUD_APPLICATION_INSTANCE
Workload
CLOUD_APPLICATION
Namespace
CLOUD_APPLICATION_NAMESPACE
Cluster
KUBERNETES_CLUSTER
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:
Then you can create the instance for the system
using the Akamas CLI:
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.
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
You can collect additional metrics with the Dynatrace provider by using the metrics
field:
In the case in which Akamas cannot reach directly your Dynatrace installation, you can configure an HTTP proxy by using the proxy
field:
This section reports the complete reference for the definition of a telemetry instance.
This table shows the reference for the config
section within the definition of the Dynatrace provider instance:
This table reports the reference for the config
→ proxy
section within the definition of the Dynatrace provider instance:
This table reports the reference for the metrics
section within the definition of the Dynatrace provider instance. The section contains a collection of objects with the following properties:
This section reports common use cases addressed by this provider.
Check the Linux optimization pack for a list of all the system metrics available in Akamas.
As a first step to start extracting metrics from Dyntrace, generate your API token and make sure it has the right permissions.
As a second step, choose a strategy to map your Linux component (MyLinuxComponent) with the corresponding Dyntrace entity.
Let’s assume you want to map by id your Dynatrace entity, you can find the id in the URL bar of a Dyntrace dashboard of the entity:
Grab the id and add it to the Linux component definition:
You can leverage the name of the entity as well:
As a third and final step, once the component is all set, you can create an instance of the Dynatrace provider and then build your first studies:
Field | Type | Value restrictions | Required | Default Value | Description |
---|---|---|---|---|---|
Field | Type | Value restrictions | Required | Default value | Description |
---|---|---|---|---|---|
Field | Type | Value Restrictions | Required | Default value | Description |
---|---|---|---|---|---|
url
String
It should be a valid URL
Yes
The URL of the Dynatrace installation API (see the official reference)
token
String
Yes
The Dynatrace API Token the provider should use to interact with Dynatrace. The token should have sufficient permissions.
proxy
Object
See Proxy options reference
Yes
The specification of the HTTP proxy to use to communicate with Dynatrace.
pushEvents
String
true, false
No
true
If set to true the provider will inform dynatrace of the configuration change event which will be visible in the Dynatrace UI.
tags
Object
No
A set of global tags to match Dynatrace entities. The provider uses these tags to apply a default filtering of Dynatrace entities for every component.
address
String
It should be a valid URL
Yes
The URL of the HTTP proxy to use to communicate with the Dynatrace installation API
port
Number (integer)
1 <port
<65535
Yes
The port at which the HTTP proxy listens for connections
username
String
No
The username to use when authenticating against the HTTP proxy, if necessary
password
String
No
The username to use when authenticating against the HTTP proxy, if necessary
metric
String
It must be an Akamas metric
Yes
The name of an Akamas metric that should map to the new metric you want to gather
datasourceMetric
String
A valid Dynatrace metric
Yes
The Dynatrace query to use to extract metric
labels
Array of strings
-
No
The list of Dynatrace labels that should be retained when gathering the metric
staticLabels
Key-Value
-
No
Static labels that will be attached to metric samples