この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
コンニチハ、千葉です。
AutoScalingに組み込んでいるサーバのログ監視をしたいことって、よくあると思います。 今回は、AutoScaling配下のサーバにfluentdを入れてログ収集サーバにて一括で集めて、ログ監視をする場合に気をつけたことをまとめておきます。
ログサーバ側のtd-agent.conf
ログサーバではこんな感じで、td-agent.confを設定しました。
<source>
type forward
port 24224
bind 0.0.0.0
</source>
<match dev.web.log>
type copy
<store>
type file
buffer_path /var/log/td-agent/buffer/local_dev.web.log.buf
symlink_path /var/log/td-agent/logs_current/dev.web.log
path /var/log/td-agent/logs/dev.web.log
time_slice_format %Y%m%d
time_slice_wait 10m
flush_interval 60m
flush_at_shutdown true
format out_file
buffer_chunk_limit 32m
</store>
</match>
<match dev.batch.log>
type copy
<store>
type file
buffer_path /var/log/td-agent/buffer/local_dev.batch.log.buf
symlink_path /var/log/td-agent/logs_current/dev.batch.log
path /var/log/td-agent/logs/dev.batch.log
time_slice_format %Y%m%d
time_slice_wait 10m
flush_interval 60m
flush_at_shutdown true
format out_file
buffer_chunk_limit 32m
</store>
</match>
以下が、設定のポイントです。
監視するログを固定する
シンボリックリンクを監視するため、ツールによってはリンク切替のタイミングで、ロストする可能性があります。利用する際は検証を必ずお願いします。
監視するログを固定したいですよね。しかし、何も考えずにデフォルトで設定すると、受信したログは以下にようにログが出力されます。
[root@dev logs]# ls -l /var/log/td-agent/logs
total 8
-rw-r--r-- 1 td-agent td-agent 230 Apr 27 05:35 dev.web.log.20160427.b53170c7a0af5ab90
-rw-r--r-- 1 td-agent td-agent 115 Apr 27 05:34 dev.web.log.20160427_0.log
カレントのログ名の後ろにはハッシュがつきます。そして、td-agentを再起動したり、一定期間または一定サイズになるとweb.log.201604_0.logのようにアーカイブされます。ログ監視したいので、ログ名を固定したいです。ということで、以下の設定を追加します。
buffer_path /var/log/td-agent/buffer/local_dev.web.log.buf
symlink_path /var/log/td-agent/logs_current/dev.web.log
これで、カレントログが固定されます。(厳密にはシンボリックリンク) このログを監視してあげればokです。
[root@dev logs_current]# ls -la
lrwxrwxrwx 1 td-agent td-agent 73 Apr 27 05:42 dev.web.log -> /var/log/td-agent/buffer/local_dev.web.log.buf.20160427.b53170e0ad768594a.log
因みにアーカイブログは、pathで指定したパスに出力されます。
アーカイブログを削除する
アーカイブログは放っておくと、無限に貯まります。当たり前ですが。 なので、アーカイブログを出力するフォルダに対して一定期間経過したらログを削除する処理を入れます。 cronで一日一回任意のタイミングで実行します。
[root@dev logs_current]# sudo crontab -u td-agent -l
50 3 * * * tmpwatch -m 72 /var/log/td-agent/logs
送信側のtd-agent.conf
送信側ではこんな感じで、td-agent.confを設定しました。
<source>
type tail
format none
path /opt/td-agent/logs/web.log
pos_file /var/log/td-agent/pos/web.log.pos
tag dev.web.log
</source>
<source>
type tail
format none
path /opt/td-agent/logs/batch.log
pos_file /var/log/td-agent/pos/batch.log.pos
tag dev.batch.log
</source>
<filter dev.**>
@type record_transformer
<record>
host ${hostname}
</record>
</filter>
<match dev.** >
type forward
host xx.xx.xx.xx
port 24224
expire_dns_cache 0
flush_interval 60s
</match>
以下が、設定のポイントです。
posファイルの利用
posファイルを指定し、ログの末尾から読み込むようにします。
pos_file /var/log/td-agent/pos/batch.log.pos
ログの中にホスト名を入れる
エラー検知した場合に、ホスト名がわからないと辛い場面があります。filterを使うことで、ホスト名を入れることができます。
<filter dev.**>
@type record_transformer
<record>
host ${hostname}
</record>
</filter>
ログサーバ側で受信したログにはこんな感じでhost名が入ります。
[root@dev logs]# cat web.log.20160427_0.log
2016-04-27T05:41:39+00:00 dev.web.log {"message":"15 /opt/td-agent/logs/web.log","host":"dev.web"}
flushのタイミング
ログサーバへログを送る間隔を指定します。 ここは監視要件に合わせる必要がありますが、あまり短くし過ぎるとtd-agentの負荷が高くなるので、今回は60秒としました。
flush_interval 60s
Jinja2でconfファイル作成を効率化する
Fluentd直接関係ないですが、Ansibleを利用しJinja2にてconfファイルを作成するとかなり楽でした。タイポもものすごく減ります。 こちらについては、別のブログで紹介したいと思います。
まとめ
ログ監視という観点で、まとめた記事を見つけられなかったのでまとめてみました。 参考になれば幸いです。この設定入れたほうがいいよ!というものがあれば、是非コメントください!