fluentdでGoogle Compute Engineのログを一つに集約する

前回、Google Compute EngineでオートスケールするWebサーバーを構築しましたが、ログが各サーバーに分散したり、インスタンスが終了するとログも消えるので、Fluentdでログを一カ所に集めることにしました。

1 オートスケールは便利だがどこに接続しているかわからん
2 Fluentdというのが流行
3 google-fluentdというものがある
4 nginxとphp-fpmのログを転送する
5 php-fpmのログも転送
6 Google Develoer Consoleのログ
7 Big Queryへ転送
8 GCEでログ管理ならgoogle-fluentd

オートスケールは便利だがどこに接続しているかわからん

前回の記事↓

　前回、GCE上に負荷に応じて自動でサーバーが勝手にできあがっては消えていくオートスケールのWordPressサーバーを構築しましたが、問題が起きたときのログを確認するのが非常に面倒だと気づきました。

　MarsEditからWordPressに画像投稿すると、絶対に投稿に失敗するという問題が起きていまして(現在は解決)、ただWebサーバーが複数あるので、一体どこのサーバーにエラーログが残っているかわからない。片っ端から見るのは面倒…。

Fluentdというのが流行

　最初はsyslogでログを転送して一カ所に集めようとしましたが、ネットを調べていると、今はログの収集にはFluentdを使うのがトレンドと知りました。

　私もよくわかってませんが、入力と出力がプラグイン化されていて、たとえばNginxのアクセスログをMongoDBに出力して解析するなんてことができるみたいです。JSON形式出力できたりするのが今風な感じですね。

　そんなわけでGCE上にFluentdとMongoDBをインストールしてみました。

　forwardするときのportをデフォルトの24224のままにしていたら、no nodes are availableとエラー吐いて進まなかったけど、どうも他のプログラムがそのポート使っていたらしく、24223に変えたらうまくいきました。

　…なんですが、どうもfluentdはGoogleがカスタマイズして、GCE上で使いやすくしたモノが別にあるみたいなんですね。

google-fluentdというものがある

　インストールしたfluentdを削除して、あとは上記のページの通りでGCE上のCentOS7にすんなり入りました。

　以下で、google-fluentdインストール。WebサーバーとDBサーバーの両方に入れました。

curl -sSO https://dl.google.com/cloudagents/install-logging-agent.sh
bash install-logging-agent.sh

これでサービスが起動し、自動起動もONになる。

chkconfigで見ると

google-fluentd     0:off    1:off    2:on    3:on    4:on    5:on    6:off

となっている。

インストール後はスクリプトは不要なので消す

rm install-logging-agent.sh

ログのテストはloggerコマンドを使う。

logger "test"

しばらくするとGoogle Developer Consoleの「ログ」に出てくる。

最初からいろいろconfig仕込んであるので、ログがバカスカでてくるが、自分は便利だと思って、そのままの設定にしている。

nginxとphp-fpmのログを転送する

/etc/google-fluentd/config.d/nginx-blog.conf配下にconfファイルを置くと、処理してくれる。

vi /etc/google-fluentd/config.d/nginx-blog.conf

たとえば、こんな感じで設定する。

<source>
  type tail
  path /var/log/nginx/a-tak.com/access.log
  tag nginx.a-tak.access
  pos_file /var/lib/google-fluentd/pos/nginx-a-tak-access_log.pos
  format none
  read_from_head true
</source>

<source>
  type tail
  path /var/log/nginx/a-tak.com/error.log
  tag nginx.a-tak.error
  pos_file /var/lib/google-fluentd/pos/nginx-a-tak-error_log.pos
  format none
  read_from_head true
</source>

source タグで転送するログファイルを指定する。

pathはログファイルの場所。

tagはログの種類わけに使う。Google Developer Cosole上で、ここで指定したタグで絞り込みが出来る。

pos_fileはログをどこまで読んだかを記録するファイルでどこかにファイル置き場を作ってあげればよい。

google-fluentdの場合は format は none にしないといけないらしい。

php-fpmのログも転送

vi /etc/google-fluentd/config.d/php-fpm.conf

<source>
  type tail
  path /var/log/php-fpm/error.log
  tag php-fpm.error
  pos_file /var/lib/google-fluentd/pos/php-fpm-error_log.pos
  format none
  read_from_head true
</source>

<source>
  type tail
  path /var/log/php-fpm/www-error.log
  tag php-fpm.www-error
  pos_file /var/lib/google-fluentd/pos/php-fpm-www-error_log.pos
  format none
  read_from_head true
</source>

サービス再起動は

systemctl restart google-fluentd.service

でできる。

Google Develoer Consoleのログ

　GCEの管理画面の「ログ」にしばらくするとログが出力され始める。

　Compute Engineを選んで、必要に応じてその横のドロップダウンでタグの絞り込みをするといい。

お手軽簡単ログビュワー

　さきほど設定した内容でインスタンステンプレートを作成すれば、オートスケールで勝手にできあがったサーバーからのログもこの画面に集約される。すげー便利。ログは30日間保管されるらしい。

Big Queryへ転送

　「ログ」に集約されたデータはさらにBig Queryに自動取り込みして、分析することが出来る。多種多様なログを「ログ」経由でビッグデータとして扱うことが出来ますな。

　設定は「ログ」の上にある「Exports」から「サービスを選択」で「Compute Engine」を選んで、「すべてのソース」にチェック入れて、「BigQuery データセットにストリーミングします」から「新しいデータセットを追加」で適当に名前入れるだけ。楽勝過ぎる。

[2015-11-02追記]
上の例では「すべてのソース」にチェック入れていますが、外すとどのタグのログを送るか指定できます。Webにアクセスしてきた人の行動分析用途ならば、nginxのアクセスログだけ送るようにすれば、節約になります。

もっと細かく制御したい場合は、fluentdのsourceを切って、タグを分けるといいと思います。

これだけでビッグデータ分析に回せる

　メニューからBigQueryを開くと、さきほど追加したデータセットがあります。

これが話題のビッグデータ

　「COMPOSE QUERY」押して右の欄にSQLを入れます。たとえばこんな感じ。

SELECT
  textPayload
FROM

[log.nginx_a_tak_access_20151031]

where textPayload like ‘%surface%’ LIMIT 1000

　上の例ではアクセスログで「surface」の文字がある行を1,000行まで引っ張ってきています。普通のデータベースだとLikeを使った部分一致は激遅なのですが、どんなにログが膨れようとも数秒で結果が返ってきます。さすがビッグデータです。

　ちなみに、BigQueryに取り込まれているデータは階層構造を持って取り込まれているので、SELECTの後は「*」にすると…

Error: Cannot output multiple independently repeated fields at the same time.

みたいなエラーになります。ちゃんと列名を指定しないといけません。

　テーブルを選んで右の方の「Details」を押すとテーブルの容量がわかります。デフォルトで「publicdata:samples」というデータセットがサンプルで用意されています。Wikipediaのデータもこの中にあって35.7GBのサイズです。これをLikeで検索しても、やっぱり数秒で応答が返ってきました。とんでもないです。