Dash0 acquires Polar Signals

Last updated:

Scraping vs. Metric Streams

Compare the two ways to get CloudWatch metrics into Dash0 and switch from a metric stream to scraping without duplicate data.

Dash0 receives CloudWatch metrics in one of two ways:

  • Scraping: The AWS integration reads metrics from the CloudWatch API in your account. See Collect AWS CloudWatch Metrics.
  • Metric Streams: You run a CloudWatch Metric Stream and an Amazon Data Firehose delivery stream that push metrics to Dash0. See the AWS CloudWatch Metrics entry in the Integration Hub.

Both paths produce metrics with the same OpenTelemetry names, so dashboards and check rules that select metrics by name work with either one.

Compare the Two Paths

ScrapingMetric Streams
Infrastructure you runNone. Dash0 reads metrics with the integration's read-only IAM role.A metric stream and a Firehose delivery stream in every region
LatencyScrapes every 5 minutes, with a delay of at least 2 minutesNear real time
Dimension setsThe most specific set per metric and resource. Sets that restate a total are not collected.Every dimension set CloudWatch publishes
AWS costsCloudWatch API requests for the selected metricsMetric stream updates and Firehose delivery
SelectionNamespaces, metrics, resource tags, and regions on the Metrics tabNamespaces and metric names in the stream's configuration
PromQL metric namesWithout a unit, for example aws_lambda_invocations_sumWith the CloudWatch unit, for example aws_lambda_invocations_Count_sum

For current CloudWatch and Firehose prices, see Amazon CloudWatch pricing and Amazon Data Firehose pricing.

When to Use Which

Use scraping when you:

  • Want no infrastructure: Nothing to deploy, monitor, or update in each region.
  • Want fewer redundant series: Dash0 does not request series that only restate a total of other series. This lowers both your AWS bill and the volume Dash0 ingests.
  • Want control by tag: Collect metrics only for resources with specific AWS tags. See Filter AWS Metrics by Resource Tags.
  • Can accept periodic data: A few minutes of delay is fine for your dashboards and alerts.

Use Metric Streams when you:

  • Need the lowest latency: Alerts must react as soon as CloudWatch records a datapoint.
  • Need every dimension set: You query the total series directly, or you rely on dimension sets that scraping does not collect.
Note

Spam filters can drop redundant metric stream series when Dash0 ingests them. This reduces only what Dash0 stores. AWS still charges for streaming and delivering those series. Scraping avoids requesting them in the first place.

Switch From Metric Streams to Scraping

While both paths are active, Dash0 receives the same metrics twice. Keep the overlap short.

  1. Turn on scraping: Make sure the integration's CloudFormation stack has CloudWatch metrics scraping (EnableMetricsScraping) set to true. See Set Up AWS Integration.
  2. Select the same metrics: On the integration's Metrics tab, turn on the namespaces your metric stream includes, select their metrics, and click Save. See Collect AWS CloudWatch Metrics.
  3. Verify the scraped metrics: After the next scrapes, query a metric by its OpenTelemetry name, for example {otel_metric_name="aws.lambda.invocations"}. Scraped series are the ones without a unit in their PromQL name.
  4. Update PromQL queries: Dashboards and check rules that use unit-based PromQL names, such as aws_lambda_invocations_Count_sum, stop receiving data once the stream is gone. Change them to select metrics by otel_metric_name.
  5. Delete the metric stream: In the AWS console, delete the CloudWatch Metric Stream and its Firehose delivery stream in every region. If you created them from a CloudFormation stack, delete that stack instead.
Note

The AWS Lambda integration manages its own metric stream for the AWS/Lambda namespace through the integration's CloudFormation stack. The steps above apply to a metric stream you set up yourself, not to this one.

Further Reading