RACCOON TECH BLOG

株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。

一緒にラクーンのサービスを作りませんか？
採用情報 カジュアル面談

カテゴリ一覧

fluentd(td-agent) の導入

はじめまして。開発チームの yuzuki です。

7/1に弊社の 決済サービスPaid（ペイド） のサーバー群へ
ログ集約の改善を目的として導入した fluentd(td-agent) の導入手順などをまとめてみました。

ログ集約を改善する動機

弊社ではこれまで（今も大部分は） cron + rsync を使い、週次バッチでWebサーバー上のログファイルをファイルサーバーへ転送することで一応の集約をさせてきました。
（集約というよりはバックアップといった意味合いの方が強いかもしれません）
サーバー台数が少なかった頃はこの仕組みでも特に大きな問題はなかったと思いますが、
サービスの成長にあわせて、サーバー台数が増え、リリース時に運用系と待機系を相互に切り替える運用へ変わったことで、
ログファイルから問合せや障害などの調査を行う際に、まずログファイルを取得することに手間が掛かる状況になっていました。

下記は弊社のもう1つのサービス ファッション・雑貨向けB2Bサイトスーパーデリバリー
（以下 SUPER DELIVERY）のサーバー構成です。

sd-network

当日分のログファイルについては、まず1系と2系のどちらが運用系なのかを調べてから、
片系で4台あるサーバー全てからログファイルをscp/sftpでせっせと取得し調査していました。

過去分のログファイルについては、各サーバーでローテーションされ週次バッチでの集約を待つ状態と、
週次バッチで各サーバーからファイルサーバーへ集約された状態の2つの状態があります。
※この集約は1台のサーバーに集まるというだけで、1ファイルにまとまるわけではありません。

過去分は、運用系／待機系の切り替えも考慮すると、両方のログを調査対象とするのが確実であるため

といった手間が調査の度に発生していました。

「ここ、何とかならないかな？」と、ずっと思っていたところに現れたのが fluentd です。
fluentd を各サーバーへインストールして、ログの転送を任せてしまえば
1日のログを1台のファイルサーバーの1つのファイルにまとめることが出来てしまいます。

余談：
SUPER DELIVERYが動機になっているのに、なぜPaidへの導入記事なのかというと、
先に導入のコンセンサスが取れたのがPaidだったから、というだけの理由です。
もうPaidで実績ができましたし、SUPER DELIVERYへの導入ハードルも下がったように思います。

fluentd(td-agent) とは？

"Fluentd" is an open-source tool to collect events and logs.
http://fluentd.org/

fluentd は、ほぼリアルタイムでログの読み込み、加工、転送、さらには書き込みまでも行ってくれる非常に素晴らしい Ruby ベースのミドルウェアです。
ログ以外にも、メッセージと表現されることもあります。
※cron + rsync と異なり、扱えるのはログファイルだけではありません！

fluentd はプラグインを書くことで拡張も可能で、既に多くのプラグインが開発・公開されています。
http://fluentd.org/plugin/

fluentd は標準プラグインがバンドルされた Ruby の gem です。
http://rubygems.org/gems/fluentd

td-agent は fluentd 専用の Ruby や jemalloc などがバンドルされ、
安定感のある fluentd の配布パッケージ（rpm, deb など）です。
http://docs.treasuredata.com/articles/td-agent

導入対象のシステムには Ruby 1.9.3 が入っていたこともあり、
既存機能への干渉を避けるため、td-agent を選びました。

td-agent のインストール

執筆時点の弊社では CentOS 5.x on x86_64 が主流なので、
下記のページを参考にインストールしました。
http://help.treasuredata.com/customer/portal/articles/1246904-installing-td-agent-on-rhel-and-centos
※以下、x86_64環境を前提として書いています。

まずはroot権限を持っているユーザーで下記のコマンドを実行し、ファイルを作成します。

# touch /etc/yum.repos.d/td.repo

次に、お好みのエディタで下記の通りに編集して保存します。

[treasuredata]
name=TreasureData
baseurl=http://packages.treasure-data.com/redhat/$basearch
gpgcheck=0

