Processor duration metric

[andborja]

Component(s)

processor/processorhelper

Describe the issue you're reporting

Is your feature request related to a problem? Please describe.

Processing duration is a critical metric for understanding and optimizing collector performance, especially for computationally intensive processors. Currently, this metric is not produced consistently across the collector's processors, making it difficult to:

• Identify performance bottlenecks in processing pipelines
• Tune processor configurations effectively
• Monitor processing latency in production environments
• Compare performance characteristics across different processors
• This inconsistency forces users to either implement custom duration metrics in individual processors or rely on external monitoring, leading to fragmented observability.

Describe the solution you'd like

Implement automatic duration measurement as part of the processorhelper module to provide consistent processing duration metrics across all processors. The solution should:

1. Automatic instrumentation: Measure processing duration for all signal types (logs, metrics, traces) without requiring processor-specific code
2. Standard metric naming: Follow the universal telemetry naming convention (e.g., otelcol_processor_duration)
3. Low overhead: Ensure minimal performance impact on data processing

Implementation approach:

• Extend the existing processorhelper.New{Logs,Metrics,Traces} functions to automatically wrap processing functions with duration measurement
• Use histogram metrics to capture duration distributions
• Leverage the existing observability infrastructure in obsreport.go

Describe alternatives you've considered

1. Per-processor implementation: Each processor could implement its own duration metrics, but this would:

• Lead to inconsistent metric naming and semantics
• Require duplicated instrumentation code
• Make cross-processor performance comparisons difficult

2. External monitoring: Users could monitor duration externally (e.g., through proxy metrics), but this:

• Lacks component-level granularity
• Doesn't integrate with the collector's telemetry ecosystem
• Requires additional infrastructure setup

Additional context

The implementation would be similar to the existing item count and size measurements already available in some processors, but would provide duration visibility across the entire processor ecosystem.

[andborja]

PR at #13227