Request

Grafana Cloud (GC) has an OpenTelemetry gateway which users can use via Alloy's otelcol.exporter.otlphttp component. Unfortunately, users will often send batches of data which are too large for GC to ingest. The traditional way to prevent this is to include otelcol.processor.batch in the Alloy config and to set send_batch_max_size to a sensible value (it is 0 by default, which means there's no maximum). This has two limitations:

• The batch processor has to be explicitly included
• The user needs to think about what value makes sense for them
• send_batch_max_size is the number of metric datapoints, log lines, and spans. It's not about the bytes on disk that the batch takes. Some of the limits on GC side are about the bytes on disk, which makes it harder to configure a sensible batch limit.

These days the batch processor is towards end of life and there are new batch options available in the exporter settings. Unfortunately Alloy doesn't have this new "batch" block yet. It would be good if we can leverage those new options instead of adjusting the defaults for the batch processor.

However, I'm not sure what the limits on GC currently are. We need information about the 3 main telemtry types - logs, metrics, and traces. We need to know whether there are limitations for both the amount of datapoints/log lines/spans, and for the amount of bytes that they could take on disk. It'd be good if folks working for Grafana's databases department could opine with what those limits are.

Use case

Currently the Alloy defaults don't work for some customers. It introduces friction during onboarding.