最後に下記のコマンドを実行し、td-agent をインストールします。

# yum install td-agent

インストール手順は上記のページに書かれている内容に従っています。

td-agent のファイル配置場所など

■td-agent の起動スクリプト

/etc/rc.d/init.d/td-agent

■td-agent の設定ファイル テンプレート

/etc/td-agent/td-agent.conf.tmpl

■
td-agent にバンドルされた Ruby のインストール先

/usr/lib64/fluent/ruby/

■
td-agent のログ出力先

/var/log/td-agent/

■
td-agent の.pid出力先

/var/run/td-agent/

fluentd 内部でのログのルーティング

プラグインについて触れる前に、タグについて簡単に説明します。

現在の fluentd v10 は内部で、タグと呼ばれる文字列でログのルーティングを行っています。
タグはピリオードで区切られた文字列で、プラグインで処理を行う度に remove_tag_prefix, add_tag_prefix などでタグの書き換えを行い、
いくつかのプラグインを経由していくのが一般的かと思います。

基本的なタグの書き換えは下記のような設定になっています。

#ログ読み込み時のタグは raw.apache.access
<source>
  type tail  #標準のin_tailプラグイン
  tag raw.apache.access
  ...
</source>
#タグが filtered.apache.access と完全一致する場合、ログをファイルに出力
#※本来は一番下に書くべき設定ですが、この位置に書いても動作することの説明のため
#　あえてここに書いています
<match filtered.apache.access>
  type file  #標準のout_fileプラグイン
  ...
</match>
#タグが raw.apache.access と完全一致する場合、先頭の raw を除去し apache.access とする
#そして新しいタグ apache.access で先頭からタグのルーティングをやり直す
<match raw.apache.access>
  type my_remove_tag_prefix_filter  #このようなプラグインは存在しません
  remove_tag_prefix raw
</match>
#タグが apache.access と完全一致する場合、先頭に filtered を追加し filtered.apache.access とする
#そして新しいタグ filtered.apache.access で先頭からタグのルーティングをやり直す
<match apache.access>
  type my_add_tag_prefix_filter     #このようなプラグインは存在しません
  add_tag_prefix filtered
</match>

この例では完全一致のみ説明していますが、パターンによるマッチもサポートされています。
詳しくは下記のページにある 「*」 「**」 「{X,Y,Z}」 の3ヶ所を参照してください。
http://docs.fluentd.org/articles/config-file#2-ldquomatchrdquo-tell-fluentd-what-to-do

なお、次のメジャーバージョンである fluentd v11 ではラベルになるとか・・・？

fluentd プラグインのインストール

今回は fluent-plugin-route と fluent-plugin-rewrite-tag-filter の2つのプラグインを追加でインストールして使用しました。
この2つのプラグインを簡単に説明します。

fluent-plugin-route は、上記で説明した remove_tag_prefix, add_tag_prefix を使い
柔軟なログのルーティングを実現することが出来ます。
今回は残念ながら大した使い方をしていないため、詳しくはプラグインのページを参照してください。
https://github.com/tagomoris/fluent-plugin-route

fluent-plugin-rewrite-tag-filter は、apache httpdのmod_rewriteのようなプラグインです。
ログ内の項目に対して正規表現によるパターンマッチングを試行し、
マッチした場合、またはマッチしなかった場合に、タグの書き換えを行うことで
柔軟かつ強力なログのルーティングを実現することが出来ます。
なお、フィルタリングの用途にも適しています。
https://github.com/fluent/fluent-plugin-rewrite-tag-filter

では、上記のプラグインをインストールします。
root権限を持っているユーザーで下記のコマンドを実行します。
（※gemに関する環境変数などは設定していません）

# /usr/lib64/fluent/ruby/bin/gem install fluent-plugin-route
# /usr/lib64/fluent/ruby/bin/gem install fluent-plugin-rewrite-tag-filter

エラーが何も出なければ、

/usr/lib64/fluent/ruby/lib/ruby/gems/1.9.1/gems/

にプラグインがインストールされるはずです。
（バンドルされる Ruby のバージョンが上がれば、パスの1.9.1の部分も変わるでしょう）

