[DOCS-13133] Add FAQ entries for common AWS metric questions#35350
[DOCS-13133] Add FAQ entries for common AWS metric questions#35350
Conversation
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3750994c1d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| When transitioning from API polling to CloudWatch Metric Streams, there is an overlap period where both collection methods send data for the same metrics. This can cause metric values to appear doubled in Datadog. | ||
|
|
||
| To avoid this: | ||
| 1. After enabling Metric Streams, disable the corresponding AWS service namespaces from API polling in the [Metric Collection tab][1]. |
There was a problem hiding this comment.
This step tells users to manually disable API polling namespaces after enabling Metric Streams, but the Metric Streams guide says Datadog automatically stops polling streamed namespaces and explicitly advises leaving AWS integration settings unchanged (content/en/integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose.md lines 29-35). Following this FAQ instruction can break expected collection paths (for example delayed metrics like aws.s3.bucket_size_bytes/aws.billing.estimated_charges and metadata polling) in accounts that rely on the default mixed mode.
Useful? React with 👍 / 👎.
| |---|---| | ||
| | Amazon RDS (OS-level metrics) | Enable [Enhanced Monitoring][9] in the RDS console | | ||
| | Amazon S3 (Storage Lens metrics) | Configure [Storage Lens][10] in the S3 console | | ||
| | AWS billing metrics | Enable [Cost Explorer][11] in the AWS Billing console | |
There was a problem hiding this comment.
The table says AWS billing metrics require enabling Cost Explorer, but the existing AWS billing setup docs require enabling Billing metric collection and budgets:ViewBudget plus AWS billing metrics in CloudWatch (content/en/integrations/guide/monitor-your-aws-billing-details.md lines 13-16). Users who follow this new instruction alone may still not receive aws.billing.* metrics because it points to a different AWS feature than the integration prerequisites.
Useful? React with 👍 / 👎.
Preview links (active after the
|
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
Applied — replaced manual disable instruction with explanation that Datadog auto-detects streamed namespaces and stops polling; added note to leave settings unchanged to preserve metadata and delayed-metric collection in d794969. |
|
Applied — replaced Cost Explorer reference with the actual billing prerequisites (enable |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d794969df7
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| Datadog automatically detects streamed namespaces and stops polling them, so you do not need to manually disable API polling. Leave your configuration settings in the [AWS integration page][1] unchanged, as Datadog continues to use API polling to collect custom tags, metadata, and metrics that cannot be sent through Metric Streams (such as `aws.s3.bucket_size_bytes` and `aws.billing.estimated_charges`). | ||
|
|
||
| The overlap period can last several hours. If values still appear doubled after 24 hours, see the [CloudWatch Metric Streams guide][6] for troubleshooting. |
There was a problem hiding this comment.
This FAQ says duplicate values can persist for “several hours” and suggests waiting 24 hours before troubleshooting, but the Metric Streams setup guide in this repo documents the overlap as a brief period of up to five minutes (content/en/integrations/guide/aws-cloudwatch-metric-streams-with-kinesis-data-firehose.md line 114). For users migrating from polling to streams, this mismatch can delay investigation of real configuration issues by many hours because they are told prolonged doubling is expected.
Useful? React with 👍 / 👎.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
Re: overlap wait-time — Applied, aligned overlap timing with the Metric Streams guide: changed "several hours" to "up to five minutes" and removed the 24-hour threshold in 39c1b37. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 39c1b37b31
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| | **Typical latency** | ~10 minutes | 2-3 minutes | | ||
| | **Setup** | Included with the AWS integration | Requires separate setup with [Amazon Data Firehose][6] | | ||
| | **AWS cost** | CloudWatch `GetMetricData` API calls | CloudWatch Metric Streams and Firehose delivery charges | | ||
| | **Coverage** | All CloudWatch namespaces | Most CloudWatch namespaces (some exclusions apply) | |
There was a problem hiding this comment.
The comparison table currently says API polling covers All CloudWatch namespaces, but this overstates default behavior and can cause missed metrics: this same FAQ states custom namespaces are only collected when Collect Custom Metrics is enabled (lines 11 and 84), and the AWS getting-started guide says users configure which services are collected in the Metric Collection tab (content/en/getting_started/integrations/aws.md line 127). As written, users can reasonably assume no additional enablement is needed for custom namespaces and skip required setup.
Useful? React with 👍 / 👎.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
Re: API polling coverage — Applied, changed "All CloudWatch namespaces" to "All standard CloudWatch namespaces; custom namespaces require Collect Custom Metrics to be enabled" in 2583721. |
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d5e70fbeec
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| If you recently enabled a new AWS service integration but are not seeing metrics in Datadog, verify the following: | ||
|
|
||
| 1. **IAM permissions**: Confirm that the `DatadogAWSIntegrationRole` includes the permissions required by the service. See the individual [AWS integration pages][8] for service-specific permission requirements. |
There was a problem hiding this comment.
This checklist item assumes every AWS integration uses DatadogAWSIntegrationRole, but the manual setup docs still support an Access Keys path (content/en/integrations/guide/aws-manual-setup.md, lines 138-155) where no role exists. In that setup, users troubleshooting missing metrics cannot apply this instruction and may skip the actual prerequisite (updating the IAM user policy), so the FAQ should describe permissions validation in a way that covers both role delegation and access-key configurations.
Useful? React with 👍 / 👎.
1 participant
What does this PR do? What is the motivation?
Adds four new FAQ entries to the AWS Integration and CloudWatch FAQ addressing common support ticket themes from DOCS-13133:
Merge instructions
Merge readiness: