Expose gRPC access-log buffering (buffer_size_bytes / buffer_flush_interval) on ProxyAccessLogSetting

Description:

Envoy Gateway builds CommonGrpcAccessLogConfig for the OpenTelemetry and ALS access-log sinks with only LogName, GrpcService and TransportApiVersion set (buildXdsAccessLog, internal/xds/translator/accesslog.go). buffer_flush_interval and buffer_size_bytes are never set, so both take Envoy's defaults of 1s and 16384 bytes, and nothing on ProxyAccessLogSetting can change them: on main it carries Format, Matches, Sinks and Type, and nothing else. backendSettings tunes the connection to the sink rather than the access logger's own buffer.

The reason this matters is that buffer_size_bytes is not only the flush threshold. In Envoy's implementation it also becomes max_buffer_size_bytes_, the cap past which canLogMore() returns false and further entries are discarded against logs_dropped. Envoy holds and retries what fits in the buffer while a stream is unavailable — an Envoy maintainer confirms this on envoyproxy/envoy#40806, "It will remain in the buffer. Envoy will keep trying to send it. The buffer needs to overflow and messages actually discarded for the metric to start being incremented" — but the overflow is dropped. So the buffer size sets how long a sink can be unavailable before access logs are lost.

At 16 KB that window is very small on a busy proxy. A JSON access-log record of roughly 1 KB means the buffer holds on the order of fifteen entries, so a gateway serving a few thousand requests per second can absorb only tens of milliseconds of sink unavailability. That is shorter than an ordinary rolling restart of the collector or backend receiving the logs, so records are dropped on routine deployments rather than only in incidents.

Envoy already supports raising this; the gap is that Envoy Gateway does not surface it. Operators who use the OTLP access-log sink for anything they need to be complete — usage accounting, per-request billing records, audit trails — currently have no way to trade proxy memory for a larger tolerance window, even though the underlying proto has supported it for a long time.

The request is to expose buffer_flush_interval and buffer_size_bytes on ProxyAccessLogSetting (or on the individual sinks), passing them through to CommonGrpcAccessLogConfig and keeping Envoy's current values as the defaults so existing behaviour is unchanged.

Two things that would be useful to settle as part of this, if maintainers have a view: whether the setting belongs per-sink or per-settings entry, given one settings entry can carry several sinks; and whether it should apply to the ALS sink as well as OpenTelemetry, since both go through the same CommonGrpcAccessLogConfig path.

Relevant Links:

• CommonGrpcAccessLogConfig — buffer_flush_interval and buffer_size_bytes and their defaults
• https://github.com/envoyproxy/envoy/issues/40806 — maintainer confirmation that entries are buffered and retried while the stream is down, with the overflow dropped
• https://github.com/envoyproxy/envoy/pull/45263 — grpc_entries_flushed / grpc_entries_flush_failed stats, merged 2026-06-30, which make the loss observable but not avoidable