導入時は /usr/lib64/fluent/ruby/bin/gem を使いましたが、
他にも /usr/lib64/fluent/ruby/bin/fluent-gem を使う方法や、
gem を /etc/td-agent/plugin/ へ配置してインストールする方法もあるようです。

サーバーの構成

Paidのユーザー向けサービスが動いているWebサーバーは2台の運用系（pd01, pd02）と、
1台の待機系（pd04）で構成されています。
残りの1台（pd03）は社内向けサービスが動いているため、今回のログ集約の対象からは除外しました。

このうち運用系をログ転送元、待機系をログ転送（集約）先としてセットアップしました。
（残念ながら、この時点ではまだログ転送先がSPOFです・・・）

paid-network

■ログ集約の構成変更前
ログ集約・変更前

■ログ集約の構成変更後
ログ集約・変更後

起動スクリプトと設定ファイルの構成

Paidのサーバー群には、原則として全てのサーバーが全ての役割を果たせるようセットアップしておくというルールがあるため、ログ転送元とログ転送先に同じファイルを配置しておく必要があります。
他のサービスへの展開なども含め、色々な試行錯誤を繰り返した結果、下記の構成に落ち着きました。
（production環境以外に、staging環境と、test環境用の設定ファイルも作成しました）

■
起動スクリプト

/etc/rc.d/init.d/
├ td-agent-paid-web-aggregator
└ td-agent-paid-web-forwarder

■
設定ファイル

/etc/td-agent/
├ config.d/
│ └ paid/
│    ├ forward/
│    │ ├ production/
│    │ │ ├ aggregate.conf
│    │ │ └ forward.conf
│    │ ├ staging/
│    │ │ ├ aggregate.conf
│    │ │ └ forward.conf
│    │ └ test/
│    │    ├ aggregate.conf
│    │    └ forward.conf
│    ├ input/
│    │ ├ java-pd.conf
│    │ └ java-pd-web-service.conf
│    └ output/
│       ├ java-pd.conf
│       └ java-pd-web-service.conf
├ td-agent-common.conf
├ td-agent-paid-web-aggregator-production.conf
├ td-agent-paid-web-aggregator-staging.conf
├ td-agent-paid-web-aggregator-test.conf
├ td-agent-paid-web-forwarder-production.conf
├ td-agent-paid-web-forwarder-staging.conf
└ td-agent-paid-web-forwarder-test.conf

起動スクリプト

■
ログ転送元の起動スクリプト

/etc/rc.d/init.d/td-agent-paid-web-forwarder

サービスへの登録はroot権限を持っているユーザーで下記を実行します。

# chkconfig --add td-agent-paid-web-forwarder
# chkconfig --level 345 td-agent-paid-web-forwarder on

起動スクリプトは、実行環境毎に読み込む設定ファイルを変えたかったため、
/etc/rc.d/init.d/td-agent を少々改変しています。主な改変箇所はスクリプト内の赤字部分です。

※fluentd の新しいバージョンでは、configtest オプションが実装されていますが、
　導入時のバージョンは td-agent 1.1.14(fluentd 0.10.35) であったため
　ここに書いてある起動スクリプトには configtest オプションが含まれていません。

■■
ログ転送元の起動スクリプトの内容

#!/bin/bash
#
# /etc/rc.d/init.d/td-agent-paid-web-forwarder
#
# chkconfig: - 80 20
# description: td-agent
# processname: td-agent-paid-web-forwarder
# pidfile: /var/run/td-agent/td-agent-paid-web-forwarder.pid
#
### BEGIN INIT INFO
# Provides:          td-agent
# Default-Stop:      0 1 6
# Required-Start:    $local_fs
# Required-Stop:     $local_fs
# Short-Description: td-agent's init script
# Description:       td-agent is a data collector
### END INIT INFO
# Source function library.
. /etc/init.d/functions
name="td-agent-paid-web-forwarder"
prog=$name
hostname=`hostname -s`
if [[ $hostname =~ ^pd[0-9]{2}$ ]]; then
    mode=production
