Filebeatの性能チューニングポイントまとめ

## はじめに
Elastic社の軽量ログ収集ツールであるFilebeatで取り込んだログファイルをLogstashへ送る際の性能チューニングポイントを簡単にまとめてみました。
　![image.png](https://qiita-image-store.s3.amazonaws.com/0/211371/9ba86056-6b44-b6b9-dab8-19546f5a6eba.png)

## 構成図
このような構成でAWS NLB経由でスケールアウト構成のLogstashにログを送る感じです^^
![image.png](https://qiita-image-store.s3.amazonaws.com/0/211371/ecc800d2-a546-5337-640e-12f7bd47ad72.png)

## Filebeatとは
- Elasticsearchで有名なElastic社の軽量ログ収集エージェントになります。
- Beatsファミリーは用途に特化したBeatが存在し、ログファイルを取り込むものが**Filebeat**です。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/211371/c43a839a-4109-d9a4-6289-a578321a2954.png)

- いずれのBeatsもGo言語で書かれているため、非常にCPUやメモリ負荷が低く軽量でサーバに常駐するエージェントとして優しい作りとなっています。
- 2015年前まではLogstashをサーバに導入しログ収集していましたが、多くのメモリを消費するため、既存システムへの導入に二の足を踏むケースもありました。

**【参考】**
・[Filebeat Reference][01]

## チューニングポイント
Filebeatの大まかな内部動作は以下の通りになります。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/211371/7d4810db-b88d-6854-24cd-07610824375f.png)

#### Generalのパラメータ値
| 設定項目 | デフォルト値 | 説明 |
|---------|-------------|------|
| queue.mem.events | 4096 | キューに格納できるイベント数を設定します |
| queue.mem.flush.min_events | 2048 | イベントがOutputに出力される最小単位を設定します |
| queue.mem.flush.timeout | 1s | イベントがOutputに出力されるまでの最大待機時間を設定します|
| max_procs | CPU論理コア数 | 同時に実行できるCPUの最大数を設定します |
- `max_procs`はCPU論理コア数よりも少し多めに割り当てるのが性能を発揮します。
- `events`は大きくすればするだけメモリ使用率が増加します。(キューイングのバケツの大きさ)
- `flush.min_events`の値は`events`の範囲内に収まるように設定します。(バケツからイベントが溢れないようにする)
- `flush.min_events`を大きい値にすることでOutputスループットが向上します。(効率よくまとめて送ることが出来るから)
- `flush.min_events`と`flush.timeout`を0に設定するとイベントがメモリキューに入ったら何も待たずにすぐにOutputします。

**【参考】**
・[Specify general settings][02]
・[Configure the internal queue][03]

#### Logstash outputのパラメータ値
| 設定項目 | デフォルト値 | 説明 |
|---------|-------------|------|
| worker | 1 | LogstashへのOutput処理に利用するスレッド数を設定します |
| loadbalance | false | Output先のLogstashへ負荷分散するか否かを設定します |
| ttl | 0s | Logstashとの接続時間(秒)を設定します |
| pipelining | 2 | LogstashからのACKを待っている間に非同期的に送信されるバッチ数を設定します |
| bulk_max_size | 2048 | 一度にLogstashに送るイベント数を設定します |
- `worker`はLogstashとの接続数になります。`loadbalance`をtrueにした場合、`worker`×Logstash台数で合計のWorker数となります。
- 接続先のhostsにNLB_FQDNを1つ設定している場合でも`loadbalance`をtrueにしないとNLB配下のLogstash1台に対しての接続しか張られません。
- `ttl`は0だと無効となり、接続が張りっぱなしになります。
- `pipelining`を無効にしないと`ttl`を有効に出来ないので、NLBを接続先にする場合は注意が必要です。
- `bulk_max_size`を大きく設定することで1回にまとめて多くのイベントを効率良く送ることが出来ます。
- `bulk_max_size`だけを大きくしても、先に説明した`flush.min_events`を大きくしておかないと効果がありません。

**【参考】**
・[Configure the Logstash output][05]

## 余談
Beats5.xまでは複数のoutputを設定することが出来ましたが、6.xからは1つにしかoutput出来ません。
Beatsには複雑な処理をさせずにシンプルな処理に特化させようという意図がくみ取れますが、たまにファイルにも出したいと思うのが人の性という。。。
またFilebeat6.3から`flush.min_events`と`flush.timeout`のデフォルト値が変わってました。こまめに追うのはきついですね(*´Д｀)

**【参考】**
・[Configure Output][04]

## まとめ
以上、主なチューニングポイントでした。いかがでしたでしょうか？
もっと良いパラメータ値があれば是非コメント頂けますと有り難い限りです^^

軽量なエージェントにCPUとメモリを大量に使わせて、Logstashへのスループットを上げようというのが
そもそもembulkのようなバッチ処理用のエージェントではないでしょ！という声が聞こえてきそうですねｗ


[01]:https://www.elastic.co/guide/en/beats/filebeat/current/index.html "Filebeat Reference"
[02]:https://www.elastic.co/guide/en/beats/filebeat/6.0/configuration-general-options.html "Specify general settings"
[03]:https://www.elastic.co/guide/en/beats/filebeat/6.0/configuring-internal-queue.html "Configure the internal queue"
[04]:https://www.elastic.co/guide/en/beats/heartbeat/current/configuring-output.html "Configure Output"
[05]:https://www.elastic.co/guide/en/beats/filebeat/6.0/logstash-output.html "Configure the Logstash output"