Skip to content

Documentation for beta /v2/usage/billing_dimension_mapping #1995

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Oct 31, 2024
Merged

Documentation for beta /v2/usage/billing_dimension_mapping #1995

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions .apigentools-info
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,13 +4,13 @@
"spec_versions": {
"v1": {
"apigentools_version": "1.6.6",
"regenerated": "2024-10-31 15:33:01.721264",
"spec_repo_commit": "a7602fa1"
"regenerated": "2024-10-31 16:03:55.097621",
"spec_repo_commit": "a11da7b5"
},
"v2": {
"apigentools_version": "1.6.6",
"regenerated": "2024-10-31 15:33:01.739608",
"spec_repo_commit": "a7602fa1"
"regenerated": "2024-10-31 16:03:55.116103",
"spec_repo_commit": "a11da7b5"
}
}
}
132 changes: 132 additions & 0 deletions .generator/schemas/v2/openapi.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2186,6 +2186,74 @@ components:
- storage_account
- storage_container
type: object
BillingDimensionsMappingBody:
description: Billing dimensions mapping data.
items:
$ref: '#/components/schemas/BillingDimensionsMappingBodyItem'
type: array
BillingDimensionsMappingBodyItem:
description: The mapping data for each billing dimension.
properties:
attributes:
$ref: '#/components/schemas/BillingDimensionsMappingBodyItemAttributes'
id:
description: ID of the billing dimension.
type: string
type:
$ref: '#/components/schemas/ActiveBillingDimensionsType'
type: object
BillingDimensionsMappingBodyItemAttributes:
description: Mapping of billing dimensions to endpoint keys.
properties:
endpoints:
description: List of supported endpoints with their keys mapped to the billing_dimension.
items:
$ref: '#/components/schemas/BillingDimensionsMappingBodyItemAttributesEndpointsItems'
type: array
in_app_label:
description: Label used for the billing dimension in the Plan & Usage charts.
example: APM Hosts
type: string
timestamp:
description: 'Month in ISO-8601 format, UTC, and precise to the second:
`[YYYY-MM-DDThh:mm:ss]`.'
format: date-time
type: string
type: object
BillingDimensionsMappingBodyItemAttributesEndpointsItems:
description: An endpoint's keys mapped to the billing_dimension.
properties:
id:
description: The URL for the endpoint.
example: api/v1/usage/billable-summary
type: string
keys:
description: The billing dimension.
example:
- apm_host_top99p
- apm_host_sum
items:
example: apm_host_top99p
type: string
type: array
status:
$ref: '#/components/schemas/BillingDimensionsMappingBodyItemAttributesEndpointsItemsStatus'
type: object
BillingDimensionsMappingBodyItemAttributesEndpointsItemsStatus:
description: Denotes whether mapping keys were available for this endpoint.
enum:
- OK
- NOT_FOUND
type: string
x-enum-varnames:
- OK
- NOT_FOUND
BillingDimensionsMappingResponse:
description: Billing dimensions mapping response.
properties:
data:
$ref: '#/components/schemas/BillingDimensionsMappingBody'
type: object
BulkMuteFindingsRequest:
description: The new bulk mute finding request.
properties:
Expand Down Expand Up @@ -41037,6 +41105,70 @@ paths:
operator: OR
permissions:
- usage_read
/api/v2/usage/billing_dimension_mapping:
get:
description: 'Get a mapping of billing dimensions to the corresponding keys
for the supported usage metering public API endpoints.

Mapping data is updated on a monthly cadence.