elif [[ $hostname =~ ^stg\-pd[0-9]{2}$ ]]; then
    mode=staging
else
    mode=test
fi
fluentd=/usr/lib/fluent/ruby/bin/fluentd
if [ -f "/usr/lib64/fluent/ruby/bin/fluentd" ]; then
    fluentd=/usr/lib64/fluent/ruby/bin/fluentd
fi
if [ -f /etc/sysconfig/$prog ]; then
    . /etc/sysconfig/$prog
fi
RUN_USER=td-agent
RUN_GROUP=td-agent
PIDFILE=/var/run/td-agent/$prog.pid
CONF_FILE=/etc/td-agent/$prog-$mode.conf
LOG_FILE=/var/log/td-agent/$prog.log
FLUENTD_ARGS="--group $RUN_GROUP -d $PIDFILE -c $CONF_FILE -o $LOG_FILE -q"
if [ -n "${PIDFILE}" ]; then
    mkdir -p $(dirname ${PIDFILE})
    chown -R $RUN_USER:$RUN_GROUP $(dirname ${PIDFILE})
fi
# use jemalloc to avoid fragmentation
if [ -f "/usr/lib/fluent/jemalloc/lib/libjemalloc.so" ]; then
    export LD_PRELOAD=/usr/lib/fluent/jemalloc/lib/libjemalloc.so
fi
if [ -f "/usr/lib64/fluent/jemalloc/lib/libjemalloc.so" ]; then
    export LD_PRELOAD=/usr/lib64/fluent/jemalloc/lib/libjemalloc.so
fi
RETVAL=0
start() {
    echo -n "Starting $name[$mode]: "
    daemon --pidfile=$PIDFILE --user=$RUN_USER $fluentd "$FLUENTD_ARGS"
    RETVAL=$?
    echo
    [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$prog
    return $RETVAL
}
stop() {
    echo -n "Shutting down $name[$mode]: "
    if [ -e "${PIDFILE}" ]; then
        killproc -p ${PIDFILE} || killproc $prog
    else
        killproc $prog
    fi
    RETVAL=$?
    echo
    [ $RETVAL -eq 0 ] && rm -f $PIDFILE && rm -f /var/lock/subsys/$prog
    return $RETVAL
}
restart() {
    stop
    start
}
reload() {
    echo -n "Reloading $name[$mode]: "
    killproc -p $PIDFILE $prog -HUP
    echo
}
case "$1" in
    start)
        start
        ;;
    stop)
        stop
        ;;
    restart)
        restart
        ;;
    reload)
        reload
        ;;
    condrestart)
        [ -f /var/lock/subsys/$prog ] && restart || :
        ;;
    status)
        status -p $PIDFILE $prog
        ;;
    *)
        echo "Usage: $prog {start|stop|reload|restart|condrestart|status}"
        exit 1
        ;;
esac
exit $?

■ログ転送先の起動スクリプト

/etc/rc.d/init.d/td-agent-paid-web-aggregator

サービスへの登録はroot権限を持っているユーザーで下記を実行します。

# chkconfig --add td-agent-paid-web-aggregator
# chkconfig --level 345 td-agent-paid-web-aggregator on

■■ログ転送先の起動スクリプトの内容
　　　forwarder を aggregator へ置換しただけです。

#!/bin/bash
#
# /etc/rc.d/init.d/td-agent-paid-web-aggregator
#
# chkconfig: - 80 20
# description: td-agent
# processname: td-agent-paid-web-aggregator
# pidfile: /var/run/td-agent/td-agent-paid-web-aggregator.pid
#
### BEGIN INIT INFO
# Provides:          td-agent
# Default-Stop:      0 1 6
# Required-Start:    $local_fs
# Required-Stop:     $local_fs
# Short-Description: td-agent's init script
# Description:       td-agent is a data collector
### END INIT INFO
# Source function library.
. /etc/init.d/functions
name="td-agent-paid-web-aggregator"
prog=$name
hostname=`hostname -s`
if [[ $hostname =~ ^pd[0-9]{2}$ ]]; then
    mode=production
