fluentd(td-agent)のインストールと設定

Contents


fluentd / td-agent とは

fluentd とは

fluentdはruby gemによって提供されるログ転送/収集の仕組みです。rsyslogdでは実現できないような大量ログの収集/分析を行う目的で使用すると良いと思います。

td-agent とは

td-agentとはfluentdのラッパープログラムです。ruby, gem等のプログラムや起動スクリプトなどの便利なファイルをインストールコマンドひとつで提供してくれます。td-agentは環境変数PATHには存在しないディレクトリにrubyやgemをインストールしてくれるので、システム全体への影響を与えずにfluentdが使えるメリットがあります。

fluentdのデメリット(弱点)

fluentdは万能ではなく、業務要件によってはクラシックなrsyslogdを使用する方が良い場面も存在します。以下にfluentdの弱点を羅列します。fluentdは大量ログの転送/収集/分析を目的として作られていますので、リアルタイム性や高可用性は苦手とする分野です。

何でもfluentdに任せるのではなく、fluentdの弱点を理解した上でのツール選定が重要です。ログを監査や監視などの目的で使用するならば、fluentdよりも優れたツールはたくさんあります。私が個人的にfluentdの弱点であると感じた事柄を以下に列挙しますので、ツール選びの参考にして頂けると幸いです。

リアルタイム性

fluentdは大量のログを収集する目的で作られています。そのため、ログを一度バッファリングします。バッファに入る分だけログの転送が遅くなりますので、リアルタイムのログ転送を実現したいならばrsyslogdの方が優れています。

例えば、”ログを集約して、そのログを監視する”のような要件の場合は、監視エージェントのログ監視機能やrsyslogdを使用した方が遥かに運用しやすいです。

ログ転送の信頼性

fluentdは大量ログを転送する事を目的に作られていますので、デフォルト設定はメモリ内にログをバッファリングします。つまり、fluentdサーバに障害が発生するとログが失われる事になります。

運用のしずらさ ( Non DevOps )

fluentdには運用者側のニーズはあまり取り込まれていません。DevOpsではなくDevDevツールです。例えば、fluentdが想定していないログがfluentdに流れ込むと大量のスタックトレースがログ出力されます。実際に私は10分間で1Gのログファイルが吐き出される障害を経験しています。

また、fluetnd間のログ送受信はバッファリングされて一定間隔で行なわれますが、この仕様はネットワークエンジニアの立場で言えば、スイッチ機器のキュー溢れを引き起こす迷惑千万な仕様です。

fluentdは私の人生の中で、わりと上位を占めるトラウマ ミドルウェアです。使い方を誤ると運用者泣かせの酷いツールになってしまうので、設計思想に沿ってfluentdを使用する事が大切です。

例外処理の甘さ

現状(2014/08/16)のfluentdは、運用者が求めているような例外処理は発展途上の段階です。実際にソースコードを読むと、例外処理にTODOと書かれているのが散見されます。threadの異常終了はプロセス監視では検知できないので、今のところ何か動作が変だと感じるならば再起動を行なう運用は、あながち間違っているとも言えません。なお、理論上はfluentd debugというツールを使用すれば解析できますが、fluentd debugを用いた障害復旧の運用ができるとは到底思えません。

例外が握りつぶされている例は以下の通りです。

fluentdのメリット(長所)

設定の用意さ

fluentdの設定ファイルは、非常に直観的で簡単に作成する事ができます。rsyslogやnxlogのようなログ転送ソフトウェアもfluentd同様の処理が可能ですが、構文が非常に複雑で学習コストが高いです。

プラグイン作成の用意さ

fluentdは非常に簡単にプラグインを作成する事ができます。基底クラスを継承し、必要なメソッドをオーバーライドするだけで、簡単にfluentdのプラグインを作成する事ができます。

一方、rsyslogやnxlogもプラガブルな構成になっているものの、CやC++を用いてプラグインを開発しなければならないため、fluentdに比べて遥かに高度なスキルを求められます。

モチベーション維持

