# Throttling log output from Filebeat directly?

**URL:** https://discuss.elastic.co/t/throttling-log-output-from-filebeat-directly/168862
**Category:** Beats
**Tags:** filebeat
**Created:** [February 18, 2019, 3:42pm UTC](https://discuss.elastic.co/t/throttling-log-output-from-filebeat-directly/168862 "2019-02-18T15:42:03Z")
**Posts on this page:** 1
**Showing post:** 8

<div class="post-metadata">

### Author: ![steffens](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/steffens/32/79630_2.png) [@steffens](https://discuss.elastic.co/u/steffens)
#### Post date: [March 11, 2019, 3:03pm UTC](https://discuss.elastic.co/t/throttling-log-output-from-filebeat-directly/168862/8 "2019-03-11T15:03:08Z")

</div>

> Is this actually the case if we have one beat.Client instance per input/prospector instead of one beat.Client per harvester?

Nice catch. I'd say my comment is somewhat wrong. The way filebeat currently works, the limit is not per harvester, but per input.

One input configuration can create an unknown number of harvesters. As users can not configure the number of harvesters, I'd say it would make sense for filebeat inputs to always apply the limit/policy to the complete input, such that the 500eps would be a shared bandwidth limitation for all harvester created per input. Enforcing this semantics also reduces the per Beat implementation details/abstractions leaking into configs.

---

_[View the full topic](https://discuss.elastic.co/t/throttling-log-output-from-filebeat-directly/168862)._