elif [[ $hostname =~ ^stg\-pd[0-9]{2}$ ]]; then
    mode=staging
else
    mode=test
fi
fluentd=/usr/lib/fluent/ruby/bin/fluentd
if [ -f "/usr/lib64/fluent/ruby/bin/fluentd" ]; then
    fluentd=/usr/lib64/fluent/ruby/bin/fluentd
fi
if [ -f /etc/sysconfig/$prog ]; then
    . /etc/sysconfig/$prog
fi
RUN_USER=td-agent
RUN_GROUP=td-agent
PIDFILE=/var/run/td-agent/$prog.pid
CONF_FILE=/etc/td-agent/$prog-$mode.conf
LOG_FILE=/var/log/td-agent/$prog.log
FLUENTD_ARGS="--group $RUN_GROUP -d $PIDFILE -c $CONF_FILE -o $LOG_FILE -q"

if [ -n "${PIDFILE}" ]; then
    mkdir -p $(dirname ${PIDFILE})
    chown -R $RUN_USER:$RUN_GROUP $(dirname ${PIDFILE})
fi
# use jemalloc to avoid fragmentation
if [ -f "/usr/lib/fluent/jemalloc/lib/libjemalloc.so" ]; then
    export LD_PRELOAD=/usr/lib/fluent/jemalloc/lib/libjemalloc.so
fi
if [ -f "/usr/lib64/fluent/jemalloc/lib/libjemalloc.so" ]; then
    export LD_PRELOAD=/usr/lib64/fluent/jemalloc/lib/libjemalloc.so
fi
RETVAL=0
start() {
    echo -n "Starting $name[$mode]: "
    daemon --pidfile=$PIDFILE --user=$RUN_USER $fluentd "$FLUENTD_ARGS"
    RETVAL=$?
    echo
    [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$prog
    return $RETVAL
}
stop() {
    echo -n "Shutting down $name[$mode]: "
    if [ -e "${PIDFILE}" ]; then
        killproc -p ${PIDFILE} || killproc $prog
    else
        killproc $prog
    fi
    RETVAL=$?
    echo
    [ $RETVAL -eq 0 ] && rm -f $PIDFILE && rm -f /var/lock/subsys/$prog
    return $RETVAL
}
restart() {
    stop
    start
}
reload() {
    echo -n "Reloading $name[$mode]: "
    killproc -p $PIDFILE $prog -HUP
    echo
}
case "$1" in
    start)
        start
        ;;
    stop)
        stop
        ;;
    restart)
        restart
        ;;
    reload)
        reload
        ;;
    condrestart)
        [ -f /var/lock/subsys/$prog ] && restart || :
        ;;
    status)
        status -p $PIDFILE $prog
        ;;
    *)
        echo "Usage: $prog {start|stop|reload|restart|condrestart|status}"
        exit 1
        ;;
esac
exit $?

設定ファイル

■ログ転送（送信）用の設定ファイル

/etc/td-agent/td-agent-paid-web-forwarder-production.conf
/etc/td-agent/td-agent-paid-web-forwarder-staging.conf
/etc/td-agent/td-agent-paid-web-forwarder-test.conf

ログ転送元の起動スクリプト /etc/rc.d/init.d/td-agent-paid-web-forwarder から
実行環境毎に、上記の3ファイルのうち1つが読み込まれます。

■■
ログ転送（送信）用の設定ファイルの内容