エンジニアならば誰もが新しい物の方がやる気を出すはずです。COBOLよりもruby, pythonの勉強をしたいのは、誰もが同じ気持ちのはずです。

fluentdは新しく、WEB業界では非常に人気があります。やる気を観察した古典「ピープルウェア」でも同様の事が書かれていますが、新しい物を取り入れる事による従業員のモチベーション向上の効果は計り知れないものがあります。(とは言っても、新しい物に節操なく飛びつくと、思わぬ技術負債となって従業員を苦しめる事はよくありますが・・・。)

fluentdの歩き方

現在(2014/07/27)のfluetnd公式サイトは、”www.fluentd.org/”です。fluentdの情報収集目的でこのサイトに訪れて頂けるのは非常に嬉しいのですが、エンジニアなら公式サイトのような一次情報を収集するのは必須であると考えています。

fluentd公式サイトで一番よく見るのは、ドキュメントに関するコンテンツです。”RESOURCES”, “documentation”の順で押下するとドキュメント一覧ページを閲覧する事ができます。

fluentd_website_001

fluentd 公式サイト – インストール手順

公式サイトのfluentd(td-agent)インストール手順は、”Overview”, “Installation”の順で押下すると調べる事ができます。RPMを使用する方法やChefを使用する方法等の色々な手順が紹介されていますが、ここでは最も簡単なRPMを使用する方法のみを紹介します。

fluentd_website_002

fluentd 公式サイト – プラグイン紹介

fluentdは入出力の動作をプラグインによって、決める事ができます。何か特殊な要件が発生したら追加プラグインを導入する事によって要件を満たせるかもしれません。どうしても必要なプラグインが存在しない場合は、自分で作る事もできます。

fluentdのプラグインは、Input, Buffer, Outputの3種類に分類する事ができます。慣れないうちは公式サイトのプラグインを読むようにし、慣れてくればGitHubを探したり自分でプラグインを開発したりすると良いでしょう。公式サイトで紹介されているプラグインのマニュアルは、サイドバーメニューの”Input Plugins”, “Output Plugins”, “Buffer Plugins”を押下する事で閲覧できます。

fluentd_website_003

td-agent (fluentd) のインストール

td-agent (fluentd) のバージョン

td-angetのインストールを行う前に、td-agentのバージョンを検討する必要があります。今現在(2015年2月)は、td-agent version 1からtd-agent version 2への過渡期です。TRESURE DATAはtd-agent2への移行を促していますが、td-anget2を公式サイトで発表したのは2014年9月のであり、十分に枯れていないソフトウェアです。

ソフトウェアライフサイクルの観点で有利なtd-anget2を使用するか、不具合リスクの観点で有利なtd-angetを使用するのかは、勤務先やプロジェクトの要件に応じて判断すべきかと思います。

td-agent2 のインストール

インターネットに接続可能な環境では、td-agentのインストールは非常に簡単です。インストールスクリプトをダウンロードし、パイプでshellに渡すだけ。たった1行で実行できます。

td-agent (旧バージョン) のインストール

旧バージョンのtd-agentをインストールする場合は、以下のコマンドになります。

td-agent (fluentd)  fluent-cat による簡単な動作確認

あまりにインストールが簡単すぎて本当に動作しているのか不安に思う方もいると思います。ですので、簡単な動作確認を行ってみましょう。

まずは起動スクリプトよりtd-agentを起動されます。

td-agentのデフォルト設定は、debug_agentと呼ばれるInputプラグインがtcp 24230でListenしています。fluent-catと呼ばれるデバッグツールを用いると、debug_agentに対してメッセージを送ることができます。以下の要領で、debug_agentにメッセージを送ります。

td-agentのデフォルト設定は、debug.*というタグ付けされたメッセージを/var/log/td-agent/td-agent.logに出力する仕様になっています。/var/log/td-agent/td-agent.logを表示させ、確かにメッセージがfluentdに届いた事を確認します。

td-agent (fluentd) のバージョンアップ

インストールスクリプトを用いてtd-agentをインストールした場合は、非常に簡単にバージョンアップできます。まずは構成を把握するために、インストールスクリプトを読んでみましょう。すると、単にtresure dataのyumリポジトリを作成し、yum installしているだけである事が分かります。

