There are a few other threads discussing this, but they focus on workarounds by adjusting the input or output plugins. What I would like to understand is what can actually
cause this error to occur?
2016-06-27 20:00:29 +0000 [warn]: Size of the emitted data exceeds buffer_chunk_limit.
2016-06-27 20:00:29 +0000 [warn]: This may occur problems in the output plugins ``at this server.``
2016-06-27 20:00:29 +0000 [warn]: To avoid problems, set a smaller number to the buffer_chunk_limit
2016-06-27 20:00:29 +0000 [warn]: in the forward output ``at the log forwarding server.``
I encountered this issue before when using detach_process (
https://github.com/fluent/fluentd/issues/930), and the root of that problem was the input forwarder was batching together multiple records before sending along to the output plugin, and despite the individual records being small, batching them together resulted in the data passed to the output plugin exceeding buffer_chunk_limit.
I'm now running without detach_process, and encountered this warning again, and am thus trying to understand how it could occur. Obviously it could happen if any individual record exceeds buffer_chunk_limit, but are there any other conditions which could trigger it?
So far I've just seen it in the logs once on a production system, and have not been able to reproduce it. The relevant bits of my configuration are here:
<source>
type forward
</source>
<match ztrack.count>
@type kinesis-aggregation
region us-west-2
stream_name xxx
aws_key_id xxx
aws_sec_key xxx
include_time_key false
include_tag_key false
buffer_chunk_limit 999k
buffer_queue_limit 30000
buffer_queue_full_action drop_oldest_chunk
flush_interval 10s
try_flush_interval 0.1
queued_chunk_flush_interval 0.01
disable_retry_limit true
num_threads 50
buffer_type file
buffer_path /var/log/fluentd/ztrack.count*.buffer
</match>
Thanks,
-Chris