オープニング meetupの概要
- v0.14.0 リリース
- 概要
- windows関係で何が起こるか
- APIの変更
本編
- Fluentdの昔と未来 2011/06/20に0.9.0リリース 5年
- 5年プロダクトが続いているなら成功している部類
- フルタイムコミッターが2名入ったことでアクティブにつづいている
- 最近さらにアクティブになっている
堅牢なOSSのコミュニティ まだまだ成長している
v0.14.0
- 昨日 05/31
- インストールしたらなんがしかのプラグインでバグがあるので、試してみて、Issueを登録してくれ
v0.12.0まで
以下の機能はリリース時にはなかった機能
- label
- @ERROR
- 設定ファイルを構造化できるので使わない手はない
- タグの書き換えをしなくてよい
- filter
- タグの書き換えをしなくてよい
- forward
- at-most-once at-least-once エラーが起きるとログが紛失する可能性があり、バッファを消さないようにする
- heartbeatをtcp/DNSラウンドロビン
- 分散環境構成(ココ2年)
- configのフォーマット
- log_level
- fluentd-ui
- buffer_queue
- 例外を上げるかわりに一番古いチャンクを捨てるなどする
未来をどうするか
- バックプレッシャー
- バッファがつまったときに 賢く 転送する
- in_tailで大量にやるときに転送量がつまる
- PubSub/pull forward→Kafkaと似たようなもの
- pushではなくpullすることで賢く
- bufferの圧縮
- bufferの分散とレプリケーション
- ログの構造をレプリケーションするのはapacheとかではすでにやっている
- service plugins
- fluentdの上にのせるサービスはハックするしかない
- source-match→serviceを使うことで、パッケージングしたサービスをFluentdのうえで走らせる
- 例: ES/KibanaをFluentdのうえで走らせる
- Schema-validate logging
- 書き込み先のストレージに変なデータが入ると困る
- validateされたログだけを転送したい
- 変なデータを送信してエラーだとか帯域を圧迫するとかっていうのをやめて、余計なデータを送らないようにする
- 認証とかも絡むかも
- configを中央で管理する
- ansibleとかshellとか使うのが今まで
- Dockerを使ってデプロイする
- fluentdの設定を、どこかのサーバで管理する
- git pushするとconfigをばらまくとか
- ロゴ
- デザイナから「見にくい」っていうご指摘