ですので、td-agentをバージョンアップするには、以下のようなyumコマンドを使用するだけになります。ただし、バージョンアップに伴い各種プラグインの仕様変更の可能性がありますので、もしかしたら/etc/td-agent/td-agent.confの修正が必要になるかもしれません。

td-agent ( fluentd ) の設定

td-agent ( fluentd ) 起動オプションの設定

td-agentはデフォルトでtd-agentユーザで起動されます。td-agentユーザでは、/var/log/messagesなどのsyslogdが出力するファイルを読む事ができないので、td-agentの運用がやや難しくなります。そこで、td-agentをrootユーザで起動させる事をお勧めします。

td-agentの起動スクリプトを読むと/etc/sysconfig/td-agentで起動ユーザを設定できる事が分かります。td-agentをrootユーザ/rootグループで起動する設定例は以下のようになります。

なお、起動オプションとして設定可能な項目一覧は、td-agentに-hオプションを付与する事で確認する事ができます。

td-agent ( fluentd ) 設定ファイルの編集

特に起動オプションで設定ファイルを変更していない場合は、/etc/td-agent/td-agent.confに設定を記述します。

動作確認のため、td-agentの設定ファイルを変更してみましょう。以下は、/var/log/messagesのログを/var/log/td-agent/td-agent.logに転送する設定例です。

td-agentを再起動させ、設定を反映させます。pos_fileパラメータの設定を強く推奨する旨の警告が出ていますが、この警告の意味は後ほど説明します。

/var/log/messagesが/etc/td-agent/td-agent.logへ転送された事を確認します。

Input Plugins

Input Plugingは、fluentdのログ受信処理を司るプログラムです。使用頻度の高いInput Pluginの簡単な動作確認方法について紹介します。

in_tail

in_tailはログを末尾から読み取るプラグインです。syslogやapache access.logのようにファイルに吐き出させるログをfluentdに読み込ませる時に使用するプラグインです。

in_tailを動作確認する最低限の設定は以下の通りです。/etc/td-agent/td-agent.confを以下のように編集します。

td-agent再起動により設定を反映させます。

/tmp/sample.logを読み込むように設定されていますので、/tmp/sample.logに適当なメッセージを書き込みます。

/var/log/td-agent/td-agent.logにログが転送されている事を確認します。

in_http

in_httpはhttp通信によってログを受け取るプラグインです。アプリケーションがログをJSON形式にしてfluentdに対してログを送る仕様になっていますので、アプリケーション開発者がログフォーマットに囚われず処理に応じて柔軟なログ形式を採用する事ができます。

ただし、td-agentのメンテナンスや再起動時にログ転送が止まってしまうリスクがありますので、本当に大事なログはファイル出力しin_tailによってログ転送する事を検討しましょう。

in_httpの動作確認する最低限の設定は以下の通りです。/etc/td-agent/td-agent.confを以下のように編集します。

td-agent再起動により設定を反映させます。

curlコマンドでログを送ります。データ部分にJSON形式でログを記述し、URLヘッダーにタグを記載します。

/var/log/td-agent/td-agent.logにログが転送されている事を確認します。

in_exec

in_execは定期的にコマンドを実行し、その標準出力をfluentdに送るプラグインです。

in_execの動作確認する最低限の設定は以下の通りです。/etc/td-agent/td-agent.confを以下のように編集します。なお、以下の設定は再起動後に1回のみコマンドが実行される設定例です。定期的にコマンドを実行したい場合は、run_intervalパラメタを指定して下さい。

td-agent再起動により設定を反映させます。

/var/log/td-agent/td-agent.logにログが転送されている事を確認します。

in_syslog

in_syslogはsyslogメッセージをfluentdに送るプラグインです。

in_syslogの動作確認する最低限の設定は以下の通りです。/etc/td-agent/td-agent.confを以下のように編集します。

td-agent再起動により設定を反映させます。

/etc/rsyslog.confを以下のように編集し、syslogをfluentdに転送するように設定します。

