---
title: Metric Type Modifiers
description: Datadog, the leading service for cloud-scale monitoring.
breadcrumbs: Docs > Metrics > Custom Metrics > Metric Type Modifiers
---

# Metric Type Modifiers

A [metric type](https://docs.datadoghq.com/metrics/types/) is an indication of what you are trying to represent with your metric and its emission source. The `COUNT` and `RATE` metric types are quite similar to each other, as they represent the same concept: the variation of a metric value over time. However, they use different logic:

- `RATE`: Normalized value variation over time (*per second*).
- `COUNT`: Absolute value variation over a given time interval.

Depending on your use case and submission method, one metric type may be more suited than the other for submission. For instance:

| Metric type submitted | Use case                                                                                                                                                                               |
| --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `RATE`                | You want to monitor the number of requests received over time across several hosts.                                                                                                    |
| `RATE`                | You do not have control over the consistency of temporal count submissions across your sources, so you're normalizing by each individual interval to be able to compare them upstream. |
| `COUNT`               | You want to count the number of times a function is called.                                                                                                                            |
| `COUNT`               | Counting the amount of revenue that have been made over a given amount of time.                                                                                                        |

Since `RATE` and `COUNT` aren't the same metric type, they don't have the same behavior or shape within Datadog graphs and monitors. To change metrics on the fly between `RATE` and `COUNT` representations, use Datadog's in-application modifier functions within your graphs and monitors.

## In-application modifiers{% #in-application-modifiers %}

The two main in-application modifiers are `as_count()` and `as_rate()`.

| Modifiers    | Description                                                                                                                                                                                                                                                                                                                                                                                                                                         |
| ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `as_count()` | Sets the operations necessary to display the given metric in `COUNT` form, giving you the absolute variation of a metric value over [a rollup interval](https://docs.datadoghq.com/metrics/introduction/#time-aggregation). **Note:** Because it depends on the rollup interval, [graphing a longer time interval changes your graph shape](https://docs.datadoghq.com/dashboards/faq/why-does-zooming-out-a-timeframe-also-smooth-out-my-graphs/). |
| `as_rate()`  | Sets the operations necessary to display the given metric in `RATE` form, giving you the absolute variation of a metric value per second.                                                                                                                                                                                                                                                                                                           |

Depending on the metric type you applied them to, the behavior differs:

{% tab title="COUNT" %}

- Effect of `as_count()`:
  - Disables any [interpolation](https://docs.datadoghq.com/metrics/guide/interpolation-the-fill-modifier-explained/).
  - Sets the time aggregator to `SUM`.
- Effect of `as_rate()`:
  - Disables any [interpolation](https://docs.datadoghq.com/metrics/guide/interpolation-the-fill-modifier-explained/).
  - Sets the time aggregator to `SUM`.
  - Divides the result post-aggregation by the sampling interval in order to normalize it. For example, the following points submitted every second `[1,1,1,1].as_rate()` with a rollup interval of 20s would produce `[0.05, 0.05, 0.05, 0.05]`.

**Note**: There is no normalization on tiny intervals (when no time aggregation occurs), thus the raw metric value counts are returned.
{% /tab %}

{% tab title="RATE" %}

- Effect of `as_count()`:
  - Disable any [interpolation](https://docs.datadoghq.com/metrics/guide/interpolation-the-fill-modifier-explained/).
  - Sets the time aggregator to SUM.
  - Multiply the result post-aggregation by the sampling interval. For example, the following points submitted every second `[0.05, 0.05, 0.05, 0.05].as_count()` with a rollup interval of 20s would produce `[1,1,1,1]`.
- Effect of `as_rate()`:
  - Disables any [interpolation](https://docs.datadoghq.com/metrics/guide/interpolation-the-fill-modifier-explained/).
  - Sets the time aggregator to `SUM`.

{% /tab %}

{% tab title="GAUGE" %}
`GAUGE` metric types represent the absolute and final value of a metric; `as_count()` and `as_rate()` modifiers have no effect on them.
{% /tab %}

### The `weighted()` modifier{% #the-weighted-modifier %}

Tags such as `pod name` or `container_name` cause high tag churn, especially when creating queries for cost management, capacity planning, or autoscaling for containerized applications. To ensure mathematical accuracy of queries on gauges regardless of tag churn, you can use a `.weighted()` in-application modifier. The `.weighted()` modifier enables Datadog to properly weight metric values based on the lifespan of these frequently churning tags.

The `.weighted()` modifier is automatically appended to queries on gauges only if both of the following conditions are met:

- The gauge metric is submitted regularly, such that there is no interpolation over gaps.
- The submission interval is correctly defined and set.

Either the Datadog Agent or an integration sets the submission interval for a metric at time of intake. Modify submission intervals on the [Metrics Summary page](https://app.datadoghq.com/metric/summary).

## Modify a metric's type within Datadog{% #modify-a-metrics-type-within-datadog %}

While it is not normally required, it is possible to change a metric's type in the [Metrics Summary page](https://app.datadoghq.com/metric/summary):

{% image
   source="https://docs.dd-static.net/images/metrics/custom_metrics/type_modifiers/metric_type.a5bd20e36e39f5ac9ccd26ec822dd315.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/metrics/custom_metrics/type_modifiers/metric_type.a5bd20e36e39f5ac9ccd26ec822dd315.png?auto=format&fit=max&w=850&dpr=2 2x"
   alt="Metric Type" /%}

Example use case:

1. You have a metric `app.requests.served` that counts requests served, but accidentally submitted it from StatsD as a `GAUGE`. The metric's Datadog type is, therefore, `GAUGE`.

1. You wanted to submit `app.requests.served` as a StatsD `COUNT` metric for time aggregation. This would help answer questions like *"How many total requests were served in the past day?"* by querying `sum:app.requests.served{*}` (this would not make sense for a `GAUGE` metric type.)

1. You like the name `app.requests.served`, so rather than submitting a new metric name with a more appropriate `COUNT` type, you could change the type of `app.requests.served` by updating:

- Your submission code, calling `dogstatsd.increment('app.requests.served', N)` after N requests are served, and
- The Datadog in-app type from the metric summary page to `RATE`.

This causes data submitted before the type change for `app.requests.served` to behave incorrectly. This is because it was stored in a format to be interpreted as an in-app `GAUGE` (not a `RATE`). Data submitted after step 3 is interpreted properly.

If you are not willing to lose the historical data submitted as a `GAUGE`, create a new metric name with the new type, leaving the type of `app.requests.served` unchanged.

**Note**: For the AgentCheck, `self.increment` does not calculate the delta for a monotonically increasing counter; instead, it reports the value passed in at the check run. To send the delta value on a monotonically increasing counter, use `self.monotonic_count`.