下記のページを参考にインストールしました。http://help.treasuredata.com/customer/portal/articles/1246904-installing-td-agent-on-rhel-and-centos※以下、x86_64環境を前提として書いています。root権限を持っているユーザーで下記のコマンドを実行し、ファイルを作成します。/etc/yum.repos.d/td.repo次に、お好みのエディタで下記の通りに編集して保存します。td-agentインストール手順は上記のページに書かれている内容に従っています。内部でのログのルーティングプラグインについて触れる前に、タグについて簡単に説明します。内部で、タグと呼ばれる文字列でログのルーティングを行っています。タグの書き換えを行い、いくつかのプラグインを経由していくのが一般的かと思います。基本的なタグの書き換えは下記のような設定になっています。filtered</match>この例では完全一致のみ説明していますが、パターンによるマッチもサポートされています。3ヶ所を参照してください。2つのプラグインを追加でインストールして使用しました。この2つのプラグインを簡単に説明します。使い柔軟なログのルーティングを実現することが出来ます。今回は残念ながら大した使い方をしていないため、詳しくはプラグインのページを参照してください。httpdのmod_rewriteのようなプラグインです。ログ内の項目に対して正規表現によるパターンマッチングを試行し、マッチした場合、またはマッチしなかった場合に、タグの書き換えを行うことで柔軟かつ強力なログのルーティングを実現することが出来ます。フィルタリングの用途にも適しています。https://github.com/fluent/fluent-plugin-rewrite-tag-filterでは、上記のプラグインをインストールします。root権限を持っているユーザーで下記のコマンドを実行します。fluent-plugin-rewrite-tag-filterエラーが何も出なければ、/usr/lib64/fluent/ruby/lib/ruby/gems/1.9.1/gems/にプラグインがインストールされるはずです。配置してインストールする方法もあるようです。pd02)と、1台の待機系(pd04)で構成されています。残りの1台(pd03)は社内向けサービスが動いているため、今回のログ集約の対象からは除外しました。このうち運用系をログ転送元、待機系をログ転送(集約)先としてセットアップしました。起動スクリプトと設定ファイルの構成Paidのサーバー群には、原則として全てのサーバーが全ての役割を果たせるようセットアップしておくというルールがあるため、ログ転送元とログ転送先に同じファイルを配置しておく必要があります。他のサービスへの展開なども含め、色々な試行錯誤を繰り返した結果、下記の構成に落ち着きました。td-agent-paid-web-forwarder-test.conf起動スクリプト■ログ転送元の起動スクリプト/etc/rc.d/init.d/td-agent-paid-web-forwarderサービスへの登録はroot権限を持っているユーザーで下記を実行します。主な改変箇所はスクリプト内の赤字部分です。オプションが含まれていません。$?■ログ転送先の起動スクリプト/etc/rc.d/init.d/td-agent-paid-web-aggregatorサービスへの登録はroot権限を持っているユーザーで下記を実行します。実行環境毎に、上記の3ファイルのうち1つが読み込まれます。test環境用はproductionの部分を置換しただけです。ディレクティブで外部の設定ファイルを読み込むだけの設定です。上記の3ファイルのうち1つが読み込まれます。test環境用はproductionの部分を置換しただけです。ディレクティブで外部の設定ファイルを読み込むだけの設定です。■共通の設定ファイル/etc/td-agent/td-agent-common.conf全体で共通して読み込む設定ファイルです。commonというネーミングにマサカリが飛んできそうですね。gz</match>上から順に解説します。null</match>上記は、out_nullプラグインを使い、"null"というタグを持つログを破棄するための設定です。意図的に破棄したいログに対して使おうとしていましたが、導入時は使いませんでした。内部のログを/var/log/td-agent/fluent.20131118_0.logのような名前のファイルに出力するための設定です。gz</match>上記は、同じくout_fileプラグインを使い、いずれにもマッチしなかったタグを持つログを/var/log/td-agent/unmatched.20131118_0.logのような名前のファイルに出力するための設定です。どれだけ出力されるのかが不明だったため、ローテート時にgzip圧縮し、拡張子に.gzが追加される設定を有効にしています。仕様がちゃんと書かれています。”.log”.■Paidのログファイル弊社が運営するサービスの多くはJavaで開発されています。Tomcat上で動作しています。Railsを使った開発もあります)このため、今回はアプリケーション内で出力しているアクセスログファイルを対象とします。以下、「Paidのログファイル」とは、このアクセスログファイルのことを指します。アクセスログファイルは下記のようなフォーマットになっています。formatは改変しています。forward.${tag}.${hostname}</match>上から順に解説します。コマンドのようにログファイルに追記される度に書き込まれたログ(1行単位)を読み込むための設定です。ログファイルがローテートされても、もちろん追従してくれます。コマンドの実行結果に置き換わります。この設定はログの転送後に、そのログがどのサーバーから転送されてきたのかを残すための準備です。と大して変わらないので省略します。※hostは改変しています。test環境用はproductionの部分、route内のホスト名、hostの部分を置換しただけです。上から順に解説します。チェックがNGであればunmatchedのログファイルに出力されます。ログを転送するリスクを減らそうとする目論見です。接続制限を加えるべきなのでしょうが、現在はそこまでしていません。</secondary></match>上記は、out_forwardプラグインを使い、ログを転送(送信)するための設定です。転送(送信)エラーとなったログをファイルへ書き込んで残したりしています。test環境用はproductionの部分を置換しただけです。上から順に解説します。forward</source>上記は、in_forwardプラグインを使い、ログを転送(受信)するための設定です。</route></match>上記は、転送されてきたログのタグに、実行環境が同一であることを示す文字列が含まれているかチェックしています。チェックがNGであればunmatchedのログファイルに出力されます。gz</match>上記は、out_fileプラグインを使い、ログをファイルへ書き込む設定です。だいたい上の方で説明済みですね。ファイルへは、タイムスタンプ、タグ、JSONの順で、タブ文字区切りで書き込まれます。と大して変わらないので省略します。ノートラブルで動き続けています。DELIVERYへの導入を考えています。