Best Practices for Edge Delta Processors

Overview

The Edge Delta Processor nodes (formerly known as multi-processor nodes) enable you to organize and manage multiple processors (such as extract and aggregate metric processors) under a unified logic block. This is helpful for building structured processing flows using conditional logic and reusable groups. However, improper configuration can lead to high memory usage, excessive metric generation, and agent instability. This guide outlines configuration best practices to help you avoid these issues.

When to Use a Processor Node

Use a processor node to:

• Encapsulate related processors under a shared telemetry type and condition.
• Create modular logic flows that are easier to manage.
• Branch logic using conditional groups.

Avoid using a single processor to handle many unrelated logic flows, especially if they share relaxed conditions or overlapping scopes.

Common Pitfalls

1. Broad or Overlapping Conditions

When multiple conditional groups or extract/aggregate rules match the same data, each one may execute independently—leading to multiple versions of the same metric.

Issue: Metric duplication, excessive memory use, and difficulty tracking root cause.

Solution:

• Use mutually exclusive conditions for each rule or group.
• Use name == checks to tightly couple aggregate metrics to corresponding extract metrics.
• Avoid duplicating logic across groups unless absolutely necessary.

2. Overloading One Processor Node

Stacking too many extract and aggregate metric rules into one processor (especially without exclusive conditions) can overwhelm the agent.

Issue: CPU/memory spikes, OOMKills, and pipeline restarts.

Solution:

• Split logic into multiple processors when:
  • You have more than 2-3 extract-aggregate metric chains.
  • Different chains process different telemetry types.
  • Different chains operate under separate logic scopes.

3. Missing or Loose name == Conditions in Aggregate Processors

Aggregate metrics without a scoping condition may pick up more metric items than expected.

Issue: Metrics aggregate unrelated data, balloon in cardinality, and consume memory.

Solution:

• Always use a name == "..." condition in your aggregate rule to ensure it only matches the corresponding extract metric.

Recommendations

Use Separate Processors per Metric Flow

- type: sequence
  processors:
  - type: extract_metric
    extract_metric_rules:
    - name: latency
      gauge:
        value: attributes["response_time_ms"]
  - type: aggregate_metric
    condition: name == "latency"
    aggregate_metric_rules:
    - name: latency_avg
      interval: 1m
      aggregation_type: avg

Use Conditional Groups for Clean Branching

- type: sequence
  processors:
  - type: sequence
    condition: attributes["level"] == "Error"
    processors:
    - type: extract_metric
      ...
    - type: aggregate_metric
      ...

Disable Unused Logic Safely

• Toggle the parent conditional group, not just individual processors.
• Confirm that child processors are truly inactive by inspecting pipeline behavior.

Leverage the Final Option

Use the Final flag to stop further processing of a data item after a processor finishes. This prevents downstream duplication.

Debugging and Optimization

Detecting Excess Metric Volume

• Use the Metrics Explorer to visualize:
  • Metric count over time
  • Cardinality grouped by name or attributes

Profiling High Memory Agents

• Enable profiling via the UI for affected agents.
• Look for spikes tied to:
  • Metric extraction and aggregation
  • ebpf-based sources (Service Map, K8s Trace)

Triage Checklist

• Is metric volume increasing after a recent pipeline change?
• Are conditions overlapping across extract/aggregate rules?
• Are processors grouped under a single high-traffic node?
• Are logs or pprof showing GC pressure or agent crashes (OOMKills)?

Summary

Related Topics

• Extract Metric Processor
• Aggregate Metric Processor
• Conditional Group Processor
• Extract and Aggregate Metrics Quickstart