Edge Delta Dynatrace Destination

Configure the Dynatrace Node to send telemetry data to a Dynatrace endpoint using TLS.

  8 minute read  

Overview

The Dynatrace Node sends items to a Dynatrace destination over TLS. The items are processed and formatted to be compatible with Dynatrace.

This node requires Edge Delta agent version v1.28.0 or higher.

Example Configuration

nodes:
  - name: dynatrace
    type: dynatrace_output
    endpoint_type: manual
    environment_type: grail
    token: some-token
    endpoint: https://my-example-environment.live.dynatrace.com

Required Parameters

name

A descriptive name for the node. This is the name that will appear in pipeline builder and you can reference this node in the YAML using the name. It must be unique across all nodes. It is a YAML list element so it begins with a - and a space followed by the string. It is a required parameter for all nodes.

nodes:
  - name: <node name>
    type: <node type>

type: dynatrace_output

The type parameter specifies the type of node being configured. It is specified as a string from a closed list of node types. It is a required parameter.

nodes:
  - name: <node name>
    type: <node type>

token

The token parameter is a Dynatrace token that has “logs.ingest”, “metrics.ingest” and “openTelemetryTrace.ingest” scopes (based on usage).

nodes:
  - name: dynatrace
    type: dynatrace_output
    endpoint_type: manual
    environment_type: grail
    token: some-token
    endpoint: https://my-example-environment.live.dynatrace.com

environment_type

This parameter specifies the environment type that the destination uses. This information is used for validating and crafting outgoing requests. You can specify grail, classic, or other.

nodes:
  - name: dynatrace
    type: dynatrace_output
    endpoint_type: manual
    environment_type: grail
    token: some-token
    endpoint: https://my-example-environment.live.dynatrace.com

endpoint_type

This parameter specifies the endpoint type that the destination uses. This information is used for validating and crafting outgoing requests. You can specify cloud, active_gate, or manual.

nodes:
  - name: dynatrace
    type: dynatrace_output
    endpoint_type: manual
    environment_type: grail
    token: some-token
    endpoint: https://my-example-environment.live.dynatrace.com

Optional Parameters

environment_id

This parameter specifies the environment ID for SaaS and Active Gate offerings.

nodes:
  - name: dynatrace
    type: dynatrace_output
    endpoint_type: cloud
    environment_type: grail
    token: some-token
    endpoint: https://my-example-environment.live.dynatrace.com
    environment_id: some-id

active_gate_domain

This parameter specifies the domain where the Dynatrace ActiveGate proxy is accessible.

nodes:
  - name: dynatrace
    type: dynatrace_output
    endpoint_type: manual
    environment_type: grail
    token: some-token
    endpoint: https://my-example-environment.live.dynatrace.com

active_gate_port

This parameter specifies the Port where Dynatrace ActiveGate proxy is accessible.

nodes:
  - name: dynatrace
    type: dynatrace_output
    endpoint_type: manual
    environment_type: grail
    token: some-token
    endpoint: https://my-example-environment.live.dynatrace.com

endpoint

This parameter specifies the Dynatrace endpoint that will be used as a baseline for ingestion.

nodes:
  - name: dynatrace
    type: dynatrace_output
    endpoint_type: manual
    environment_type: grail
    token: some-token
    endpoint: https://my-example-environment.live.dynatrace.com

buffer_max_bytesize

The buffer_max_bytesize parameter configures the maximum byte size for total unsuccessful items. If the limit is reached, the remaining items are discarded until the buffer space becomes available. It is specified as a datasize.Size, has a default of 0 indicating no size limit, and it is optional.

nodes:
  - name: dynatrace
    type: dynatrace_output
    endpoint_type: manual
    environment_type: grail
    token: some-token
    endpoint: https://my-example-environment.live.dynatrace.com
    buffer_max_bytesize: 2048

buffer_path

The buffer_path parameter configures the path to store unsuccessful items. Unsuccessful items are stored there to be retried back (exactly once delivery). It is specified as a string and it is optional.

nodes:
  - name: dynatrace
    type: dynatrace_output
    endpoint_type: manual
    environment_type: grail
    token: some-token
    endpoint: https://my-example-environment.live.dynatrace.com
    buffer_path: <path to unsuccessful items folder>

buffer_ttl

The buffer_ttl parameter configures the time-to-Live for unsuccessful items, which indicates when to discard them. It is specified as a duration, has a default of 10m, and it is optional.

nodes:
  - name: dynatrace
    type: dynatrace_output
    endpoint_type: manual
    environment_type: grail
    token: some-token
    endpoint: https://my-example-environment.live.dynatrace.com
    buffer_ttl: 20m

tls

Configure TLS settings for secure connections to this destination. TLS is optional and typically used when connecting to endpoints that require encrypted transport (HTTPS) or mutual TLS.

YAML Configuration Example:

nodes:
  - name: <node name>
    type: <destination type>
    tls:
      <tls options>

Enable TLS

Enables TLS encryption for outbound connections to the destination endpoint. When enabled, all communication with the destination will be encrypted using TLS/SSL. This should be enabled when connecting to HTTPS endpoints or any service that requires encrypted transport. (YAML parameter: enabled)

Default: false

When to use: Enable when the destination requires HTTPS or secure connections. Always enable for production systems handling sensitive data, connections over untrusted networks, or when compliance requirements mandate encryption in transit.

