---
title: "otelcol.processor.interval | Grafana Alloy documentation"
description: "Learn about otelcol.processor.interval"
---

# `otelcol.processor.interval`

> **EXPERIMENTAL**: This is an [experimental](/docs/release-life-cycle/) component. Experimental components are subject to frequent breaking changes, and may be removed with no equivalent replacement. To enable and use an experimental component, you must set the `stability.level` [flag](/docs/alloy/latest/reference/cli/run/) to `experimental`.

`otelcol.processor.interval` aggregates metrics and periodically forwards the latest values to the next component in the pipeline. The processor supports aggregating the following metric types:

- Monotonically increasing, cumulative sums
- Monotonically increasing, cumulative histograms
- Monotonically increasing, cumulative exponential histograms
- Gauges
- Summaries

The following metric types won’t be aggregated and will instead be passed, unchanged, to the next component in the pipeline:

- All delta metrics
- Non-monotonically increasing sums

> Note
> 
> Aggregating data over an interval is an inherently lossy process. You lose precision for monotonically increasing cumulative sums, histograms, and exponential histograms, but you don’t lose overall data. You can lose data when you aggregate non-monotonically increasing sums, gauges, and summaries. For example, a value can increase and decrease to the original value, and you can lose this change in the aggregation. In most cases, this type of data loss is acceptable. However, you can change the configuration so that these changed values pass through and aren’t aggregated.

> Warning
> 
> After exporting, any internal state is cleared. If no new metrics come in, the next interval will export nothing.

> Note
> 
> `otelcol.processor.interval` is a wrapper over the upstream OpenTelemetry Collector [`interval`](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/v0.147.0/processor/intervalprocessor) processor. Bug reports or feature requests will be redirected to the upstream repository, if necessary.

## Usage

Alloy ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy

```alloy
otelcol.processor.interval "<LABEL>" {
  output {
    metrics = [...]
  }
}
```

## Arguments

You can use the following argument with `otelcol.processor.interval`:

Expand table

| Name       | Type       | Description                                                           | Default | Required |
|------------|------------|-----------------------------------------------------------------------|---------|----------|
| `interval` | `duration` | The interval in which the processor should export aggregated metrics. | `"60s"` | no       |

## Blocks

You can use the following blocks with `otelcol.processor.interval`:

No valid configuration blocks found.

### `output`

Required

The `output` block configures a set of components to forward resulting telemetry data to.

The following arguments are supported:

Expand table

| Name      | Type                     | Description                           | Default | Required |
|-----------|--------------------------|---------------------------------------|---------|----------|
| `logs`    | `list(otelcol.Consumer)` | List of consumers to send logs to.    | `[]`    | no       |
| `metrics` | `list(otelcol.Consumer)` | List of consumers to send metrics to. | `[]`    | no       |
| `traces`  | `list(otelcol.Consumer)` | List of consumers to send traces to.  | `[]`    | no       |

You must specify the `output` block, but all its arguments are optional. By default, telemetry data is dropped. Configure the `metrics`, `logs`, and `traces` arguments accordingly to send telemetry data to other components.

### `debug_metrics`

The `debug_metrics` block configures the metrics that this component generates to monitor its state.

The following arguments are supported:

Expand table

| Name                               | Type      | Description                                          | Default | Required |
|------------------------------------|-----------|------------------------------------------------------|---------|----------|
| `disable_high_cardinality_metrics` | `boolean` | Whether to disable certain high cardinality metrics. | `true`  | no       |

`disable_high_cardinality_metrics` is the Alloy equivalent to the `telemetry.disableHighCardinalityMetrics` feature gate in the OpenTelemetry Collector. It removes attributes that could cause high cardinality metrics. For example, attributes with IP addresses and port numbers in metrics about HTTP and gRPC connections are removed.

> Note
> 
> If configured, `disable_high_cardinality_metrics` only applies to `otelcol.exporter.*` and `otelcol.receiver.*` components.