This endpoint is only accessible to [parent-level organizations](https://docs.datadoghq.com/account_management/multi_organization/).'
operationId: GetBillingDimensionMapping
parameters:
- description: Datetime in ISO-8601 format, UTC, and for mappings beginning
this month. Defaults to the current month.
in: query
name: filter[month]
required: false
schema:
format: date-time
type: string
- description: String to specify whether to retrieve active billing dimension
mappings for the contract or for all available mappings. Allowed views have
the string `active` or `all`. Defaults to `active`.
in: query
name: filter[view]
required: false
schema:
default: active
type: string
responses:
'200':
content:
application/json;datetime-format=rfc3339:
schema:
$ref: '#/components/schemas/BillingDimensionsMappingResponse'
description: OK
'400':
content:
application/json;datetime-format=rfc3339:
schema:
$ref: '#/components/schemas/APIErrorResponse'
description: Bad Request
'403':
content:
application/json;datetime-format=rfc3339:
schema:
$ref: '#/components/schemas/APIErrorResponse'
description: Forbidden - User is not authorized
'429':
content:
application/json;datetime-format=rfc3339:
schema:
$ref: '#/components/schemas/APIErrorResponse'
description: Too many requests
security:
- apiKeyAuth: []
appKeyAuth: []
- AuthZ:
- usage_read
summary: Get billing dimension mapping for usage endpoints
tags:
- Usage Metering
x-unstable: '**Note**: This endpoint is in Preview.

If you have any feedback, contact [Datadog support](https://docs.datadoghq.com/help/).'
/api/v2/usage/cost_by_org:
get:
deprecated: true
Expand Down
1 change: 1 addition & 0 deletions ...ing/Get-billing-dimension-mapping-for-usage-endpoints-returns-Bad-Request-response.frozen
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
2024-10-28T16:04:40.774Z
22 changes: 22 additions & 0 deletions ...tering/Get-billing-dimension-mapping-for-usage-endpoints-returns-Bad-Request-response.yml
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

8 changes: 8 additions & 0 deletions examples/v2/usage-metering/GetBillingDimensionMapping.rb
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
# Get billing dimension mapping for usage endpoints returns "OK" response

require "datadog_api_client"
DatadogAPIClient.configure do |config|
config.unstable_operations["v2.get_billing_dimension_mapping".to_sym] = true
end
api_instance = DatadogAPIClient::V2::UsageMeteringAPI.new
p api_instance.get_billing_dimension_mapping()
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚪ Code Quality Violation

Suggested change
p api_instance.get_billing_dimension_mapping()
p api_instance.get_billing_dimension_mapping
Do not use parentheses with methods that take no arguments (...read more)

The rule "Avoid parentheses when methods take no arguments" is part of the Ruby style guide. It suggests that when a method takes no arguments, you should not use parentheses. This is because the use of parentheses in such a case is redundant and unnecessary, and it can make your code more difficult to read and understand.

This rule is important because it promotes cleaner, more readable code. In Ruby, clean and readable code is highly valued. By following this rule, you can ensure your code is easier to understand and maintain, which is crucial for long-term project success.

To adhere to this rule, remove the parentheses when calling a method that does not require any arguments. For example, instead of writing 'test'.upcase(), you should write 'test'.upcase. Similarly, instead of Kernel.exit!(), write Kernel.exit!. However, note that there is an exception for super - super by itself is different from super(), so in this case, parentheses may be necessary.

View in Datadog  Leave us feedback  Documentation

4 changes: 4 additions & 0 deletions features/scenarios_model_mapping.rb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1129,6 +1129,10 @@
"start_hr" => "Time",
"end_hr" => "Time",
},
"v2.GetBillingDimensionMapping" => {
"filter_month" => "Time",
"filter_view" => "String",
},
Comment on lines +1132 to +1135
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚪ Code Quality Violation

Consider using symbols instead of string hash keys (...read more)

In Ruby, it is a best practice to use symbols instead of strings as hash keys. This rule emphasizes that it's more efficient and idiomatic to use symbols for this purpose. Symbols are immutable and unique, which makes them ideal for identifying things, whereas strings are mutable and can create multiple objects for the same sequence of characters.

The importance of this rule lies in the performance and memory usage of your Ruby application. Using symbols as hash keys reduces memory usage because they are stored in memory only once during a Ruby process. This can make a significant difference in the efficiency of your application, especially when dealing with large data sets.

To ensure you're following good coding practices, always use symbols for hash keys unless there's a specific reason to use a string. A simple refactoring from values = { 'foo' => 42, 'bar' => 99, 'baz' => 123 } to values = { foo: 42, bar: 99, baz: 123 } will make your code compliant with this rule. This not only improves your code's performance but also makes it more readable and consistent with Ruby's conventions.

View in Datadog  Leave us feedback  Documentation

"v2.GetCostByOrg" => {
"start_month" => "Time",
"end_month" => "Time",
Expand Down
6 changes: 6 additions & 0 deletions features/v2/undo.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2494,6 +2494,12 @@
"type": "safe"
}
},
"GetBillingDimensionMapping": {
"tag": "Usage Metering",
"undo": {
"type": "safe"
}
},
"GetCostByOrg": {
"tag": "Usage Metering",
"undo": {
Expand Down
14 changes: 14 additions & 0 deletions features/v2/usage_metering.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -48,6 +48,20 @@ Feature: Usage Metering
When the request is sent
Then the response status is 200 OK

@team:DataDog/revenue-query
Scenario: Get billing dimension mapping for usage endpoints returns "Bad Request" response
Given operation "GetBillingDimensionMapping" enabled
And new "GetBillingDimensionMapping" request
When the request is sent
Then the response status is 400 Bad Request

@skip @team:DataDog/revenue-query
Scenario: Get billing dimension mapping for usage endpoints returns "OK" response
Given operation "GetBillingDimensionMapping" enabled
And new "GetBillingDimensionMapping" request
When the request is sent
Then the response status is 200 OK

@generated @skip @team:DataDog/revenue-query
Scenario: Get cost across multi-org account returns "Bad Request" response
Given new "GetCostByOrg" request
Expand Down
1 change: 1 addition & 0 deletions lib/datadog_api_client/configuration.rb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -195,6 +195,7 @@ def initialize
"v2.list_apis": false,
"v2.update_open_api": false,
"v2.get_active_billing_dimensions": false,
"v2.get_billing_dimension_mapping": false,
"v2.get_monthly_cost_attribution": false,
"v2.create_dora_deployment": false,
"v2.create_dora_incident": false,
Expand Down
5 changes: 5 additions & 0 deletions lib/datadog_api_client/inflector.rb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1007,6 +1007,11 @@ def overrides
"v2.azure_uc_config_post_request_type" => "AzureUCConfigPostRequestType",
"v2.azure_uc_configs_response" => "AzureUCConfigsResponse",
"v2.bill_config" => "BillConfig",
"v2.billing_dimensions_mapping_body_item" => "BillingDimensionsMappingBodyItem",
"v2.billing_dimensions_mapping_body_item_attributes" => "BillingDimensionsMappingBodyItemAttributes",
"v2.billing_dimensions_mapping_body_item_attributes_endpoints_items" => "BillingDimensionsMappingBodyItemAttributesEndpointsItems",
"v2.billing_dimensions_mapping_body_item_attributes_endpoints_items_status" => "BillingDimensionsMappingBodyItemAttributesEndpointsItemsStatus",
"v2.billing_dimensions_mapping_response" => "BillingDimensionsMappingResponse",
"v2.bulk_mute_findings_request" => "BulkMuteFindingsRequest",
"v2.bulk_mute_findings_request_attributes" => "BulkMuteFindingsRequestAttributes",
"v2.bulk_mute_findings_request_data" => "BulkMuteFindingsRequestData",
Expand Down
73 changes: 73 additions & 0 deletions lib/datadog_api_client/v2/api/usage_metering_api.rb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -89,6 +89,79 @@ def get_active_billing_dimensions_with_http_info(opts = {})
return data, status_code, headers
end

# Get billing dimension mapping for usage endpoints.
#
# @see #get_billing_dimension_mapping_with_http_info
def get_billing_dimension_mapping(opts = {})
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚪ Code Quality Violation

Avoid using a hash as an optional parameter (...read more)

The rule "Avoid hash optional parameters" is a guideline that encourages developers to explicitly declare parameters instead of using a hash for optional parameters. This is because using a hash for optional parameters can make the code harder to understand and maintain. It can also lead to unexpected behavior if a developer accidentally includes a key in the hash that the method does not expect.

This rule is important because it promotes code readability and maintainability. It also helps prevent potential bugs that may occur due to unexpected keys in the optional hash. By explicitly declaring each parameter, developers can easily see what parameters a method expects, making the code easier to read and understand.

To adhere to this rule, instead of using a hash for optional parameters, explicitly declare each parameter in the method definition. For example, instead of using options = {} in the method definition, declare each parameter like name, email, age. This way, anyone reading the code can easily understand what parameters the method expects and in what order.

View in Datadog  Leave us feedback  Documentation

data, _status_code, _headers = get_billing_dimension_mapping_with_http_info(opts)
data
end

# Get billing dimension mapping for usage endpoints.
#
# Get a mapping of billing dimensions to the corresponding keys for the supported usage metering public API endpoints.
# Mapping data is updated on a monthly cadence.
#
# This endpoint is only accessible to [parent-level organizations](https://docs.datadoghq.com/account_management/multi_organization/).
#
# @param opts [Hash] the optional parameters
# @option opts [Time] :filter_month Datetime in ISO-8601 format, UTC, and for mappings beginning this month. Defaults to the current month.
# @option opts [String] :filter_view String to specify whether to retrieve active billing dimension mappings for the contract or for all available mappings. Allowed views have the string `active` or `all`. Defaults to `active`.
# @return [Array<(BillingDimensionsMappingResponse, Integer, Hash)>] BillingDimensionsMappingResponse data, response status code and response headers
def get_billing_dimension_mapping_with_http_info(opts = {})
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚪ Code Quality Violation

Avoid using a hash as an optional parameter (...read more)

The rule "Avoid hash optional parameters" is a guideline that encourages developers to explicitly declare parameters instead of using a hash for optional parameters. This is because using a hash for optional parameters can make the code harder to understand and maintain. It can also lead to unexpected behavior if a developer accidentally includes a key in the hash that the method does not expect.

This rule is important because it promotes code readability and maintainability. It also helps prevent potential bugs that may occur due to unexpected keys in the optional hash. By explicitly declaring each parameter, developers can easily see what parameters a method expects, making the code easier to read and understand.

To adhere to this rule, instead of using a hash for optional parameters, explicitly declare each parameter in the method definition. For example, instead of using options = {} in the method definition, declare each parameter like name, email, age. This way, anyone reading the code can easily understand what parameters the method expects and in what order.

View in Datadog  Leave us feedback  Documentation

unstable_enabled = @api_client.config.unstable_operations["v2.get_billing_dimension_mapping".to_sym]
if unstable_enabled
@api_client.config.logger.warn format("Using unstable operation '%s'", "v2.get_billing_dimension_mapping")
else
raise DatadogAPIClient::APIError.new(message: format("Unstable operation '%s' is disabled", "v2.get_billing_dimension_mapping"))
end

if @api_client.config.debugging
@api_client.config.logger.debug 'Calling API: UsageMeteringAPI.get_billing_dimension_mapping ...'
end
# resource path
local_var_path = '/api/v2/usage/billing_dimension_mapping'

# query parameters
query_params = opts[:query_params] || {}
query_params[:'filter[month]'] = opts[:'filter_month'] if !opts[:'filter_month'].nil?
query_params[:'filter[view]'] = opts[:'filter_view'] if !opts[:'filter_view'].nil?

# header parameters
header_params = opts[:header_params] || {}
# HTTP header 'Accept' (if needed)
header_params['Accept'] = @api_client.select_header_accept(['application/json;datetime-format=rfc3339'])

# form parameters
form_params = opts[:form_params] || {}

# http body (model)
post_body = opts[:debug_body]

# return_type
return_type = opts[:debug_return_type] || 'BillingDimensionsMappingResponse'

# auth_names
auth_names = opts[:debug_auth_names] || [:apiKeyAuth, :appKeyAuth, :AuthZ]
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚪ Code Quality Violation

Suggested change
auth_names = opts[:debug_auth_names] || [:apiKeyAuth, :appKeyAuth, :AuthZ]
auth_names = opts[:debug_auth_names] || %i[apiKeyAuth appKeyAuth AuthZ]
Consider using the %i syntax instead (...read more)

The rule "Prefer %i to the literal array syntax" is a guideline that encourages the use of the %i syntax for arrays of symbols. This is a part of the Ruby style guide that aims to promote conciseness and readability.

Symbols are immutable, reusable objects often used in Ruby instead of strings when the value does not need to be changed. When declaring an array of symbols, using the %i syntax can make your code cleaner and easier to read.

To adhere to this rule, instead of declaring an array of symbols using the literal array syntax like [:foo, :bar, :baz], use the %i syntax like %i[foo bar baz]. It's a good practice to consistently use %i for arrays of symbols as it enhances code readability and maintainability.

View in Datadog  Leave us feedback  Documentation


new_options = opts.merge(
:operation => :get_billing_dimension_mapping,
:header_params => header_params,
:query_params => query_params,
:form_params => form_params,
:body => post_body,
:auth_names => auth_names,
:return_type => return_type,
:api_version => "V2"
)

data, status_code, headers = @api_client.call_api(Net::HTTP::Get, local_var_path, new_options)
if @api_client.config.debugging
@api_client.config.logger.debug "API called: UsageMeteringAPI#get_billing_dimension_mapping\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
end
return data, status_code, headers
end

# Get cost across multi-org account.
#
# @see #get_cost_by_org_with_http_info
Expand Down
Loading
Loading