rsyslogdを再起動し、設定を反映させます。

/var/log/td-agent/td-agent.logにsyslogが転送されている事を確認します。

in_forward

in_forwardはmessage packによってログを受信するプラグインです。ログを送信するout_forwardとセットで使用プラグインですので、後述のout_forwardと一緒に動作確認を行います。

Output Plugins

Output Plugingは、fluentdのログ送信処理を司るプログラムです。使用頻度の高いOutput Pluginの簡単な動作確認方法について紹介します。

なお、Output Pluginは、ログを出力するタイミングによって、Non-Buffered, Bufferd, Time Slicedの3種類に分類する事ができます。fluentd 公式ドキュメントを引用ですが、3種類の違いは以下の表と図のように説明されています。

Output Pluginの分類説明
Non-Bufferedデータをバッファリングすることなく、即座に結果を書き出します。
Bufferedチャンク(チャンクはイベントの集合です)のキューを維持し、その振る舞いは「chunk limit」および 「queue limit」パラメータによって調整することができます(下の図を参照)。
Time Sliced事実上、Bufferredプラグインですが、チャンクは時間によってキーにされます(下の図を参照)。

fluentd_output_plugin_type

out_stdout (Non-Buffered)

out_stdoutはログを標準出力またはログファイルに書き出すプラグインです。デフォルト設定の場合は、/var/log/td-agent/td-agent.logにログが出力されます。他のプラグインと違ってNon-Bufferedであるため、”すぐに”ログが出力されます。そのため、fluentd設定ののデバッグをする際には非常に便利なプラグインです。

out_stdoutの動作確認を行うため、/etc/td-agent/td-agent.confを以下のように編集します。

td-agent再起動により設定を反映させます。

/var/log/td-agent/td-agent.logにログが転送されている事を確認します。

out_file (Time Sliced)

out_fileはログをファイルに書き出すプラグインです。Time Slicedのプラグインですので、Time Slicedの時間が経過するまでログファイルが生成されない事に注意して下さい。

out_fileの動作確認を行うため、/etc/td-agent/td-agent.confを以下のように編集します。デフォルト設定は、日時で0時10分にログファイルが生成されますが、デフォルト設定では動作確認に非常に時間がかかるので、毎分でログファイルを生成するようにtime_slice_format, time_slice_waitを定義しております。

なお、root権限でtd-agentを起動している場合はディレクトリ作成の必要はございません。out_fileプラグイン内でディレクトリを生成する処理が記述されています。

td-agent再起動により設定を反映させます。

ログが生成されるディレクトリを閲覧します。td-agent再起動後、30秒程度待つと以下のようなファイルが生成されている事が確認できます。この時刻と乱数によって生成されたファイルは、fluentdがバッファしているログです。バッファされたログはtime_slice_formatで指定した時刻からtime_slice_wait経過後にログファイルに出力されます。

しばらく待つと、ログファイルが毎分生成されている事が確認できます。

out_forward (Buffered)

out_forwardはログをMessagePackによって他サーバへ転送するプラグインです。私個人の意見ですが、out_forwardは信頼性と省リソースの天秤、スケールアウト戦略、データフロー等のやり甲斐のある設計ができる最も面白いプラグインであると思います。

このページでは、out_forwardを最も簡単に動作確認できる設定例を紹介します。ログを送信する側の/etc/td-agent/td-agent.confを以下のように編集して下さい。

ログを受信する側の/etc/td-agent/td-agent.confを以下のように編集します。

td-agent再起動により設定を反映させます。

out_forwardプラグインは、ログ転送にTCPを使用し、ハートビートにUDPを使用します。TCP24224, UDP24224の両方を口開けして下さい。iptablesの設定例は以下のようになります。

out_forwardに格納されたログは一度バッファリングされます。デフォルト設定はメモリにバッファリングされますが、今回はでは動作確認しやすいようにファイルにバッファしております。バッファが作成されるディレクトリをlsで観察すると、バッファリングされたログを確認する事ができます。

