Grafana Alloy for Low Badwith environments

Grafana Alloy
1

Hi everyone,

I’m currently evaluating Grafana Alloy for a fleet of edge devices (primarily vessels) where network conditions vary significantly between deployments. Some edges have stable, high-bandwidth links, while others rely on satellite or intermittent connections with highly fluctuating bandwidth, latency, and packet loss.

While looking at the otelcol.processor.batch configuration, I noticed that the batch parameters are statically configured. This means the same send_batch_size is used regardless of the network conditions experienced by a particular edge.

For example:

  • Vessel A: 100 Mbps stable connection → larger batches are efficient.
  • Vessel B: 20 Mbps connection → moderate batch size works well.
  • Vessel C: Satellite connection with fluctuating bandwidth and intermittent connectivity → large batches can increase retries, queue buildup, and export latency.

Reducing the batch size globally helps slower links but also increases request overhead for well-connected edges.

This made me wonder whether an adaptive batching capability would make sense.

Proposed idea

The idea would be an optional adaptive mode that dynamically adjusts the effective batch size at runtime based on exporter health rather than relying on a fixed configuration.

Rather than using only bandwidth, the controller could observe metrics such as:

  • Export latency
  • Retry rate
  • Consecutive failures
  • Sending queue utilization
  • Export success rate
  • Flush duration
  • Other exporter metrics already exposed by Alloy/OpenTelemetry Collector

The controller could then:

  • Increase the batch size gradually when exports are healthy.
  • Reduce the batch size quickly when retries, latency, or queue pressure increase.
  • Use hysteresis or moving averages to avoid oscillations.

Something conceptually similar to:

otelcol.processor.batch "default" {
  send_batch_size = 8192

  adaptive {
    enabled = true
    min_batch_size = 500
    max_batch_size = 10000
    evaluation_interval = "30s"
  }
}

If adaptive is not configured, the existing behavior would remain unchanged.

Questions

Before I start working on a proof of concept, I wanted to ask the maintainers:

  1. Has this idea already been discussed or attempted?
  2. Is there an existing roadmap item for adaptive batching or adaptive flow control?
  3. Since Alloy wraps the OpenTelemetry Collector, would this functionality be more appropriate in the upstream OpenTelemetry Collector batch processor rather than Alloy itself?
  4. Are there any architectural concerns that would make this approach unsuitable?
  5. Would maintainers be open to reviewing a proposal or proof of concept if the design aligns with the project?

My goal is to contribute something that is useful for edge and intermittently connected deployments while remaining fully backward compatible.

I’d appreciate any feedback or guidance before I start implementing it.