Try it free

CloudWatch metrics

  • Latest Dynatrace
  • Explanation

Dynatrace AWS Cloud Platform Monitoring allows the ingestion of any CloudWatch metric from any AWS service that sends metrics to a CloudWatch namespace.

Our metric ingest strategy allows you to quickly onboard with our recommended set of services and metrics.

At the same time, customization using advanced settings is possible during the onboarding process and after.

Ingest methods

Dynatrace AWS Cloud Platform Monitoring is designed to support two CloudWatch metrics ingest methods

API polling (poll-based)

This is a default metric ingest method, where Dynatrace calls the CloudWatch ListMetrics and GetMetricData APIs to validate, poll, and persist metrics.

Dynatrace authenticates and authorizes by assuming the created IAM monitoring role in the AWS account (cross-account role assumption).

The IAM monitoring role is created inside your account during connection creation. The role uses an external ID and a trust policy that is descoped to the Dynatrace account following the AWS security best practices.

Poller scheduling

Metric polling is scheduled every 5 minutes, evaluating a 5-minute window with a 7-minute delay. This means that a metric polling job that started at 9:00 AM will evaluate the data points for 8:48 AM-8:53 AM (a 7-minute delay + a 5-minute window).

The evaluation delay is necessary, as CloudWatch is an eventually consistent metrics API, and it takes multiple minutes to aggregate data points in order to produce fresh statistics.

Poller architecture

The Dynatrace metric poller was efficiently designed to poll metrics in the two stages:

  • After a metric list is compiled, the poller removes duplicated metrics from the list.

  • After the list of unique metrics is ready for polling, it calls the *ListMetrics* API. Only metrics which recently show data point updates are picked up for ingest.

This design aims to minimize calls to the *GetMetrics* API, potentially saving API Cost.

Streaming (push-based)

Coming soon

Amazon CloudWatch Metric Streams will be introduced in the future as a secondary metric ingest method.

CloudWatch metrics concepts

AWS services that require explicit configuration

See the detailed list of AWS services which are known to require additional configuration on the AWS side, in order to collect metrics, or detailed/additional extended metrics.

Native AWS services

A Dynatrace native (AWS) service is a first-class citizen service across our entire platform.

  • The service is backed by one or more purpose-built entities.
  • The service entity is enriched with rich cloud metadata.
  • The service and its related key cloud resources are represented as nodes and edges in the Dynatrace topology service.
  • Telemetry signals (metrics, logs, events, and topology) related to the service's AWS resources are designed to be linked to the respected Dynatrace entities.

"Linked" means that a Clouds Clouds resource with its linked telemetry is viewed as a single unified unit in context.

Default recommended AWS services

The default recommended AWS services represent a logical group of Dynatrace opinionated native AWS services and their corresponding recommended metrics.

When onboarding an AWS account following the Recommended flow, those AWS services are enabled for metric polling by default.

The recommended services list is constantly evaluated based on customer feedback and AWS innovation; we may change the list to reflect user feedback or to keep pace with AWS innovation.

Any changes are designed not to introduce breaking changes for existing AWS connections.

Metric collection sets

A metric collection set (MCS) is a group of metrics assigned to a native service. Once assigned, all metrics in this MCS will be scheduled for polling. Note that an MCS is known as a "FeatureSet" in our API.

Metric collection set types

Recommended (known as "essential" in our API)

An immutable list of opinionated Dynatrace metrics (per cloud native service). An optimal starting point.

Recommended + Custom

All Recommended MCS metrics plus the ability to add specific (user-defined) AWS metrics that are not included in the Recommended set type.

Auto-Discovery

All key metrics for a specific AWS service are auto-discovered and marked for polling. All metric dimension for this MCS are pre-set and are immutable.

The Auto-Discovery MCS has a high potential to:

  • Generate elevated Amazon CloudWatch API cost and Dynatrace high DPS consumption.
  • Lead to CloudWatch metrics high cardinality (extereme number of unique combinations of metric names and dimension values) leading to high cost and metric polling delay.

