Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Fluentdで注意するべきところ

25 views

Published on

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

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Fluentdで注意するべきところ

  1. 1. fluentdで注意するべきところ 望月 大作 1
  2. 2. アジェンダ 1. 自己紹介 2. fluentdとは? 3. 使う上での注意点 4. 簡単なテスト方法 5. より効率的に使うために 2
  3. 3. 自己紹介  所属: ガンホー・オンライン・エンターテイメント株式会社  名前: 望月 大作  職種: 肩書はエンジニアですが、分析チームの管理をしてます  業務: 各タイトルのログ集計、グラフ作成、分析、ツール作成  関連しているタイトル: クロノマギア、サモンズボード、ディバインゲート零 ケリ姫スイーツ、セブンスリバース・・・等  趣味: ゲーム、サイクリング、ボードゲーム、剣道、フットサル 3
  4. 4. fluentdとは? 4
  5. 5. fluentdとは? Rubyで動いているオープンソースの データコレクターやデータログ収集ツールと呼ばれるソフトウェア ・メリット ほぼリアルタイムにデータを送信できる(ストリーミング送信) スキーマを考える必要がない ・デメリット データの担保が行えない 送信されているのか判断しにくい 5
  6. 6. fluentdとは? 何故使用するのか?  ログファイルを別の場所に蓄積させる  そのままサーバ上に保存をしているとHDDが溢れてしまい、動かなくなる  出来るなら即座に調査をしたい  不具合が発生した場合にできる限り直前のログを追いたい (緊急メンテや補填の処理はできる限り迅速にしたいので・・・ ) 6
  7. 7. 使う上での注意点 7
  8. 8. 使う上での注意点①  Rubyのバージョンに依存している fluentdを普通に入れるとサーバ内のRubyのバージョン依存が面倒 • td-agentをインストールすると簡単 • curl -L http://toolbelt.treasuredata.com/sh/install-redhat-td-agent2.sh | sh 最新版はこれでインストール可能 8
  9. 9. 使う上での注意点②  データが消えてしまう 何故データが消えてしまう可能性があるのか? • データの送信が失敗している • require_ack_responseを必ず入れる事により、必ず1度はログ送信がされる • CPUの使用率が100%になっている • fluentdは基本的にはシングルスレッドでの動作 • 設定ファイルの設定やログの送信量によりCPUが100%に張り付くと ログを送信できずにロストしてしまう 9
  10. 10. 使う上での注意点③  データを多重に送信してしまう require_ack_responseの設定の為に起こる現象 • 多重送信されるものとして扱う以外対処が難しい • 私もまだこの部分の完全な解決は行えていない • サーバのIPとユニークキーをログに追加させ、 ユニーク化をさせて判断させる事を検討中 10
  11. 11. 使う上での注意点④  エラーが発生すると、送信処理が詰まってしまう • 書込み権限が無くエラーが発生して、その後の処理が止まっている • 本番とテスト環境でtd-agentを分けて管理する事で 一部の問題点は回避可能 • CPUの使用率もなぜか非常に上がってくる • データサイズやCPU使用率を元にエラー状況の把握ができる 送信に失敗すると、他のログも送信が出来なくなったりする 11
  12. 12. 簡単なテスト方法 12
  13. 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. より効率的に使うために まだ出来ていないが、今後改善したい部分を・・・ 14
  15. 15. より効率的に使うために  1つのサーバ内のFluentdを複数起動させる  プロセッサ分だけ、 Fluentd起動させて1つのサーバで複数動作させる  例えば、4コアのサーバーで実行する場合、 接続ポートを分けて4つのfluentdを起動させる 15 Port:aaa Port:bbb Port:ccc Port:ddd と思っていたが・・・ V0.14以降はmultiprocess化されているようです <system> workers 4 </system> この設定だけで4コアで動作するようです。
  16. 16. より効率的に使うために  重複しているデータを把握できる情報を付与する 16 サーバーのIP情報、時間を使ったユニークキー等をログ送信時に付与させる ユーザの情報やログの出力時間等で大枠判断できるが、 ログインボーナスを一括で受け取った際に、同じようなログが同時に出力される可能性がある。 重複と違う同一のログは判断出来るようにしたい。
  17. 17. より効率的に使うために  何故今まで対応を行っていないのか? 17 1. Treasure Dataを使用している場合、30分以内のログは重複を担保してくれる 2. 売上に関連するログの重複の確認が見受けられなかった データの再入込みや別のビックデータを活用する際に 必須の対応だと認識している
  18. 18. おまけ  EmbulkとFluentdの使い分けについて 18 即時性 確実性 スキーマレス バッチ機能 Fluentd 〇 △ 〇 × Embulk △ 〇 × 〇

×