ログを受信する側の/var/log/td-agent/td-agent.logを表示させ、確かにログが転送されている事を確認します。

ログフォーマット

fluentdはJSON形式のデータ転送を行い、最終的にはデータ分析につなげる事を目的としております。しかし、/var/log/messagesや/var/log/httpd/access.logのようなログファイルはJSON形式にはなっていません。

fluentdは、in_tailやin_execなどのInputプラグインでログを読み込む際にJSON形式に変換する事ができます。

ログフォーマット – 正規表現

in_tailプラグインは以下のようにformatパラメタに正規表現を与える事によって、ログをJSON形式に変換する事ができます。また、JSONにtimeというkeyを含む場合は、time_formatで指定した時刻形式に従ってログを時刻順に並び替える機能が存在します。

よく使用するログファイルについては、format指定についてaliasが定義されています。例えば、/var/log/messagesに対するformat指定は以下のように”format syslog”と表記する事もできます。

format指定として使用可能なaliasはfluentd公式ドキュメントを参照しても良いですが、挙動がどうも怪しいと感じた時はソースコードを追ってみましょう。指定可能なaliasは/usr/lib64/fluent/ruby/lib/ruby/gems/1.9.1/gems/fluentd-0.10.50/lib/fluent/parser.rbに記載されています。

それでは、実際にformat指定によるJSON化の動作確認を行ってみましょう。設定例は以下の通りです。なお、以下の設定例が機能するのは、apacheのログフォーマットがデフォルト設定の場合のみです。ログフォーマットを変更している場合は、正規表現を適宜変更する必要があります。

td-agent再起動により設定を反映させます。

/var/log/td-agent/td-agent.logを表示させ、ログがJSON形式に変換された事を確認します。

ログフォーマット – ログ正規化の見送り ( none )

ログ出力形式の仕様を決められない事もあるかもしれません。また、ログの形式を定める前に、とりあえずログを蓄積したいというニーズがあるかもしれません。

そのような場合は、format noneと指定する事によって、とりあえずのログ収集を行なう事ができます。また、/var/log/httpd/error_logのように、PHP等のデバッグログが出力されるような、いつも決まりきったフォーマットではないログを収集する際は、none指定は非常に有効な手段です。

“format none”の設定例は以下の通りです。/etc/td-agent/td-agent.confを以下のように編集します。

td-agent再起動により設定を反映させます。

/var/log/td-agent/td-agent.logを表示させます。”message”というkeyに対するvalueとしてログメッセージが格納されている事が確認できます。

ログフォーマット – tsv, csv, ltsv

ログを予めtsv, scv, ltsvのような形式で出力する事によって、容易にJSON形式に変換する事ができます。最も扱いやすくお勧めなのは、コロンとタブで区切ったltsvと呼ばれる形式です。

ltsvを使用するには、予めアプリケーションやミドルウェア側のログ出力をLTSV形式にする必要があります。例えば、nginxの場合ならば以下のような設定になります。

apacheならば、以下のような設定になります。

LTSVに対応したtd-agent.confの設定は以下のようになります。LTSVの中にtimeというフィールドが含まれる場合は、time_formatの設定が必要になる事に注意して下さい。

td-agent再起動により設定を反映させます。

/var/log/td-agent/td-agent.logを表示させ、ログがJSON形式に変換された事を確認します。

fluentd (td-agent) の 監視

プロセス監視 ポート監視

監視の定番、プロセス監視とポート監視の方法について説明します。

td-agentのプロセスは以下のように2つ立ち上がります。片方が親プロセスでもう一方が子プロセスです。”/usr/sbin/td-agent”というプロセスが2つ存在する事を確認すると良いでしょう。

ポート監視は、どのようなInput Pluginを使用するかによって監視するポートが異なります。多くの場合は、in_httpが使用するTCP8888か、in_forwardが使用するTCP24224を利用すると良いでしょう。もし、監視可能なポートが存在しないならば、監視用途のため、Input Pluginを追加しても良いかもしれません。

バッファ溢れ (buffer_queue_limit, buffer_chunk_limit)