To learn the list of metrics for the Recommended MCS (per service), see native supported (service) AWS resources, CloudWatch metrics, dimensions combinations.

To learn the list Auto-Discovery metric dimensions (per service), see native supported (service) AWS resources, CloudWatch metrics, dimensions combinations.

Metric collection set characteristics

  • Metrics that are part of any MCS are designed to support our signals-in-context principle, allowing the following upstream use cases:

  • Clouds Clouds metrics in-context view (view the metrics, related to the AWS resource).

  • Enrichment of those metrics with cloud extended metadata as attributes (aws.account.id, aws.region, aws.tag, aws.tag.TagKeyName:value), allowing advanced Dynatrace platform use cases such as:

    • Dashboard with metrics/logs filtered by any supported attribute as dimension (AWS Account ID).
    • Linked metrics/logs can be viewed in context to their corresponding AWS resource (entity—node) using Clouds Clouds.

  • Only a single MCS can be assigned to a service at any given time.

Advanced metric ingest use cases

Any AWS metric

In certain use cases, it might be necessary to choose a fine-grained metrics ingest approach to cover use cases such as:

  • Ingest of any CloudWatch metrics from an AWS service that Dynatrace has yet to add to its native AWS service list.
  • Ingest of CloudWatch metrics that are not associated with an AWS Service (for example, AWS/Usage).

In the connection monitoring settings, turn on Ingest any AWS metrics and provide the required inputs. To determine the namespace and metric names, see the AWS documentation.

When possible, we highly recommend enabling our native AWS services with our built-in Metrics Collection Sets for metric ingest. They are closely maintained and curated by Dynatrace dedicated Cloud teams to maximize the platform experience.

Custom (user-instrumented) CloudWatch metrics

In certain use cases, it is required to ingest CloudWatch custom metrics instrumented by the AWS SDKs.

In the connection monitoring settings, turn on Ingest custom (user-instrumented) metrics and provide the required inputs.

Add a metric definition

When you enable Ingest any AWS metrics or Ingest custom (user-instrumented) metrics, you must provide the following inputs for each metric definition:

Namespace

The CloudWatch namespace that groups the metric. To find valid namespace values, see AWS services that publish CloudWatch metrics.

  • For any AWS metric, the namespace must start with the AWS/ prefix (for example, AWS/EC2 or AWS/S3).
  • For custom (user-instrumented) metrics, the namespace is defined by your application and does not use the AWS/ prefix (for example, MyApplication/Performance).
Metric name

The name of the CloudWatch metric within the namespace (for example, CPUUtilization).

Dimensions

A comma-separated list of dimension names that Dynatrace uses to scope metric polling (for example, InstanceId,AutoScalingGroupName). Dynatrace polls only the metrics that match these exact dimensions.

Statistics

Select one or more statistics from the dropdown list that Dynatrace retrieves for the metric. Available statistics include Average, Sum, Minimum, Maximum, and Sample Count.

Unit

Select the unit of the metric from the dropdown list.

Advanced metric ingest characteristics

CloudWatch metrics ingested via Ingest any AWS metrics or Ingest custom (user-instrumented) metrics:

  • Do not follow the metrics-in-context principle (are not linked to entities).
  • Will not be visible as nodes or edges in AWS topology.
  • Will not be enriched with cloud-native metadata (such as AWS Tags).
  • Will not adhere to the Clouds Clouds metrics in-context, hence will not be viewable in Clouds Clouds.

However, the following use cases will be supported for those metrics:

  • Depict in custom dashboards.
  • Define custom notification alerts.
  • Run DQL to query the metrics.

Limitations

  • The maximum number of user-provided AWS tags for enrichment is 20.
  • The maximum number of tag-based filtering is up to 5 for include and 5 for exclude.
Related tags
Infrastructure Observability