Pinging code owners:

• processor/interval: @RichieSams @sh0rez

See Adding Labels via Comments if you do not have permissions to add labels yourself.

I think the actual expected result is that only one of the two points will be sent?

I think the actual expected result is that only one of the two points will be sent?

Yes, sorry that is what I actually meant. Updated the description of the issue.

Ok, I ran this locally both with and without the interval processor, and I see what you're saying. The interval processor is correctly aggregating. Note that the "extra" metric exports you're seeing are empty:

2025-02-13T16:37:14.146Z	info	Metrics	{"kind": "exporter", "data_type": "metrics", "name": "debug", "resource metrics": 0, "metrics": 0, "data points": 0}

No resource metrics, no metrics, and no datapoints.

func (p *Processor) exportMetrics() {
	md := func() pmetric.Metrics {
		p.stateLock.Lock()
		defer p.stateLock.Unlock()

		// ConsumeMetrics() has prepared our own pmetric.Metrics instance ready for us to use
		// Take it and clear replace it with a new empty one
		out := p.md
		p.md = pmetric.NewMetrics()

		// Clear all the lookup references
		clear(p.rmLookup)
		clear(p.smLookup)
		clear(p.mLookup)
		clear(p.numberLookup)
		clear(p.histogramLookup)
		clear(p.expHistogramLookup)
		clear(p.summaryLookup)

		return out
	}()

	if err := p.nextConsumer.ConsumeMetrics(p.ctx, md); err != nil {
		p.logger.Error("Metrics export failed", zap.Error(err))
	}
}

We can add a check to the end, where we skip calling ConsumeMetrics() if md is empty.

I'm making a PR

@RichieSams I don't think that is the issue. Note the timestamps of the two points that are printed by the debug exporter are very close:
Timestamp: 2025-02-13 16:37:04.135426715 +0000 UTC vs Timestamp: 2025-02-13 16:37:04.258232968 +0000 UTC. Shouldn't one of those be dropped?

I don't think that is the issue. Note the timestamps of the two points that are printed by the debug exporter are very close:
Timestamp: 2025-02-13 16:37:04.135426715 +0000 UTC vs Timestamp: 2025-02-13 16:37:04.258232968 +0000 UTC. Shouldn't one of those be dropped?

The main ConsumeMetrics() has the same problem. It will aggregate and "consume" metrics correctly. But it will always forward on a root metrics instance, even if it's empty.

So the fix will need to be applied in both places

It seems like you are still missing the core issue. Two data points that are within 0.2 seconds of each other are sent to the debug exporter with the interval set to 5s. Your fix still makes sense, but I don't think it is the core issue here. Or am I misunderstanding how the interval processor is supposed to work?

I understand. Interval processor works as follows:

1. It receives metrics at any time from upstream (ConsumeMetrics())
2. Inside that, the "intention" is that interval processor will fully consume (and not pass on) any aggregated metrics. And non-aggregated metrics will be passed on right then and there
3. At the given "interval time", the processor will re-export the aggregated metrics

There are two problems:

1. In step 2, the processor is correctly consuming all metrics to be aggregated. This results in an "empty" metric set. The "bug" is that interval processor will still send this empty metric set downstream. (This can be seen in the debug exporter).
2. In step 3, a similar problem occurs. If no metrics have come in from upstream, interval processor will have an empty metric set. And it will still forward that on downstream.

Thus my PR attempts to fix both those issue by adding a hard check before we send things downstream: If the metric set is empty, don't bother sending it

To answer your question directly:

Two data points that are within 0.2 seconds of each other are sent to the debug exporter with the interval set to 5s.

Yes. But if you look at the data, you'll notice that the second one is completely empty.

2025-02-13T16:37:23.001Z	info	Metrics	{"kind": "exporter", "data_type": "metrics", "name": "debug", "resource metrics": 0, "metrics": 0, "data points": 0}
2025-02-13T16:37:23.001Z	info		{"kind": "exporter", "data_type": "metrics", "name": "debug"}
2025-02-13T16:37:24.145Z	info	Metrics	{"kind": "exporter", "data_type": "metrics", "name": "debug", "resource metrics": 0, "metrics": 0, "data points": 0}
2025-02-13T16:37:24.145Z	info		{"kind": "exporter", "data_type": "metrics", "name": "debug"}

I'm only looking at these two metrics (ignoring empty ones):

2025-02-13T16:37:08.001Z	info	Metrics	{"kind": "exporter", "data_type": "metrics", "name": "debug", "resource metrics": 1, "metrics": 1, "data points": 1}
2025-02-13T16:37:08.001Z	info	ResourceMetrics #0
Resource SchemaURL: https://opentelemetry.io/schemas/1.13.0
ScopeMetrics #0
ScopeMetrics SchemaURL: 
InstrumentationScope  
Metric #0
Descriptor:
     -> Name: gen
     -> Description: 
     -> Unit: 
     -> DataType: Gauge
NumberDataPoints #0
StartTimestamp: 1970-01-01 00:00:00 +0000 UTC
Timestamp: 2025-02-13 16:37:04.135426715 +0000 UTC
Value: 0
	{"kind": "exporter", "data_type": "metrics", "name": "debug"}
2025-02-13T16:37:18.001Z	info	Metrics	{"kind": "exporter", "data_type": "metrics", "name": "debug", "resource metrics": 1, "metrics": 1, "data points": 1}
2025-02-13T16:37:18.001Z	info	ResourceMetrics #0
Resource SchemaURL: https://opentelemetry.io/schemas/1.13.0
ScopeMetrics #0
ScopeMetrics SchemaURL: 
InstrumentationScope  
Metric #0
Descriptor:
     -> Name: gen
     -> Description: 
     -> Unit: 
     -> DataType: Gauge
NumberDataPoints #0
StartTimestamp: 1970-01-01 00:00:00 +0000 UTC
Timestamp: 2025-02-13 16:37:04.258232968 +0000 UTC
Value: 1
	{"kind": "exporter", "data_type": "metrics", "name": "debug"}