fluentdはログ溢れしないようバッファリングという機能を備えています。いくらツール側が気を効かせた実装を行なったとしても、適切なバッファ設定とバッファ監視がなされていなければ意味がありません。

どの程度のログがバッファされているか調査するには、monitor_agentと呼ばれるInput Pluginを利用します。この監視用のプラグインを使用するには、/etc/td-agent/td-agent.confに以下を加筆して下さい。

monitor_agentは監視結果をJSON形式で返します。運用担当者がターミナルソフト越しで、JSONを目視で読み取るのは、なかなか辛いものがあります。そこでお勧めなのが、jqというコマンドラインJSONパーサーです。以下のようにyumコマンドでjqをインストールします。

”http://127.0.0.1:24220/api/plugins.json”にHTTPリクエストを送ると、 buffer_total_queued_size, buffer_queue_lengthを調査する事ができます。この値を統合監視ツール経由で取得するようにすれば、バッファ溢れを事前に検知する事ができます。

ログ監視 ( ログ暴走監視 )

fluentd ( td-agent )は何らかのエラーが発生すると、大量のログを出力する残念なツールです。fluentdの構造自体が特定の処理をループで回すような構造になっているため、今度の改善は期待できず運用でカバーせざるを得ない問題です。

私が経験したヒアリハット事例は、10分間で1G以上のログを吐き出す状態になってしまいました。このような状態になってしまうと、ディスク容量監視では検知できない事もあるかもしれません。

また、何らかの想定外のエラーを検出する意味でも、/var/log/td-agent/td-agent.logの”[error]”という文字列を監視すると良いでしょう。ちなみに、エラーが大量に出力されているログ出力の例は以下の通りです。

thread 異常終了

“thread 異常終了”、レアケースですが、これがfluentdを運用していた際の最大の悩みでした。fluentdは特定のthreadが異常終了してしまう事があります。これが起きてしまうと、プロセス監視では正常に見えても、なぜかログが転送されない自体になってしまいます。

実際に経験した障害事例ですが、プロセス監視は正常でもin_http経由で入力されたログのみがロストするという事例に遭遇しました。

thread 異常終了に対する防御策は、今のところ良いアイディアがありません。

  • 監視用のログを定期的に送信して、ログが想定通りに転送されている事を確認する。
  • thread 異常終了時のログ出力を監視するようにする。

のような思いつきレベルの防御策ならば語る事ができますが、正直、運用として回るかどうかは不明です。

Tips

td-agent.conf 構文チェック

td-agentに引数–dry-runオプションを渡すか、起動スクリプトに引数configtestを渡す事によって、td-agent.confの構文チェックを行う事ができます。td-agent.conf設定反映のための再起動を行う前に、一度構文チェックを行う癖をつけておくと良いでしょう。

td-agent2

fluentd (td-agent) はruby, gemのライブラリのひとつとして提供されています。という事は、残念ながら、かなり早い頻度でruby, gemバージョンアップ対応に迫られるでしょう。td-agentの1回目のバージョンアップ対応がtd-agent2です。td-agent2はtd-agentのruby, gemなどのバージョンアップを図ったパッケージです。具体的なバージョンの違いは以下の表を参照下さい。

 td-agent-1.1.20td-agent2-1.0.0
ruby1.9.3p4842.1.2p95
gem1.8.232.2.2

td-agent2は2014/05/19にリリースされた未だ枯れていないバージョンです。td-agent2を本番環境に入れるには、人柱になる覚悟が必要でしょう。

よく見かける エラーメッセージ

argument out of range

/var/log/td-agent/td-agent.logのエラーメッセージとして、error=”argument out of range”が出力される事があります。これは”time_format”の指定漏れが原因の事が多いです。

fluentdのログフォーマット機能は、”time”というkeyがある場合は、time_formatの形式に従って時刻をパースし時刻順にログを並び替える機能があります。もし、time_formatの指定がない場合は、以下のようなエラーメッセージが出力され、ログ転送が行われなくなります。

/etc/td-agent/td-agent.conf の修正例は以下の通りです。

no nodes are available

