github.com/Jeffail/benthos/v3@v3.65.0/website/docs/components/processors/metric.md

---
title: metric
type: processor
status: stable
categories: ["Utility"]
---

<!--
     THIS FILE IS AUTOGENERATED!

     To make changes please edit the contents of:
     lib/processor/metric.go
-->

import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';

Emit custom metrics by extracting values from messages.


<Tabs defaultValue="common" values={[
  { label: 'Common', value: 'common', },
  { label: 'Advanced', value: 'advanced', },
]}>

<TabItem value="common">

```yaml
# Common config fields, showing default values
label: ""
metric:
  type: counter
  name: ""
  labels: {}
  value: ""
```

</TabItem>
<TabItem value="advanced">

```yaml
# All config fields, showing default values
label: ""
metric:
  type: counter
  name: ""
  labels: {}
  value: ""
  parts: []
```

</TabItem>
</Tabs>

This processor works by evaluating an [interpolated field `value`](/docs/configuration/interpolation#bloblang-queries) for each message and updating a emitted metric according to the [type](#types).

Custom metrics such as these are emitted along with Benthos internal metrics, where you can customize where metrics are sent, which metric names are emitted and rename them as/when appropriate. For more information check out the [metrics docs here](/docs/components/metrics/about).

## Examples

<Tabs defaultValue="Counter" values={[
{ label: 'Counter', value: 'Counter', },
{ label: 'Gauge', value: 'Gauge', },
]}>

<TabItem value="Counter">

In this example we emit a counter metric called `Foos`, which increments for every message processed, and we label the metric with some metadata about where the message came from and a field from the document that states what type it is. We also configure our metrics to emit to CloudWatch, and explicitly only allow our custom metric and some internal Benthos metrics to emit.

```yaml
pipeline:
  processors:
    - metric:
        name: Foos
        type: counter
        labels:
          topic: ${! meta("kafka_topic") }
          partition: ${! meta("kafka_partition") }
          type: ${! json("document.type").or("unknown") }

metrics:
  aws_cloudwatch:
    namespace: ProdConsumer
    region: eu-west-1
    path_mapping: |
      root = if ![
        "Foos",
        "input.received",
        "output.sent"
      ].contains(this) { deleted() }
```

</TabItem>
<TabItem value="Gauge">

In this example we emit a gauge metric called `FooSize`, which is given a value extracted from JSON messages at the path `foo.size`. We then also configure our Prometheus metric exporter to only emit this custom metric and nothing else. We also label the metric with some metadata.

```yaml
pipeline:
  processors:
    - metric:
        name: FooSize
        type: gauge
        labels:
          topic: ${! meta("kafka_topic") }
        value: ${! json("foo.size") }

metrics:
  prometheus:
    path_mapping: 'if this != "FooSize" { deleted() }'
```

</TabItem>
</Tabs>

## Fields

### `type`

The metric [type](#types) to create.


Type: `string`  
Default: `"counter"`  
Options: `counter`, `counter_by`, `gauge`, `timing`.

### `name`

The name of the metric to create, this must be unique across all Benthos components otherwise it will overwrite those other metrics.


Type: `string`  
Default: `""`  

### `labels`

A map of label names and values that can be used to enrich metrics. Labels are not supported by some metric destinations, in which case the metrics series are combined.
This field supports [interpolation functions](/docs/configuration/interpolation#bloblang-queries).


Type: `object`  
Default: `{}`  

```yaml
# Examples

labels:
  topic: ${! meta("kafka_topic") }
  type: ${! json("doc.type") }
```

### `value`

For some metric types specifies a value to set, increment.
This field supports [interpolation functions](/docs/configuration/interpolation#bloblang-queries).


Type: `string`  
Default: `""`  

### `parts`

An optional array of message indexes of a batch that the processor should apply to.
If left empty all messages are processed. This field is only applicable when
batching messages [at the input level](/docs/configuration/batching).

Indexes can be negative, and if so the part will be selected from the end
counting backwards starting from -1.


Type: `array`  
Default: `[]`  

## Types

### `counter`

Increments a counter by exactly 1, the contents of `value` are ignored
by this type.

### `counter_by`

If the contents of `value` can be parsed as a positive integer value
then the counter is incremented by this value.

For example, the following configuration will increment the value of the
`count.custom.field` metric by the contents of `field.some.value`:

```yaml
pipeline:
  processors:
    - metric:
        type: counter_by
        name: CountCustomField
        value: ${!json("field.some.value")}
```

### `gauge`

If the contents of `value` can be parsed as a positive integer value
then the gauge is set to this value.

For example, the following configuration will set the value of the
`gauge.custom.field` metric to the contents of `field.some.value`:

```yaml
pipeline:
  processors:
    - metric:
        type: gauge
        path: GaugeCustomField
        value: ${!json("field.some.value")}
```

### `timing`

Equivalent to `gauge` where instead the metric is a timing.