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:
By default, only requests at the service level are imported by the telemetry provider.
To import specific key requests you can follow these steps.
Currently only average response time, throughput, and error rate metrics are available for key requests.
Create a new component of type Web Application for each key request you want to import. This allows tracking response time, throughput, and error rates separately.
You can use the following yaml file as an example and customize it to suit your needs.
In order to instruct Akamas to import a specific key request you just need to change the id
field of the yaml above to the one that matches your key request on Dynatarce.
To obtain that ID open the analysis page for the request as in the example below, take note of the URL of the page, and look for the SERVICE_METHOD
keyword. The id is the one starting with SERVICE_METHOD
and ending before the character %14
Considering the example below the id is SERVICE_METHOD-D4BCC949D5DD656A
Create a telemetry instance for your system using the yaml specified below as an example and modify it to provide your Dynatrace account and credentials. This will instruct Akamas to use key request metrics instead of service metrics.
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
No
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
aggregation
String
No
avg
The aggregation to perform if the mergeEntities property under the extras section is set to true
extras
Object
Only the parameter mergeEntities
can be defined to either true
or false
No
Section for additional properties