### `passthrough`

The `passthrough` block configures which metric types should be passed through instead of being aggregated.

The following attributes are supported:

Expand table

| Name      | Type   | Description                                                                           | Default | Required |
|-----------|--------|---------------------------------------------------------------------------------------|---------|----------|
| `gauge`   | `bool` | Determines whether gauge metrics should be passed through as they’re or aggregated.   | `false` | no       |
| `summary` | `bool` | Determines whether summary metrics should be passed through as they’re or aggregated. | `false` | no       |

## Exported fields

The following fields are exported and can be referenced by other components:

Expand table

| Name    | Type               | Description                                                      |
|---------|--------------------|------------------------------------------------------------------|
| `input` | `otelcol.Consumer` | A value that other components can use to send telemetry data to. |

`input` accepts `otelcol.Consumer` data for metrics.

## Component health

`otelcol.processor.interval` is only reported as unhealthy if given an invalid configuration.

## Debug information

`otelcol.processor.interval` doesn’t expose any component-specific debug information.

## Example

This example receives OTLP metrics and aggregates them for 30s before sending to the next exporter.

Alloy ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy

```alloy
otelcol.receiver.otlp "default" {
  grpc { ... }
  http { ... }

  output {
    metrics = [otelcol.processor.interval.default.input]
  }
}

otelcol.processor.interval "default" {
  interval = "30s"
  output {
    metrics = [otelcol.exporter.otlphttp.grafana_cloud.input]
  }
}

otelcol.exporter.otlphttp "grafana_cloud" {
  client {
    endpoint = "https://otlp-gateway-prod-gb-south-0.grafana.net/otlp"
    auth     = otelcol.auth.basic.grafana_cloud.handler
  }
}

otelcol.auth.basic "grafana_cloud" {
  username = env("<GRAFANA_CLOUD_USERNAME>")
  password = env("<GRAFANA_CLOUD_API_KEY>")
}
```

Expand table

| Timestamp | Metric Name    | Aggregation Temporality | Attributes          | Value |
|-----------|----------------|-------------------------|---------------------|-------|
| 0         | `test_metric`  | Cumulative              | `labelA: example1`  | 4.0   |
| 2         | `test_metric`  | Cumulative              | `labelA: example2`  | 3.1   |
| 4         | `other_metric` | Delta                   | `fruitType: orange` | 77.4  |
| 6         | `test_metric`  | Cumulative              | `labelA: example1`  | 8.2   |
| 8         | `test_metric`  | Cumulative              | `labelA: example1`  | 12.8  |
| 10        | `test_metric`  | Cumulative              | `labelA: example2`  | 6.4   |

The processor immediately passes the following metric to the next processor in the chain because it’s a Delta metric.

Expand table

| Timestamp | Metric Name    | Aggregation Temporality | Attributes          | Value |
|-----------|----------------|-------------------------|---------------------|-------|
| 4         | `other_metric` | Delta                   | `fruitType: orange` | 77.4  |

At the next `interval` (15s by default), the processor passed the following metrics to the next processor in the chain.

Expand table

| Timestamp | Metric Name   | Aggregation Temporality | Attributes         | Value |
|-----------|---------------|-------------------------|--------------------|-------|
| 8         | `test_metric` | Cumulative              | `labelA: example1` | 12.8  |
| 10        | `test_metric` | Cumulative              | `labelA: example1` | 6.4   |

## Compatible components

`otelcol.processor.interval` can accept arguments from the following components:

- Components that export [OpenTelemetry `otelcol.Consumer`](../../../compatibility/#opentelemetry-otelcolconsumer-exporters)

`otelcol.processor.interval` has exports that can be consumed by the following components:

- Components that consume [OpenTelemetry `otelcol.Consumer`](../../../compatibility/#opentelemetry-otelcolconsumer-consumers)

> Note
> 
> Connecting some components may not be sensible or components may require further configuration to make the connection work correctly. Refer to the linked documentation for more details.