Edge Delta Extract Metric Processor

The Edge Delta extract metric processor generates metrics from other data items.

7 minute read

Overview

The extract metric processor converts a data item into a metric item and uses one of its fields as the metric. This is useful if your data item already contains a useful metric.

See Extract and Aggregate Metrics for more information about using the extract metric processor.

For detailed instructions on how to use multiprocessors, see Use Multiprocessors.

Example Input

Consider this log:

{
  "_type": "log",
  "timestamp": 1744873926928,
  "body": "{\"timestamp\": \"2025-04-17T07:12:05.923408Z\", \"level\": \"Alert\", \"msg\": \"processing failed\", \"user\": {\"email\": \"wang.xiu@mymailservice.com\", \"id\": \"96dd851f-e791-4388-98c7-cbb7e3df50b2\", \"name\": \"08ecbb0d-a961-4c8a-8db0-040e537257af\"}, \"request\": {\"ip\": \"172.24.16.218\", \"method\": \"DELETE\", \"path\": \"/json/view\"}, \"status\": 500, \"response_time_ms\": 7837}",
  "resource": {
    ...
  },
  "attributes": {
    "level": "Alert",
    "msg": "processing failed",
    "request": {
      "ip": "172.24.16.218",
      "method": "DELETE",
      "path": "/json/view"
    },
    "response_time_ms": 7837,
    "status": 500,
    "timestamp": "2025-04-17T07:12:05.923408Z",
    "user": {
      "email": "wang.xiu@mymailservice.com",
      "id": "96dd851f-e791-4388-98c7-cbb7e3df50b2",
      "name": "08ecbb0d-a961-4c8a-8db0-040e537257af"
    }
  }
}

Note: The body is JSON that has been parsed into attributes.

Note: The extract metric processor can consume doubles or integers.

Suppose you want to monitor the count of HTTP response codes across all logs. You can convert the log into a metric focused on the status attribute.

Configuration

In this example, the extract metric processor creates a gauge type metric with a count of unique values found in the attributes["status"] field.

Note: The status attribute is an integer. If it was a string, you have the opportunity to convert the data type using the target field with the OTTL convertor. You should convert it into a double (Double(attributes["status"])), but integers (Int(attributes["status"])) are also accepted by the processor.

The corresponding YAML is as follows (without the parse JSON processor).

- name: kubernetes_input_jt1iw_multiprocessor
  type: sequence
  processors:
  - type: extract_metric
    metadata: '{"id":"_rK4ucX4G8oDcrXWwXh2r","type":"extract_metric","name":"Extract
      Metric"}'
    extract_metric_rules:
    - name: status_code
      description: A count of each unique status code
      unit: "1"
      gauge:
        value: attributes["status"]

Example Output

This results in metrics such as the following:

{
  "_type": "metric",
  "timestamp": 1744875106543,
  "resource": {
    ...
  },
  "attributes": {
    "level": "Info",
    "msg": "processing succeeded",
    "request": {
      "ip": "10.192.49.15",
      "method": "GET",
      "path": "/json/view"
    },
    "response_time_ms": 255,
    "status": 200,
    "timestamp": "2025-04-17T07:31:43.684354Z",
    "user": {
      "email": "jane.smith@demomail.com",
      "id": "110abee8-d4e5-4a80-8984-54dc1c04930f",
      "name": "7b982abe-a8fe-4429-9c8f-30e3692f8caa"
    }
  },
  "description": "A count of each unique status code",
  "gauge": {
    "value": 200
  },
  "kind": "gauge",
  "name": "status_code",
  "unit": "1",
  "_stat_type": "value"
}

Note how the attributes have been adopted from the parent log. This will be useful for later aggregation with dimension groups, for example, using the aggregate metric processor.

Options

Select a telemetry type

You can specify, log, metric, trace or all. It is specified using the interface, which generates a YAML list item for you under the data_types parameter. This defines the data item types against which the processor must operate. If data_types is not specified, the default value is all. It is optional.

It is defined in YAML as follows:

- name: multiprocessor
  type: sequence
  processors:
  - type: <processor type>
    data_types:
    - log

Condition

