• Home
  • Extend Dynatrace
  • Extensions 2.0
  • Extensions 2.0 concepts

Extensions 2.0 concepts

Familiarize yourself with basic Extensions 2.0 concepts to understand the framework and foundations of Extensions 2.0–based monitoring.

Architecture

Your extensions are executed by the Extension Execution Controller module (EEC), either remotely from the Environment ActiveGate or locally from OneAgent. As of now, only WMI extensions and Prometheus extensions can be run locally. More data sources are coming in later releases.

Watch this Performance Clinic episode to learn more about Extensions 2.0 framework architecture.

Extension Execution Controller

The Extension Execution Controller (EEC) is the Dynatrace component running your extensions. EEC can query your local data sources when run on OneAgent, or remote data sources when run from an ActiveGate. EEC doesn't need your attention at all; it's automatically installed and managed with each OneAgent and ActiveGate instance. EEC takes care of translating all the ingested data so that Dynatrace can leverage it for our Davis AI causation analysis. For more information, see Metric ingestion.

To run local extensions, you need to make sure EEC is enabled at the environment or selected host level.

Enable at the environment level
  1. In the Dynatrace menu, go to Settings and select Preferences > Extension Execution Controller.
  2. Turn on Enable Extension Execution Controller.
  3. Turn on Enable local PIPE/HTTP metric and Log Ingest API.
Enable for a single host
  1. In the Dynatrace menu, go to Hosts and select a host name to open the host overview page.
  2. Select More (…) > Settings.
  3. Select Extension Execution Controller.
  4. Turn on Enable Extension Execution Controller.

Performance profile

OneAgent version 1.243+

You can set your limit for resource consumption in the Performance profile option. By default, one data source process takes up to 2% CPU and 100 MB RAM in OneAgent and 5% CPU and 500 MB RAM in ActiveGate.

CPU and RAM limits are applied to the sum of the resources consumed by the EEC and all data source processes. There are two stages:

  • Soft limit—Every incoming test is rejected if consumption exceeds the limit. This stage applies to ActiveGate only.
  • Hard limit—The most recently started task is the first to be stopped and rejected.
    • For OneAgent, tasks are stopped and restarted with a delay. The delay time increases as the process restarts.
    • For ActiveGate, tasks are stopped and rejected until consumption is below the limit.
Change the Performance profile at the environment level
  1. In the Dynatrace menu, go to Settings and select Preferences > Extension Execution Controller.
  2. Set Performance profile to Default or High limits.
Change the Performance profile at the host level
  1. In the Dynatrace menu, go to Hosts and select a host name to open the host overview page.
  2. Set Performance profile to Default or High limits.
Change the Performance profile in the ActiveGate settings
  1. In the Dynatrace menu, go to Deployment Status > ActiveGates and expand the details of the designated ActiveGate.
  2. Go to Settings > Extension Execution Controller.
  3. Set Performance profile to Default or High limits.

ActiveGate group

An ActiveGate running an extension must belong to an ActiveGate group, because Dynatrace uses a group to instruct the extension where it should run. If you plan to use a single ActiveGate, assign it to a dedicated group. To assign an ActiveGate to a group, you can use the --set-group-name installation parameter for Linux and Windows during installation, or you can specify a group in your ActiveGate properties.

Data source type

Data source type is any technology that is generic enough for you to create an extension, but that doesn't conform to the observability standards ingested by Dynatrace out of the box, such as StatsD or Telegraf. Learn more about out-of-the-box Metric ingestion.

Currently, Dynatrace provides you with an interface to collect customized data from:

  • Prometheus
  • SNMP
  • WMI
  • SQL

Extensions 2.0 lifecycle

The Dynatrace API enables you to manage the full lifecycle of your Extensions 2.0 framework. For details and examples, see Manage Extensions 2.0 lifecycle.

Environment configuration

An environment configuration is a universal set of monitoring definitions tailored to the specifics of your data source, such as SNMP. The environment configuration is stored as the extension.yaml file uploaded to Dynatrace as a part of the extension ZIP package. An environment configuration defines:

  • The scope of collected data: which metrics are ingested and which dimensions they are to be assigned to.
  • The source from where the measurements and dimension values are extracted.
  • The data categorization into feature sets that you can select when defining the monitoring configuration.
  • How the metrics are constructed in the context of the metric ingestion protocol.
  • How the data collected by the extension is processed and presented by Dynatrace.

Your environment can store up to 10 extension versions, but only one version can be active at a time. You enable an extension by selecting a particular version of the environment configuration.

Without an environment configuration, an extension is invisible to the Dynatrace platform.

Monitoring configuration

A monitoring configuration is specific to the data source type you want to monitor. It defines:

  • From where the extension runs.
  • For remote extensions, the endpoints that the extension calls to collect data, as well as credentials to access them.
  • Connectivity properties, such as the timeout and number of retries in case of unsuccessful connection.
  • The values of variables that will be passed to the environment configuration when it's necessary to customize the extension for the specifics of your data source instance.

You can create up to 10 monitoring configurations based on a single environment configuration and each of them runs in parallel.

To start monitoring using the extension, you must use an API call to add a monitoring configuration that will instruct Dynatrace on how to collect data from your data source.

Without a monitoring configuration, an extension is visible in the Dynatrace platform, but it doesn't collect any data.

Extension package

