Carpe Diem

備忘録

Fluentdを0.14にバージョンアップした時の対応

概要

Fluentdを0.12から0.14へアップデートしました。
その時にtd-agent.confやらpluginで色々と変更点があったのでその時の対応をまとめます。

環境

  • fluentd 0.14.21
  • fluent-plugin-s3 1.0.0.rc6

td-agent.confの変更点

root_dirができた

以前はbuffer毎に

<match pattern>
  buffer_type file
  buffer_path /var/fluentd/buffer/
  ...
</match>

といった感じに1つ1つpathを設定する必要がありましたが、

<system>
  root_dir /path/fluentd/root
</system>

と設定すれば、システム内の/path/fluentd/root/worker0/plugin_idに保存されるようになります。

マルチプロセスに対応した

Fluentd v0.14.12 has been released | Fluentd

で発表されましたが、ついにデフォルトでマルチプロセスに対応してくれるようになりました。以下のように設定します。

<system>
  workers 8
  root_dir /path/fluentd/root
</system>

ただし以下の点を注意してください。

  • pluginがまだほとんど対応してないので、インストールしてると使えない
  • bufferのlimit_size系はworkerの数だけ倍になる

bufferの書き方が変わった

以下のように<buffer>セクションを使う書き方に変わりました。

before

<match pattern>
  # omit the part about @type and other output parameters

  buffer_type memory
  buffer_chunk_limit 256m
  buffer_queue_limit 128
  flush_interval 60s
  retry_limit 17
  retry_wait 1s
</match>

after

<match pattern>
  # omit the part about @type and other output parameters

  <buffer>
    @type memory
    chunk_limit_size 256m
    queue_limit_length 128
    flush_interval 60s
    retry_max_times 17
    retry_wait 1s
  </buffer>
</match>

これにともなってフィールド名も微妙に変わっているので、

Buffer section configurations | Fluentd

github.com

を参考に修正してください。

time sliced pluginの書き方が変わった

fluentdは時間ベースでchunkを分けることもできます。以前は以下のように

<match pattern>
  # omit the part about @type and other output parameters

  buffer_type file
  path /my/buffer/file.*.log
  time_slice_format %Y%m%d%H
  buffer_chunk_limit 256m
  buffer_queue_limit 128
</match>

と、time_slice_format %Y%m%d%Hのように設定することで、bufferとして

/my/buffer/file.2017092904_0.log
/my/buffer/file.2017092904_1.log
/my/buffer/file.2017092905_0.log

といった形で保持されました。これが0.14からは

<match pattern>
  # omit the part about @type and other output parameters
  path /my/buffer/file.*.log

  <buffer time>
    @type file
    chunk_limit_size 256m
    queue_limit_length 128
    timekey 1h
  </buffer>
</match>

といった書き方に変わります。

retry_countがリセットされなくなった

monitoringで取得できるリトライ回数が、以前は

      "output_plugin": true,
      "buffer_queue_length": 0,
      "buffer_total_queued_size": 0,
      "retry_count": 8,

といった感じでretry_countだけでした。
しかし0.14では

      "buffer_total_queued_size":0,
      "retry_count":2,
      "retry":{
        "start":"2016-12-27 07:36:14 +0700",
        "steps":1,
        "next_time":"2016-12-27 07:37:16 +0700"
      }

というretry.stepsというフィールドができてます。
動かしてみるとretry_countはリセットされずに増え続けており、元はバグっぽかったのですが今後はretry.stepsを使おうという流れになったようです。

github.com

ソース