概要

Filebeatのパフォーマンスに関連する設定をまとめてみました。

公式ドキュメントは下記となります。
https://www.elastic.co/guide/en/beats/filebeat/current/configuration-filebeat-options.html

環境

Filebeat: v1.2.3

設定項目

Filebeatの設定ファイルである filebeat.yml の prospectors セクションの下記項目が主に性能に関連します。

backoff

ファイルの更新をチェックする待機時間（デフォルトは1s）

つまりはどれぐらいの頻度でファイルの更新をチェックするかということです。
デフォルトの1sであればほぼリアルタイムでの更新チェックとなるため、基本的に変更する必要はありません。
ただしファイルに更新がない場合、この待機時間は下記で説明する backoff_factor を「底」として max_backoff に到達するまで指数関数的に増加していきます。
ファイルに更新があった場合は、待機時間は当該の設定値（デフォルト1s）にリセットされます。

max_backoff

ファイルの更新をチェックするために、最大でどの程度待機するか（デフォルトは10s）

backoff_factor

更新チェックの待機時間を算出するための「底」（デフォルトは2）

backoff関連をまとめると

わかりやすく言えば、「待機時間 = 現在の待機時間 × backoff_factor 」として求めることができます。
（ただし待機時間の最大値は max_backoff であり、ファイルに更新があった場合待機時間は backoff にリセットされます。）

デフォルトの設定だと下記のような挙動になります。

1秒待機して更新チェック⇒更新なし
2秒（1s * 2）待機して更新チェック⇒更新なし
4秒（2s * 2）待機して更新チェック⇒更新なし
8秒（4s * 2）待機して更新チェック⇒更新なし
10秒（最大待機時間）待機して更新チェック⇒更新なし
10秒（最大待機時間）待機して更新チェック⇒更新なし
・
・
・
10秒（最大待機時間）待機して更新チェック⇒更新あり
1秒待機して更新チェック

待機時間を常に一定にしたい場合は backoff_factor を1に設定すると良いでしょう。
（その分負荷は大きくなります。）

spool_size

アウトプットの閾値となるイベントの回数（デフォルトは2048）

つまりデフォルトだと2048回イベントが発生した段階で連携先（Elasticsearch, Logstash）にイベントが送信されます。

idle_timeout

イベント送信までのタイムアウト値（デフォルトは5s）

イベントの回数が spool_size に到達せずとも、当該の設定時間が経過した段階で連携先（Elasticsearch, Logstash）にイベントが送信されます。
リアルタイムにイベントを送信したい場合は、このタイムアウト値を小さくすると良いでしょう。
（その分負荷は大きくなります。）

publish_async

非同期送信を行うかどうか（デフォルトはfalse）

true に設定した場合は、イベント送信の確認応答（ACK）を待たずして（非同期的に）イベントを送信します。
（スループットは向上しますがその分メモリ使用量は大きくなります。）

終わりに

当然ですが、リアルタイムに連携を行おうとすればするほど負荷は大きくなりますので、
リソースと要件を天秤にかけながら上手く調整してあげてください。
また今回はfilebeat自体の設定項目のみを紹介しましたが、連携先の種類に応じてパフォーマンスに関連する設定項目は存在します。（例えば、連携先がElasticsearchの場合は、bulk APIの件数 bulk_max_size など。）
これらはまた別の機会に紹介したいと思います。