“no nodes are available”はログ転送先のホストが全てダウンしている事を表すログです。運用フェーズに入っている場合はログ集約サーバ側の障害を疑うべきですが、初期構築段階でこのログが見られるのはログ転送を行なうサーバ間の疎通不能をあらわす事が多いです。

fluentdはログ転送としてTCP 24224を使用し、ハートビートとしてUDP 24224を使用する事に注意が必要です。よくあるパターンがUDP 24224の開放漏れです。

実際に”no nodes are available”が出力される例は以下のようになります。

no patterns matched tag

/var/log/td-agent/td-agent.logにno patterns matched tagが出力される事があります。これはOutput Pluginで指定したタグにマッチせずに破棄されてしまったログが存在する事を意味します。

例えば、/etc/td-agent/td-agent.confで<match **>と書くべきところを<match *>と書いてしまうと、/var/log/td-agent/td-agent.logにno patterns matched tagと出力されてしまいます。

‘pos_file PATH’ parameter is not set to a ‘tail’ source

td-agent再起動時に’pos_file PATH’ parameter is not set to a ‘tail’ source. this parameter is highly recommended to save the position to resume tailing.と表示される事があります。文字通り、in_tailプラグインはpos_fileパラメタは強く推奨されています。このパラメタが存在しないと、td-agent再起動時にログが2重で読み込まれてしまう等の不都合が生じてしまいます。

/etc/td-agent/td-agent.conf の修正例は以下の通りです。

Fluent::BufferQueueLimitError: queue size exceeds limit

Fluent::BufferQueueLimitError: queue size exceeds limitは、out_forwardプラグインを使用する過程でbuffer_queue_limitで指定したキューから溢れてしまった事を意味します。

一度キュー溢れが発生すると、単にログロストにつながるだけでなく、ログ転送そのものが止まってしまうので、一度td-agentを再起動する事をお勧めします。

Size of the emitted data exceeds buffer_chunk_limit.

Size of the emitted data exceeds buffer_chunk_limit.は、out_forwardプラグインを使用する過程でbuffer_chunk_limitで指定したchunkから溢れてしまった事を意味します。

/etc/td-agent/td-agent.confを編集し、buffer_chunk_limitを大き目の値に設定します。設定例は以下の通りです。

LTSVの取り扱い方法

LTSVはapacheやnginxのデフォルトのフォーマットと異なりますが、LTSVは慣れると非常に便利です。

apacheのデフォルト設定では区切り文字列が空白になっているため、awkで抽出される際に想定外の場所で区切られる事がよくあります。しかし、LTSVはタブ区切りになっているため、デフォルト設定に比べれば想定外の区切られ方になる事は少ないです。

例えば、ユーザーエージェントの抽出ならば、以下のように行います。デフォルト設定のaccess_logに比べて、遥かに簡単にawkする事ができます。

ユーザエージェント上位5件などの集計作業もこんなに簡単です。

さらに、LTSV専用のパーサーを使用すれば、もっと容易に集計する事ができます。以下は、ltsviewというruby gemによって提供されるLTSVパーサーの出力例です。

LTSVパーサーは、いろいろあります。恐らく全てのLTSVパーサーが長い期間メンテナンスされる事はないでしょう。つまり、LTSVパーサーを使って集計の運用を回すという事はメンテナンス終了のリスクを十分に考慮する必要があります

もし、メンテナンス終了のリスクを嫌うのならば、枯れた言語のワンライナーで集計を書けるという手法もあります。DQNEO起業日記 LTSVログをパースする最強のワンライナー集では、以下のようなperlによるワンライナーの実装例が紹介されています。このようにperlを使用すれば、rubyバージョンアップ・OSバージョンアップの度にガクガクブルブルしないで済むでしょう。

動作確認環境

Linuxにおける動作確認環境は以下の通りです。

  • 最終動作確認日 : 2014/01/19
  • CentOS 6.6 ( Sakura VPS ), Redhat 6.5 ( AWS : Amazon Web Service )
  • td-agent-1.1.21-0.x86_64

シェアする

  • このエントリーをはてなブックマークに追加

フォローする