[DOCS-11489] CCM new data source #30521
Open
+70
−29
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
📝 Documentation Team Review RequiredThis pull request requires approval from the @DataDog/documentation team before it can be merged. Please ensure your changes follow our documentation guidelines and wait for a team member to review and approve your changes. |
Preview links (active after the
|
helenmtang
requested changes
Jul 17, 2025
helenmtang
requested changes
Jul 18, 2025
|
|
||
| ## Create a custom allocation rule | ||
|
|
||
| ### Step 1 - Define the source | ||
|
|
||
| 1. Navigate to [Cloud Cost > Settings > Custom Allocation Rules][2] and click **Add New Rule** to start. | ||
| 2. From the dropdown, select the shared costs you want to allocate. | ||
| 1. Under **Define the source**, select the cost provider. | ||
| 1. Each data source you add creates a separate grouping for the data. |
There was a problem hiding this comment.
Suggested change
| 1. Each data source you add creates a separate grouping for the data. | |
| 1. Under **Define the costs to split**, select the shared costs you want to allocate. |
There was a problem hiding this comment.
Ah! Data source doesn't apply here — it applies to the Dynamic by metric section, under allocaiton type
|
|
||
| _Example: Untagged support costs, shared database costs._ | ||
| _For example, you may want to apply the allocation rule to a specific subset of your cloud spend, such as the `production` environment._ |
There was a problem hiding this comment.
Suggested change
| _For example, you may want to apply the allocation rule to a specific subset of your cloud spend, such as the `production` environment._ | |
| _Example: Untagged support costs, shared database costs._ |
There was a problem hiding this comment.
i think the original is good!
| @@ -44,9 +45,9 @@ Below is a description of how each allocation method works with examples. | |||
|
|
|||
| {{< img src="cloud_cost/custom_allocation_rules/even_diagram.png" alt="Diagram illustrating the even split strategy" style="width:70%;" >}} | |||
|
|
|||
| With the even strategy, costs are allocated evenly towards your destination tags. [Apply a filter](#step-4---optional-apply-filters) to refine which part of the bill determines the proportions. | |||
| With the even strategy, costs are allocated evenly towards your destination tags. | |||
There was a problem hiding this comment.
Suggested change
| With the even strategy, costs are allocated evenly towards your destination tags. | |
| With the even strategy, costs are allocated evenly towards your destination tags. [Apply a filter](#step-4---optional-apply-filters) to refine which part of the bill determines the proportions. |
There was a problem hiding this comment.
Hm it looks like there's nowhere else in the doc where we can explain that Even Allocaiton has filters, so let's keep this in here?
| @@ -70,15 +71,14 @@ In the preceding diagram, the pink bar represents a filter on the cost allocatio | |||
|
|
|||
| To create a rule for this allocation, you can: | |||
|
|
|||
| - Define the costs to allocate (source): **EC2 support fees** (`aws_product:support`). | |||
| - Define the costs to allocate (source): **EC2 support fees** (`aws_product:support`). Use filters to narrow down the data source. Each source you add creates a separate grouping for the data. | |||
There was a problem hiding this comment.
Suggested change
| - Define the costs to allocate (source): **EC2 support fees** (`aws_product:support`). Use filters to narrow down the data source. Each source you add creates a separate grouping for the data. | |
| - Define the costs to allocate (source): **EC2 support fees** (`aws_product:support`). |
| @@ -70,15 +71,14 @@ In the preceding diagram, the pink bar represents a filter on the cost allocatio | |||
|
|
|||
| To create a rule for this allocation, you can: | |||
|
|
|||
| - Define the costs to allocate (source): **EC2 support fees** (`aws_product:support`). | |||
| - Define the costs to allocate (source): **EC2 support fees** (`aws_product:support`). Use filters to narrow down the data source. Each source you add creates a separate grouping for the data. | |||
| - Choose the allocation method: **Proportional by spend**. | |||
| - Choose the [destination tag](#step-3---define-the-destination) to split your costs by: **User** (`User A`, `User B`, `User C`). | |||
There was a problem hiding this comment.
Suggested change
| - Choose the [destination tag](#step-3---define-the-destination) to split your costs by: **User** (`User A`, `User B`, `User C`). | |
| - Choose the [destination tag](#step-3---define-the-destination) to split your costs by: **User** (`User A`, `User B`, `User C`). | |
| - Refine the allocation by applying [filters](#step-4---optional-apply-filters): **EC2** (`aws_product:ec2`).``` |
| To create a rule for this allocation, you could: | ||
|
|
||
| - Define the costs to allocate (source): **PostGreSQL costs** (`azure_product_family:dbforpostgresql`). | ||
| - Define the costs to allocate (source): **Database costs** (`aws_product:rds`). Use filters to narrow down the data source. Each source you add creates a separate grouping for the data. |
There was a problem hiding this comment.
Suggested change
| - Define the costs to allocate (source): **Database costs** (`aws_product:rds`). Use filters to narrow down the data source. Each source you add creates a separate grouping for the data. | |
| - Define the costs to allocate (source): **NAT gateway costs** (`aws_operation:NatGateway`). |
| - Refine the allocation by applying [filters](#step-4---optional-apply-filters): **EC2** (`aws_product:ec2`). | ||
| - Define the metric query used to split the source costs: **Query execution time per user** (`sum:postgresql.queries.time{*}` by `{user}.as_count`). | ||
| - Create suballocations by [partitioning](#step-5---optional-apply-a-partition) the allocation rule: **environment** (`env`). | ||
| - Choose the data source: **Database Queries**. Tip: Review available metrics and tags in the [Metrics Summary][2]. |
There was a problem hiding this comment.
Suggested change
| - Choose the data source: **Database Queries**. Tip: Review available metrics and tags in the [Metrics Summary][2]. | |
| - Choose the data source: **Network**. Tip: Review available metrics and tags in the [Metrics Summary][2]. |
| - Define the metric query used to split the source costs: **Query execution time per user** (`sum:postgresql.queries.time{*}` by `{user}.as_count`). | ||
| - Create suballocations by [partitioning](#step-5---optional-apply-a-partition) the allocation rule: **environment** (`env`). | ||
| - Choose the data source: **Database Queries**. Tip: Review available metrics and tags in the [Metrics Summary][2]. | ||
| - Choose the [destination tag](#step-3---define-the-destination) to split your costs by: **Service** (`trace.caller.service`). |
There was a problem hiding this comment.
Suggested change
| - Choose the [destination tag](#step-3---define-the-destination) to split your costs by: **Service** (`trace.caller.service`). | |
| - Refine the allocation by applying a [filter](#step-4---optional-apply-filters):**NAT Gateway** (`server_gateway_id:nat-*`). This filters the metric to only return data for your NAT Gateway usage. | |
| - Choose the [destination tag](#step-3---define-the-destination) to split your costs by applying a group by. In Network, do this by filling out the `View clients as` section: **service** (`client_service`). This groups the metric by service. |
| - Create suballocations by [partitioning](#step-5---optional-apply-a-partition) the allocation rule: **environment** (`env`). | ||
| - Choose the data source: **Database Queries**. Tip: Review available metrics and tags in the [Metrics Summary][2]. | ||
| - Choose the [destination tag](#step-3---define-the-destination) to split your costs by: **Service** (`trace.caller.service`). | ||
| - Create suballocations by [partitioning](#step-4---optional-apply-a-partition) the allocation rule: **environment** (`env`). |
There was a problem hiding this comment.
Suggested change
| - Create suballocations by [partitioning](#step-4---optional-apply-a-partition) the allocation rule: **environment** (`env`). | |
| - Create suballocations by [partitioning](#step-4---optional-apply-a-partition) the allocation rule. To do this, first apply another group by to the metric. In Network, do this by filling out the `View servers as` section: **Gateway ID** (`gateway_id`). This groups the metric by gateway_id. Then, select `server_gateway_id` in the **Partition source costs by** section. |
There was a problem hiding this comment.
Does this make sense? Should we add another sentence "Note: if you do not define a partition, the allocation rule will consider all group by tags as your destination tags, and split source costs across all destinations."
|
|
||
| - **Proportional by spend**: Let's say you allocate shared costs to the team tag, proportional to how much each team spends. You can add a filter, creating a cost allocation that is proportional to how much team spends on `aws_product` is `ec2`. | ||
| - **Dynamic by metric**: Let's say you allocate shared PostgreSQL costs to the service tag, proportional to the query execution time of each service. You can add a filter, creating a cost allocation that only applies where `environment` is `production`. | ||
| 1. Define the custom percentages for each of the tags you've selected for cost allocation. |
There was a problem hiding this comment.
Suggested change
| 1. Define the custom percentages for each of the tags you've selected for cost allocation. | |
| ### Step 4 - (optional) Apply filter(s) | |
| Apply a filter across the entire allocation rule. Filters help you target the allocation rule to the relevant subset of your cloud spend. | |
| - **Proportional by spend**: Let's say you allocate shared costs to the team tag, proportional to how much each team spends. You can add a filter, creating a cost allocation that is proportional to how much team spends on `aws_product` is `ec2`. | |
| - **Dynamic by metric**: Let's say you allocate shared PostgreSQL costs to the service tag, proportional to the query execution time of each service. You can add a filter, creating a cost allocation that only applies where `environment` is `production`. Note: since the Dynamic by metric allocation type uses a metric to create the cost allocation, you apply the filter to the allocation rule by filtering the metric query itself. | |
There was a problem hiding this comment.
lmk if this makes sense!
helenmtang
requested changes
Jul 18, 2025
|
|
||
| ### Step 5 - (optional) Apply a partition | ||
| ### Step 4 - (optional) Apply a partition |
There was a problem hiding this comment.
Suggested change
| ### Step 4 - (optional) Apply a partition | |
| ### Step 5 - (optional) Apply a partition |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do? What is the motivation?
Merge instructions
Merge readiness:
For Datadog employees:
Your branch name MUST follow the
<name>/<description>convention and include the forward slash (/). Without this format, your pull request will not pass CI, the GitLab pipeline will not run, and you won't get a branch preview. Getting a branch preview makes it easier for us to check any issues with your PR, such as broken links.If your branch doesn't follow this format, rename it or create a new branch and PR.
[6/5/2025] Merge queue has been disabled on the documentation repo. If you have write access to the repo, the PR has been reviewed by a Documentation team member, and all of the required checks have passed, you can use the Squash and Merge button to merge the PR. If you don't have write access, or you need help, reach out in the #documentation channel in Slack.
Additional notes