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.

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.

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.

plaintextcopydownload
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:

plaintextcopydownload
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

Environment

Monitoring configuration

Metric ingestion

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

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

ActiveGate

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.