Custom Metrics Billing
New announcements from Dash: Incident Management, Continuous Profiler, and more! New announcements from Dash!

Custom Metrics Billing

If a metric is not submitted from one of the more than 400 Datadog integrations it’s considered a custom metric(1).

A custom metric is uniquely identified by a combination of a metric name and tag values (including the host tag).

Counting Custom Metrics

The number of custom metrics associated with a particular metric name depends on its metric submission type. Below are examples of how to count your custom metrics based on the following scenario below:

Suppose you’re submitting a metric, request.Latency, from two hosts (host:A,host:B), which measures the latency of your endpoint requests. You’re submitting this metric with two tag keys:

  • endpoint, which has the value endpoint:X or endpoint:Y.
  • status, which has the value status:200 or status:400.

Assume that in your data, endpoint:X is supported by both hosts, but fails only on host:B. Also assume that requests to endpoint:Y are always successful and only appear on host:B as shown below:

The number of custom metrics from COUNT, RATE, and GAUGE metric types is calculated with the same logic.

The number of unique tag value combinations submitted for a GAUGE metric with this tagging scheme is four:

  • host:A, endpoint:X, status:200
  • host:B, endpoint:X, status:200
  • host:B, endpoint:X, status:400
  • host:B, endpoint:Y, status:200

This results in request.Latency reporting four distinct custom metrics.

Effect of adding tags

Adding tags may not result in more custom metrics. Your count of custom metrics usually scales with the most granular or detailed tag. Suppose you are measuring temperature in the US, and you have tagged your temperature metric by country and region. You submit the following to Datadog:

Metric NameTag Values
temperaturecountry:USA, region: Northeast
temperaturecountry:USA, region: Southeast

Suppose you wanted to add the tag city which has three values: NYC, Miami, and Orlando. Adding this tag increases the number of custom metrics as it provides more detail and granularity to your dataset as shown below:

Metric NameTag Values
temperaturecountry:USA, region: Northeast, city: NYC
temperaturecountry:USA, region: Southeast, city: Orlando
temperaturecountry:USA, region: Southeast, city: Miami

The count of custom metrics reporting from temperature scales with the most granular tag, city.

Now suppose you also wanted to tag your temperature metric by state (which has two values: NY and Florida). You’re now tagging temperature by the set of tags: country, region, state, and city. Adding the state tag doesn’t increase the level of granularity already present in your dataset provided by the city tag.

To obtain the temperature in Florida, you can simply recombine the custom metrics of:

  • temperature{country:USA, state:Florida, city:Orlando}
  • temperature{country:USA, state:Florida, city:Miami}

Note: Reordering tag values doesn’t add uniqueness. The following combinations are the same custom metric:

  • temperature{country:USA, state:Florida, city:Miami}
  • temperature{state:Florida, city:Miami, country:USA}

A HISTOGRAM metric generates by default five custom metrics for each unique combination of metric name and tag values to support the Agent-side aggregations max, median, avg, 95pc, and count. Learn more about HISTOGRAM metric type.

The number of unique tag value combinations submitted for a HISTOGRAM metric with this tagging scheme is four:

  • host:A, endpoint:X, status:200
  • host:B, endpoint:X, status:200
  • host:B, endpoint:X, status:400
  • host:B, endpoint:Y, status:200

By default, the Agent generates five custom metrics for each of the original four unique tag value combinations to account for each Agent-side aggregations enabled: avg, count, median, 95percentile, and max. Consequently, request.Latency reports a total of 4*5 = 20 custom metrics.

Note: Adding aggregations to your HISTOGRAM metrics increases the number of distinct custom metrics reported. Removing aggregations decreases the number of custom metrics reported.

  • Configure which aggregation you want to send to Datadog with the histogram_aggregates parameter in your datadog.yaml configuration file. By default, only max, median, avg, and count aggregations are sent out to Datadog. sum and min are also available if desired.
  • Configure which percentile aggregation you want to send to Datadog with the histogram_percentiles parameter in your datadog.yaml configuration file. By default, only the 95percentile, 95th percentile, is sent out to Datadog.

