Fluentdの利用方法とこれから行いたい事

1. fluentdで注意するべきところ
望月 大作
1

2. アジェンダ
1. 自己紹介
2. fluentdとは？
3. 使う上での注意点
4. 簡単なテスト方法
5. より効率的に使うために
2

3. 自己紹介
 所属： ガンホー・オンライン・エンターテイメント株式会社
 名前： 望月 大作
 職種： 肩書はエンジニアですが、分析チームの管理をしてます
 業務： 各タイトルのログ集計、グラフ作成、分析、ツール作成
 関連しているタイトル： クロノマギア、サモンズボード、ディバインゲート零
ケリ姫スイーツ、セブンスリバース・・・等
 趣味： ゲーム、サイクリング、ボードゲーム、剣道、フットサル
3

4. fluentdとは？
4

5. fluentdとは？
Rubyで動いているオープンソースの
データコレクターやデータログ収集ツールと呼ばれるソフトウェア
・メリット
ほぼリアルタイムにデータを送信できる（ストリーミング送信）
スキーマを考える必要がない
・デメリット
データの担保が行えない
送信されているのか判断しにくい
5

6. fluentdとは？
何故使用するのか？
 ログファイルを別の場所に蓄積させる
 そのままサーバ上に保存をしているとHDDが溢れてしまい、動かなくなる
 出来るなら即座に調査をしたい
 不具合が発生した場合にできる限り直前のログを追いたい
（緊急メンテや補填の処理はできる限り迅速にしたいので・・・ ）
6

7. 使う上での注意点
7

8. 使う上での注意点①
 Rubyのバージョンに依存している
fluentdを普通に入れるとサーバ内のRubyのバージョン依存が面倒
• td-agentをインストールすると簡単
• curl -L http://toolbelt.treasuredata.com/sh/install-redhat-td-agent2.sh | sh
最新版はこれでインストール可能
8

9. 使う上での注意点②
 データが消えてしまう
何故データが消えてしまう可能性があるのか？
• データの送信が失敗している
• require_ack_responseを必ず入れる事により、必ず1度はログ送信がされる
• CPUの使用率が100%になっている
• fluentdは基本的にはシングルスレッドでの動作
• 設定ファイルの設定やログの送信量によりCPUが100%に張り付くと
ログを送信できずにロストしてしまう
9

10. 使う上での注意点③
 データを多重に送信してしまう
require_ack_responseの設定の為に起こる現象
• 多重送信されるものとして扱う以外対処が難しい
• 私もまだこの部分の完全な解決は行えていない
• サーバのIPとユニークキーをログに追加させ、
ユニーク化をさせて判断させる事を検討中
10

11. 使う上での注意点④
 エラーが発生すると、送信処理が詰まってしまう
• 書込み権限が無くエラーが発生して、その後の処理が止まっている
• 本番とテスト環境でtd-agentを分けて管理する事で
一部の問題点は回避可能
• CPUの使用率もなぜか非常に上がってくる
• データサイズやCPU使用率を元にエラー状況の把握ができる
送信に失敗すると、他のログも送信が出来なくなったりする
11

12. 簡単なテスト方法
12

13. 簡単なテスト方法
 confに送信したいデータを「dummy」タイプとして登録するだけ
<source>
@type dummy
dummy {"hello":"world"}
tag tdtail.var.log.td-agent.tdlog.test_db.access.20180101.aaaa
</source>
実データを送信する事なく動作確認がおこなえる！
※永続してログが出力されるので注意が必要
13

14. より効率的に使うために
まだ出来ていないが、今後改善したい部分を・・・
14

15. より効率的に使うために
 1つのサーバ内のFluentdを複数起動させる
 プロセッサ分だけ、 Fluentd起動させて１つのサーバで複数動作させる
 例えば、４コアのサーバーで実行する場合、
接続ポートを分けて4つのfluentdを起動させる
15
Port:aaa Port:bbb
Port:ccc Port:ddd
と思っていたが・・・
V0.14以降はmultiprocess化されているようです
<system>
workers 4
</system>
この設定だけで4コアで動作するようです。

16. より効率的に使うために
 重複しているデータを把握できる情報を付与する
16
サーバーのIP情報、時間を使ったユニークキー等をログ送信時に付与させる
ユーザの情報やログの出力時間等で大枠判断できるが、
ログインボーナスを一括で受け取った際に、同じようなログが同時に出力される可能性がある。
重複と違う同一のログは判断出来るようにしたい。

17. より効率的に使うために
 何故今まで対応を行っていないのか？
17
1. Treasure Dataを使用している場合、30分以内のログは重複を担保してくれる
2. 売上に関連するログの重複の確認が見受けられなかった
データの再入込みや別のビックデータを活用する際に
必須の対応だと認識している

18. おまけ
 EmbulkとFluentdの使い分けについて
18
即時性 確実性 スキーマレス バッチ機能
Fluentd 〇 △ 〇 ×
Embulk △ 〇 × 〇