YAML Configuration Example:

nodes:
  - name: <node name>
    type: <destination type>
    tls:
      enabled: true

Ignore Certificate Check

Disables TLS certificate verification, allowing connections to servers with self-signed, expired, or invalid certificates. This bypasses security checks that verify the server’s identity and certificate validity. (YAML parameter: ignore_certificate_check)

Default: false

When to use: Only use in development or testing environments with self-signed certificates. NEVER enable in production—this makes your connection vulnerable to man-in-the-middle attacks. For production with self-signed certificates, use ca_file or ca_path to explicitly trust specific certificates instead.

YAML Configuration Example:

nodes:
  - name: <node name>
    type: <destination type>
    tls:
      ignore_certificate_check: true  # Only for testing!

CA Certificate File

Specifies the absolute path to a CA (Certificate Authority) certificate file used to verify the destination server’s certificate. This allows you to trust specific CAs beyond the system’s default trusted CAs, which is essential when connecting to servers using self-signed certificates or private CAs. (YAML parameter: ca_file)

When to use: Required when connecting to servers with certificates signed by a private/internal CA, or when you want to restrict trust to specific CAs only. Choose either ca_file (single CA certificate) or ca_path (directory of CA certificates), not both.

YAML Configuration Example:

nodes:
  - name: <node name>
    type: <destination type>
    tls:
      ca_file: /certs/ca.pem

CA Certificate Path

Specifies a directory path containing one or more CA certificate files for verifying the destination server’s certificate. Use this when you need to trust multiple CAs or when managing CA certificates across multiple files. All certificate files in the directory will be loaded. (YAML parameter: ca_path)

When to use: Alternative to ca_file when you have multiple CA certificates to trust. Useful for environments with multiple private CAs or when you need to rotate CA certificates without modifying configuration. Choose either ca_file or ca_path, not both.

YAML Configuration Example:

nodes:
  - name: <node name>
    type: <destination type>
    tls:
      ca_path: /certs/ca-certificates/

Certificate File

Path to the client certificate file (public key) used for mutual TLS (mTLS) authentication with the destination server. This certificate identifies the client to the server and must match the private key. The certificate should be in PEM format. (YAML parameter: crt_file)

When to use: Required only when the destination server requires mutual TLS authentication, where both client and server present certificates. Must be used together with key_file. Not needed for standard client TLS connections where only the server presents a certificate.

YAML Configuration Example:

nodes:
  - name: <node name>
    type: <destination type>
    tls:
      crt_file: /certs/client-cert.pem
      key_file: /certs/client-key.pem

Private Key File

Path to the private key file corresponding to the client certificate. This key must match the public key in the certificate file and is used during the TLS handshake to prove ownership of the certificate. Keep this file secure with restricted permissions. (YAML parameter: key_file)

When to use: Required for mutual TLS authentication. Must be used together with crt_file. If the key file is encrypted with a password, also specify key_password. Only needed when the destination server requires client certificate authentication.

YAML Configuration Example:

nodes:
  - name: <node name>
    type: <destination type>
    tls:
      crt_file: /certs/client-cert.pem
      key_file: /certs/client-key.pem
      key_password: <password>  # Only if key is encrypted

Private Key Password

Password (passphrase) used to decrypt an encrypted private key file. Only needed if your private key file is password-protected. If your key file is unencrypted, omit this parameter. (YAML parameter: key_password)

When to use: Optional. Only required if key_file is encrypted/password-protected. For enhanced security, use encrypted keys in production environments. If you receive “bad decrypt” or “incorrect password” errors, verify the password matches the key file encryption.

YAML Configuration Example:

nodes:
  - name: <node name>
    type: <destination type>
    tls:
      crt_file: /certs/client-cert.pem
      key_file: /certs/encrypted-client-key.pem
      key_password: mySecurePassword123

Minimum TLS Version

Minimum TLS protocol version to use when connecting to the destination server. This enforces a baseline security level by refusing to connect if the server doesn’t support this version or higher. (YAML parameter: min_version)

Available versions:

  • TLSv1_0 - Deprecated, not recommended (security vulnerabilities)
  • TLSv1_1 - Deprecated, not recommended (security vulnerabilities)
  • TLSv1_2 - Recommended minimum for production (default)
  • TLSv1_3 - Most secure, use when destination supports it

Default: TLSv1_2

When to use: Set to TLSv1_2 or higher for production deployments. Only use TLSv1_0 or TLSv1_1 if connecting to legacy servers that don’t support newer versions, and be aware of the security risks. TLS 1.0 and 1.1 are officially deprecated.

YAML Configuration Example:

nodes:
  - name: <node name>
    type: <destination type>
    tls:
      min_version: TLSv1_2

Maximum TLS Version

Maximum TLS protocol version to use when connecting to the destination server. This is typically used to restrict newer TLS versions if compatibility issues arise with specific server implementations. (YAML parameter: max_version)

Available versions:

  • TLSv1_0
  • TLSv1_1
  • TLSv1_2
  • TLSv1_3

When to use: Usually left unset to allow the most secure version available. Only set this if you encounter specific compatibility issues with TLS 1.3 on the destination server, or for testing purposes. In most cases, you should allow the latest TLS version.

YAML Configuration Example:

nodes:
  - name: <node name>
    type: <destination type>
    tls:
      max_version: TLSv1_3