"one log record size is greater than max size" dropping batch

[defields923]

Component(s)

exporter/exporterhelper, exporter/exporterhelper/internal/queuebatch

Describe the issue you're reporting

After deploying some new services are sending data through an collector, I am now seeing this log:

2025-12-08T20:38:34.054Z warn queuebatch/partition_batcher.go:75 Failed to split request. {"resource": {"service.instance.id": "", "service.name": "foo", "service.version": "1.1.0"}, "otelcol.component.id": "otlp/newrelic", "otelcol.component.kind": "exporter", "otelcol.signal": "logs", "error": "one log record size is greater than max size, dropping items: 4553"}

I am using this exporter configuration:

  otlp/newrelic:
    endpoint: ${env:NEW_RELIC_OTLP_ENDPOINT:-https://otlp.nr-data.net:443}
    headers:
      api-key: ${NR_KEY}
    tls:
      insecure: false
    compression: zstd
    sending_queue:
      queue_size: ${env:EXPORTER_SENDING_QUEUE_SIZE:-1000} # Default
      num_consumers: ${env:EXPORTER_QUEUE_NUM_CONSUMERS:-6} 
      batch:
        flush_timeout: 200
        min_size: ${env:EXPORTER_SENDING_QUEUE_SIZE:-1000}
        max_size: ${env:EXPORTER_SEND_BATCH_MAX_SIZE:-750000}
        sizer: ${env:EXPORTER_SEND_BATCH_SIZER:-bytes}
    timeout: ${env:EXPORTER_SEND_TIMEOUT:-5s}

I am guessing that one of these new services is sending a log message that is very large. I already have attribute length truncation set via system property "otel.attribute.value.length.limit": 4095, which is NewRelic's limit. But I am not truncating the log record body.

Is my guess correct? Should I implement a transform processor to truncate the body, too?

Also, why does this need to drop the entire batch? Is it too expensive to simply drop the offending log?

Thanks

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[github-actions]

Pinging code owners:

• exporter/exporterhelper: @bogdandrutu @dmitryax

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

[axw]

I am guessing that one of these new services is sending a log message that is very large.

...

Is my guess correct?

It could be the message, or it could be that the sum of all the attributes exceeds the limit. Either way, the issue is that one log record exceeds the limit, and log records can't be split.

Should I implement a transform processor to truncate the body, too?

I recommend using the debug exporter to identify out what specifically is too large. Then you can decide what needs changing.

Also, why does this need to drop the entire batch? Is it too expensive to simply drop the offending log?

I don't know the answer to that one. Seems like it could probably be a config option. @bogdandrutu @dmitryax WDYT?