A DISTRIBUTION metric generates by default five custom metrics for each unique combination of metric name and tag values to represent the global statistical distribution of values. These five custom metrics represent server-side aggregations of count, sum, min, max, and avg. Learn more about DISTRIBUTION metric type.

The number of unique tag value combinations submitted for a DISTRIBUTION metric with this tagging scheme is four.

  • host:A, endpoint:X, status:200
  • host:B, endpoint:X, status:200
  • host:B, endpoint:X, status:400
  • host:B, endpoint:Y, status:200

The number of custom metrics from a DISTRIBUTION metric is five times the unique combination of metric name and tag values. This results in request.Latency reporting a total of 5*4 = 20 custom metrics.

Customization of tagging

You can customize which tag combination aggregations are created for any DISTRIBUTION metric. Suppose you want to keep only the endpoint and status tags associated with the request.Latency metric. This results in the following three unique tag combinations:

  • endpoint:X, status:200
  • endpoint:X, status:400
  • endpoint:Y, status:200

The number of custom metrics from a DISTRIBUTION metric is five times the unique combination of metric name and tag values. As a result of the tag customization, request.Latency reporting a total of 5*3 = 15 custom metrics

Adding percentile aggregations

Percentile aggregations are unique in the way they’re counted because Datadog stores five custom metrics for each potentially queryable tag value combination to provide you with globally accurate percentiles: p50, p75, p90, p95, and p99. Suppose you have added percentile aggregations for request.Latency for the set of tags endpoint and status with the same tag dependency seen earlier. The number of queryable tag value combinations is eight:

  • endpoint:X, status:200
  • endpoint:X, status:400
  • endpoint:Y, status:200
  • endpoint:X
  • endpoint:Y
  • status:200
  • status:400
  • *

After enabling percentile aggregations for request.Latency, this metric name additionally reports 5*8 = 40 custom metrics.

Note: Only tag value combinations that actually appear in your data are counted as queryable. Since the combination { endpoint:Y, status:400 } was never submitted in your data, this combination won’t be queryable and won’t count towards your custom metric count.

Tracking custom metrics

Administrative users (those with Datadog Admin roles) can see the monthly average number of custom metrics per hour and the top 5000 custom metrics for their account on the usage details page. See the Usage Details documentation for more information.

For more real-time tracking of the count of custom metrics for a particular metric name, click into the metric name on the Metrics Summary page. It’s listed as “Currently reporting # distinct metrics…” as shown below:

Allocation

You are allocated a certain number of custom metrics based on your Datadog pricing plan:

  • Pro: 100 custom metrics per host.
  • Enterprise: 200 custom metrics per host.

These allocations are counted across your entire infrastructure. For example, if you are on the Pro plan and licensed for three hosts, 300 custom metrics are allocated. The 300 custom metrics can be divided equally across each host, or all 300 metrics can be used by a single host. Using this example, the graphic below shows scenarios that do not exceed the allocated custom metric count:

The billable number of custom metrics is based on the average number of custom metrics (from all paid hosts) per hour over a given month. Contact Sales or your Customer Success Manager to discuss custom metrics for your account or to purchase an additional custom metrics package.

Standard integrations

The following standard integrations can potentially emit custom metrics.

Type of integrationsIntegrations
Limited to 350 custom metrics by default.ActiveMQ XML / Go-Expvar / Java-JMX
No default limit on custom metrics collection.Nagios /PDH Check /Prometheus /SNMP /Windows Services /WMI
Can be configured to collect custom metrics.MySQL /Oracle /Postgres /SQL Server
Custom metrics sent from cloud integrationsAWS

Troubleshooting

For technical questions, contact Datadog support.

For billing questions, contact your Customer Success Manager.