include config.d/paid/input/*.conf
include config.d/paid/forward/production/forward.conf
include td-agent-common.conf

上記は /etc/td-agent/td-agent-paid-web-forwarder-production.conf の内容ですが
staging, test環境用はproductionの部分を置換しただけです。

これは include ディレクティブで外部の設定ファイルを読み込むだけの設定です。

■
ログ転送（受信）用の設定ファイル

/etc/td-agent/td-agent-paid-web-aggregator-production.conf
/etc/td-agent/td-agent-paid-web-aggregator-staging.conf
/etc/td-agent/td-agent-paid-web-aggregator-test.conf

ログ転送先の起動スクリプト /etc/rc.d/init.d/td-agent-paid-web-aggregator から
実行環境毎に、
上記の3ファイルのうち1つが読み込まれます。

■■
ログ転送（受信）用の設定ファイルの内容

include config.d/paid/forward/production/aggregate.conf
include config.d/paid/output/*.conf
include td-agent-common.conf

上記は /etc/td-agent/td-agent-paid-web-aggregator-production.conf の内容ですが
これもstaging, test環境用はproductionの部分を置換しただけです。

同じく include ディレクティブで外部の設定ファイルを読み込むだけの設定です。

■共通の設定ファイル

/etc/td-agent/td-agent-common.conf

全体で共通して読み込む設定ファイルです。commonというネーミングにマサカリが飛んできそうですね。

■■共通の設定ファイルの内容

<match null>
  type null
</match>
<match fluent.**>
  type file
  path /var/log/td-agent/fluent
</match>
<match **>
  type file
  path /var/log/td-agent/unmatched
  compress gz
</match>

上から順に解説します。

<match null>
  type null
</match>

上記は、out_nullプラグインを使い、"null"というタグを持つログを破棄するための設定です。
意図的に破棄したいログに対して使おうとしていましたが、導入時は使いませんでした。
/dev/null のようなものですね。

<match fluent.**>
  type file
  path /var/log/td-agent/fluent
</match>

上記は、out_fileプラグインを使い、fluentd 内部のログを
/var/log/td-agent/fluent.20131118_0.log
のような名前のファイルに出力するための設定です。

<match **>
  type file
  path /var/log/td-agent/unmatched
  compress gz
</match>

上記は、同じくout_fileプラグインを使い、いずれにもマッチしなかったタグを持つログを
/var/log/td-agent/unmatched.20131118_0.log
のような名前のファイルに出力するための設定です。
どれだけ出力されるのかが不明だったため、ローテート時にgzip圧縮し、拡張子に.gzが追加される設定を有効にしています。

※失敗談： 実は7/1の導入時は（実は現在も・・・）全体的に

　path /var/log/td-agent/fluent.log
　path /var/log/td-agent/unmatched.log

　のように、path の末尾に.logを書いてしまっていたために、作成されるログファイル名が
　fluent.log.20130701_0.log
　のように.logが重なってしまっていました・・・

　下記のページに path の仕様がちゃんと書かれています。真面目に読まなきゃダメですね・・・
　http://docs.fluentd.org/articles/out_file


　> The Path of the file. The actual path is path + time + ”.log”.

■Paidのログファイル
弊社が運営するサービスの多くはJavaで開発されています。
フレームワークはSeasar2, S2Dao, Hibernate, S2Struts, Tilesといったところで、
Apache Tomcat上で動作しています。
（最近はPlay Framework、Ruby on Railsを使った開発もあります）

このため、今回はアプリケーション内で出力しているアクセスログファイルを対象とします。
以下、「Paidのログファイル」とは、このアクセスログファイルのことを指します。

アクセスログファイルは下記のようなフォーマットになっています。
（実際にはユーザーIDや、その他の情報も含まれていますが、ここでは省略しています）

2013-07-01 16:35:02,665 HEAD http://paid.jp/v/contents/index.jsp 7
2013-07-01 16:36:01,675 HEAD http://paid.jp/v/contents/index.jsp 6

■Paidのログファイルを読み込みための設定ファイル

/etc/td-agent/config.d/paid/input/java-pd.conf

■■Paidのログファイルを読み込みための設定ファイルの内容
　　　※path, formatは改変しています。

# input ( -> raw.paid.tomcat-pd.tomcat.access)
<source>
  type tail
  path /var/log/tomcat6-pd/access.log
  pos_file /var/log/td-agent/paid_tomcat-pd_tomcat_access.pos
  tag raw.paid.tomcat-pd.tomcat.access
  format /^(?<time>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2},\d{3}) (?<method>[A-Z]+) (?<url>.+) (?<response_millis>\d+)$/
  time_format %Y-%m-%d %H:%M:%S,%L
</source>
# filter (raw.paid.tomcat-pd.tomcat.access -> forward.paid.tomcat-pd.tomcat.access.${hostname})
<match raw.paid.tomcat-pd.tomcat.access>
  type rewrite_tag_filter
  remove_tag_prefix raw
  hostname_command hostname -s
  rewriterule1 method .* forward.${tag}.${hostname}
</match>

上から順に解説します。

# input ( -> raw.paid.tomcat-pd.tomcat.access)
<source>
  type tail
  path /var/log/tomcat6-pd/access.log
  pos_file /var/log/td-agent/paid_tomcat-pd_tomcat_access.pos
  tag raw.paid.tomcat-pd.tomcat.access
  format /^(?<time>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2},\d{3}) (?<method>[A-Z]+) (?<url>.+) (?<response_millis>\d+)$/
  time_format %Y-%m-%d %H:%M:%S,%L
</source>

上記は、in_tailプラグインを使い、tail -F コマンドのように
ログファイルに追記される度に書き込まれたログ（1行単位）を読み込むための設定です。
ログファイルがローテートされても、もちろん追従してくれます。

# filter (raw.paid.tomcat-pd.tomcat.access -> forward.paid.tomcat-pd.tomcat.access.${hostname})
<match raw.paid.tomcat-pd.tomcat.access>
  type rewrite_tag_filter
  remove_tag_prefix raw
  hostname_command hostname -s
  rewriterule1 method .* forward.${tag}.${hostname}
</match>

上記は、fluent-plugin-rewrite-tag-filterプラグインを使い、最初にタグの先頭の raw を除去し、
次にタグの先頭に forward を、タグの末尾に ${hostname} を付加しています。
${hostname} は hostname_command で指定した hostname -s コマンドの実行結果に置き換わります。
この設定はログの転送後に、そのログがどのサーバーから転送されてきたのかを残すための準備です。

これは /etc/td-agent/config.d/paid/input/java-pd.conf と大して変わらないので省略します。

/etc/td-agent/config.d/paid/input/java-pd-web-service.conf

■Paidのログファイルを転送（送信）するための設定ファイル

/etc/td-agent/config.d/paid/forward/{production,staging,test}/forward.conf

■■Paidのログファイルを転送（送信）するための設定ファイルの内容
　　　※hostは改変しています。

# filter (forward.paid.*.*.access.${hostname} -> production.forward.paid.*.*.access.${hostname})
<match forward.paid.*.*.access.*>
  type route
  <route forward.paid.*.*.access.{pd01,pd02,pd03,pd04}>
    add_tag_prefix production
  </route>
</match>
# forward-output (production.forward.paid.*.*.access.${hostname} -> )
<match production.forward.paid.*.*.access.*>
  type forward
  heartbeat_type tcp
  buffer_type file
  buffer_path /var/log/td-agent/forward-paid.buf
  <server>
    name pd04
    host 192.168.2.4
  </server>
  #<server>
  #  name pd03
  #  host 192.168.2.3
  #  standby
  #</server>
  <secondary>
    type file
    path /var/log/td-agent/forward-paid.err
    compress gz
  </secondary>
</match>

上記は /etc/td-agent/config.d/paid/forward/production/forward.conf の内容ですが
staging, test環境用はproductionの部分、route内のホスト名、hostの部分を置換しただけです。

上から順に解説します。

# filter (forward.paid.*.*.access.${hostname} -> production.forward.paid.*.*.access.${hostname})
<match forward.paid.*.*.access.*>
  type route
  <route forward.paid.*.*.access.{pd01,pd02,pd03,pd04}>
    add_tag_prefix production
  </route>
</match>

上記は、fluent-plugin-routeプラグインを使い、転送前にホスト名の簡易チェックを行った後に、
チェックがOKであればタグの先頭に production を付加しています。
チェックがNGであればunmatchedのログファイルに出力されます。

※転送時の送信側と受信側で、タグに付加された実行環境毎に異なる文字列をチェックすることで
　誤ってテスト環境から本番環境の fluentd にログを転送するリスクを減らそうとする目論見です。
　本来は iptables などで接続制限を加えるべきなのでしょうが、現在はそこまでしていません。

# forward-output (production.forward.paid.*.*.access.${hostname} -> )
<match production.forward.paid.*.*.access.*>
  type forward
  heartbeat_type tcp
  buffer_type file
  buffer_path /var/log/td-agent/forward-paid.buf
  <server>
    name pd04
    host 192.168.2.4
  </server>
  #<server>
  #  name pd03
  #  host 192.168.2.3
  #  standby
  #</server>
  <secondary>
    type file
    path /var/log/td-agent/forward-paid.err
    compress gz
  </secondary>
</match>

上記は、out_forwardプラグインを使い、ログを転送（送信）するための設定です。
パフォーマンスはかなり落ちますが、転送（送信）時にファイルバッファを使いログ消失を防止したり、
転送（送信）エラーとなったログをファイルへ書き込んで残したりしています。
コメントアウトされているログ転送先のスタンバイは、まだ稼働していません・・・

■Paidのログファイルを転送（受信）するための設定ファイル

/etc/td-agent/config.d/paid/forward/{production,staging,test}/aggregate.conf

■■Paidのログファイルを転送（受信）するための設定ファイルの内容

# forward-input ( -> production.forward.paid.*.*.access.${hostname})
<source>
  type forward
</source>
# filter (production.forward.paid.*.*.access.${hostname} -> paid.*.*.access.${hostname})
<match production.forward.paid.*.*.access.*>
  type route
  <route production.forward.paid.*.*.access.*>
    remove_tag_prefix production.forward
  </route>
</match>

上記は /etc/td-agent/config.d/paid/forward/production/aggregate.conf の内容ですが
staging, test環境用はproductionの部分を置換しただけです。

上から順に解説します。

# forward-input ( -> production.forward.paid.*.*.access.${hostname})
<source>
  type forward
</source>

上記は、in_forwardプラグインを使い、ログを転送（受信）するための設定です。

# filter (production.forward.paid.*.*.access.${hostname} -> paid.*.*.access.${hostname})
<match production.forward.paid.*.*.access.*>
  type route
  <route production.forward.paid.*.*.access.*>
    remove_tag_prefix production.forward
  </route>
</match>

上記は、転送されてきたログのタグに、実行環境が同一であることを示す文字列が含まれているかチェックしています。
チェックがOKであれば転送（送信）前にタグの先頭に付加された production.forward を除去します。
チェックがNGであればunmatchedのログファイルに出力されます。

■転送されてきたPaidのログファイルを集約して書き込むための設定ファイル

/etc/td-agent/config.d/paid/output/java-pd.conf

■■転送されてきたPaidのログファイルを集約して書き込むための設定ファイルの内容

# output (paid.tomcat-pd.tomcat.access.${hostname} -> )
<match paid.tomcat-pd.tomcat.access.*>
  type file
  path /var/log/td-agent/aggregate_paid_tomcat-pd_tomcat_access
  compress gz
</match>

上記は、out_fileプラグインを使い、ログをファイルへ書き込む設定です。
だいたい上の方で説明済みですね。

ファイルへは、タイムスタンプ、タグ、JSONの順で、タブ文字区切りで書き込まれます。

2013-07-01T16:35:02+09:00    paid.tomcat-pd.tomcat.access.pd01    {"method":"HEAD","url":"http://paid.jp/v/contents/index.jsp","response_millis":"7"}
2013-07-01T16:36:01+09:00    paid.tomcat-pd.tomcat.access.pd02    {"method":"HEAD","url":"http://paid.jp/v/contents/index.jsp","response_millis":"6"}

これも /etc/td-agent/config.d/paid/output/java-pd.conf と大して変わらないので省略します。

/etc/td-agent/config.d/paid/output/java-pd-web-service.conf

まとめ

7/1の導入から4ヶ月以上経ちましたが、fluentd(td-agent) はノートラブルで動き続けています。
現在はPaidだけですが、次はSUPER DELIVERYへの導入を考えています。

一緒にラクーンのサービスを作りませんか？ 採用情報を詳しく見る

関連記事

運営会社：株式会社ラクーンホールディングス(c)2000 RACCOON HOLDINGS, Inc