Extensions are provided as a ZIP package containing only the extension.zip archive and the extension.zip.sig signature file. Extension packages with different contents are not accepted for upload. The maximum size of an extension package is 100 KB.

plaintext
bundle.zip │ extension.zip │ extension.zip.sig

Extension ZIP archive

The archive contains

  • The extension YAML file that defines the environment configuration
  • Assets

For example:

plaintext
extension.zip │ extension.yaml │ └───alerts │ | alert.json │ └───dashboards │ dashboard.json

Digital signature

Dynatrace verifies the authenticity of an extension using a digital signature file generated against the root certificate. Using the signature file, Dynatrace checks whether the extension is provided by a trusted source (Dynatrace or a Dynatrace customer). Learn how to sign your extension.

When you receive an extension from Dynatrace, it's already signed.

Dynatrace CLI

The Dynatrace CLI (dt-cli) is a command-line utility that assists you in developing, signing, and building extensions for the Dynatrace Extensions 2.0 framework.

It enables you to:

  • Build and sign extensions from source
  • Generate development certificates for extension signing
  • Generate CA certificates for development

For details, see Sign extension and the dt-cli project on GitHub.

Feature sets

Feature sets are categories into which you organize the data collected by the extension. Imagine an SNMP extension monitoring your network devices and collecting metrics related to NIC status, transport layer, and SNMP traps. This is reflected by metrics organization into related feature sets. Using a single extension, you can now customize your monitoring to limit a particular feature set to selected devices of your choice or identify ActiveGates with connectivity suited to devices capable of providing data specific to a feature set. It's all centrally managed from a single place, using a single API call. All metrics that aren't categorized into any feature set are considered to be default and are always reported.

Limits

Extension

EntityLimitDescription
Groups10For a single extension, you can define 10 groups.
Subgroups10Each group can contain 10 subgroups.
Dashboard10For a single extension, you can define 10 dashboards.
Alerts10For a single extension, you can define 10 custom events for alerting definitions.
Dimension25For each level (extension, group, subgroup), you can define up to 25 dimensions.
Metrics100For each level (extension, group, subgroup), you can define up to 100 metrics.
Activations10A single extension can run 10 monitoring configurations in parallel.
ZIP package size100 KBA single extension ZIP package size is limited to 100 KB.

Environment

EntityLimitDescription
Extensions250Your environment can manage up to 250 extensions.
Extension versions10Your environment can manage 10 versions of a single extension.

Monitoring configuration

EntityLimitDescription
ActiveGate groups10You can define up to 10 ActiveGate groups as the scope of a single monitoring configuration.
Number of extensions for an ActiveGate group10You can assign up to 10 extensions to be executed by a single ActiveGate group.
Devices100You can define up to 100 devices for a single monitoring configuration.

While it's possible to enter up to 100 devices in a single configuration, remote WMI monitoring is limited by the number of simultaneous WMI queries that can be executed on the internal Windows service that handles them.

Currently, the limit is 100 queries. For example, if your extension uses 5 queries, configuring more than 20 devices may cause performance issues and gaps in the monitoring data.

We are working on ways to get around this Windows limitation in future versions of the WMI data source.

Metric ingestion

EntityLimitDescription
Metric key length, characters250The total length of the metric key, including the prefix.
Dimension key length, characters100The total length of the dimension key.
Dimension value length, characters250The total length of the dimension value.
Number of dimensions per line50The number of dimensions in a single line of the payload.
Total number of possible metric keys per environment20,000The maximum number of metric keys that can be registered in Dynatrace.
Number of tuples per month per metric1,000,000The maximum number of tuples (unique metric-dimension key-dimension value-payload type combinations) for each metric key for the last 30 days.
Number of tuples per month for all custom metrics50,000,000The maximum number of tuples (unique metric-dimension key-dimension value-payload type combinations) for all custom metrics for the last 30 days.
Length of line, characters50,000The maximum length of a single line of the payload.

There's also a limit to the number of metrics that Dynatrace can ingest.

ChannelLimit

OneAgent metric API

Per minute per OneAgent instance:

OneAgent version 1.213 and earlier 1,000
OneAgent version 1.215+ 100,000

Metrics API v2

There's no limit to the metric number, but API throttling applies.

Resource consumption

In the following table:

  • Per instance shows the consumption volume for one data source in OneAgent and ActiveGate.
  • For all data source processes refers to the sum of the resources consumed by the EEC and all data source processes in OneAgent and ActiveGate. Each data source process represents a single extension activation assigned to a given host or an ActiveGate group.

OneAgent

Performance profileCPURAMCPU (Soft limit)RAM (Soft limit)CPU (Hard limit)RAM (Hard limit)

Per instance

For all data source processes

Default

2%

100 MB

N/A

N/A

5%

15%

High limits

5%

200 MB

N/A

N/A

15%

25%

ActiveGate

Performance profileCPURAMCPU (Soft limit)RAM (Soft limit)CPU (Hard limit)RAM (Hard limit)

Per instance

For all data source processes

Default

5%

500 MB

10%

20%

20%

30%

High limits

15%

700 MB

45%

30%

60%

40%

Access control

  • If you use the Hub, you need the classic Change monitoring settings permission in your group to modify the monitoring configuration.
  • If you authenticate the API with the tenant token, your token needs extensions.read and extensions.write permissions.