The condition parameter contains a conditional phrase of an OTTL statement. It restricts operation of the processor to only data items where the condition is met. Those data items that do not match the condition are passed without processing. You configure it in the interface and an OTTL condition is generated. It is optional. You can select one of the following operators:

Operator	Name	Description	Example
`==`	Equal to	Returns `true` if both values are exactly the same	`attributes["status"] == "OK"`
`!=`	Not equal to	Returns `true` if the values are not the same	`attributes["level"] != "debug"`
`>`	Greater than	Returns `true` if the left value is greater than the right	`attributes["duration_ms"] > 1000`
`>=`	Greater than or equal	Returns `true` if the left value is greater than or equal to the right	`attributes["score"] >= 90`
`<`	Less than	Returns `true` if the left value is less than the right	`attributes["load"] < 0.75`
`<=`	Less than or equal	Returns `true` if the left value is less than or equal to the right	`attributes["retries"] <= 3`
`matches`	Regex match	Returns `true` if the string matches a regular expression	`isMatch(attributes["name"], ".*\\.name$"`

It is defined in YAML as follows:

- name: _multiprocessor
  type: sequence
  processors:
  - type: <processor type>
    condition: attributes["request"]["path"] == "/json/view"

Add Rule

Click to add additional metrics to extract. One metric is generated for each rule per data item.

Metric Name

Define a name for the metric.

Description

Provide a description for the metric. This is added to the metric item in the description field.

Unit

Select Count or Bytes as the unit of measurement.

Conditions

The conditions parameter is a child of the metric definition. It contains a conditional phrase of an OTTL statement. It restricts operation of the processor to only data items where the condition is met, for the parent metric. This is different to the condition parameter which toggles the entire processor. Those data items that do not match the condition are passed without a metric being generated (other metrics in the same processor might still be created). It is specified by the tool as an OTTL condition when you select the condition fields in the interface and it is optional.

It is defined in YAML as follows:

- name: _multiprocessor
  type: sequence
  processors:
  - type: <processor type>
    aggregate_metric_rules:
    - name: <metric name>
      conditions:
      - attributes["level"] = Error

Metric

Specify which target field to use as the metric in this section. You specify the OTTL path and if necessary convert the data type with the OTTL convertor. You should convert it into a double (Double(attributes["status"])).

Note: The extract metric processor can consume doubles or integers.

You also specify the metric type:

Gauge: A gauge is a metric that represents a value at a single point in time. It can go up or down. For example, CPU usage (e.g., 57%), memory usage, number of active sessions. Think of it like a speedometer—it shows the current value, not an accumulation over time.
Sum: A sum represents a total or accumulated value over time. It’s used to track things that only go up (usually), such as total requests served, bytes sent, etc. When defining a sum, you can further specify how it’s recorded:
- Cumulative: A cumulative sum is an ever-increasing counter (unless reset). Each new value includes all previous values. For example, a web server might report a cumulative total of bytes sent (e.g., 1000 → 2000 → 3000). It is useful for tracking long-term totals, and systems can compute rates from this.
- Delta: A delta sum represents the change in value since the last report. Each value is independent and represents a slice in time. For example, if 500 bytes were sent in the last 5 seconds, the log reports 500. This is easier to process directly when you just want the change in a given period.
- Monotonic: This is a flag that applies to a sum. A monotonic sum means the value should never decrease, only stay the same or increase. If a drop is observed, it may indicate a reset or error. For example if bytes sent goes from 2000 to 1500, and it’s marked as monotonic, the system will treat this as a reset.

Final

The final parameter specifies whether successfully processed data items should continue to subsequent processors within the same multiprocessor node. Data items that fail to be processed by the processor will be passed to the next processor in the node regardless of this setting. You select the slider in the tool which specifies it for you in the YAML as a Boolean. The default is false and it is optional.

It is defined in YAML as follows:

- name: multiprocessor
  type: sequence
  processors:
    - type: <processor type>
    final: true

Keep original telemetry item

This option defines whether to delete the original unmodified data item after it is processed. For example, you can keep the original log as well as any metrics generated by an extract metric processor. If you select this option your data volume will increase.