blogこの広告は、90日以上更新していないブログに表示しています。inc.)の技術ブログinFablicに投稿した記事(http://in.fablic.co.jp/entry/2015/12/25/110618)になります。inFablicが閉鎖され閲覧ができなくなってしまったため、会社の了承を取った上で転載しております。元記事にリンクを貼っていただいていた方に対しては大変お手数ですが、こちらにリンクし直していただければ幸いです。25日目のエントリです。こんにちは、Fablicでサーバーサイドエンジニアをしている@yutadayoです。今回はフリルのアクセスログをどのように収集し、活用しているかを紹介します。ログ収集で実現したいことログ収集にあたり、以下のような実現したいことがありました。考える仮説の裏付けとなるデータの抽出エラーや障害時の調査MySQLを使用したデータ分析や管理画面などの整備も行っていますが、ログからしか分からないものに関しては収集してきちんと利用できるようにするのが最終的なゴールです。使用している技術は以下の通りです。nginxfluentdBigQueryElasticsearchKibanaシステム構成フリルのシステム構成の概略を図にすると以下のようになります。フリルでは数十台のサーバを運用しているので、アプリケーションサーバから集約サーバに一旦ログを集め、そこからBigQuery、Elasticsearch、S3に転送しています。処理の流れログを収集するまでの大まかな設定を紹介します。fluentdのインストールや各ツールの設定などは、情報も豊富なので省略します。td-loggerを使用しています。設定を以下に記載します。fril例として検索ログを出力する際は下記のようにメソッドを呼び出します。endpointのパラメータを整形しセットしています。...})このとき出力するログ形式のschemaとBigQueryに作成するテーブルのschemaを合わせておくと良いでしょう。60s</match>アプリケーション内で設定したログのマッチ設定を記載し、集約サーバへforwardするようにします。集約サーバのログコレクタ集約サーバ側のtd-agentでS3やBigQueryに保存する設定を以下に記載します。</store></match>注意点BigQueryを使う上で注意が必要なのは、課金の部分です。BigQueryはクエリ発行毎(走査したデータの分)に料金が掛かってしまうため、保存するテーブルはある程度小さめにしておくと安全です。そのため、定期的にBigQueryにテーブルを作成するバッチを実行し、日毎にテーブルを分けてログを保存するようにしています。ような形式で作成されます。活用方法BigQueryの導入でユーザーの行動に紐づくデータの解析が誰でもできるようになり、仮説の検証がとてもしやすくなりました。その他にも、ログを使って検索ランキングを実装したり、日時のバッチ処理でログデータからKPIデータを作成したり、アクセスログをKibanaで可視化したりなど、色々な箇所で役立てています。Fablicでは開発者だけでなく、デザイナーやマーケティングの担当者もBigQueryを使ってデータの分析を行っています。このため、全社での知見共有や、新しい方が入社された際にもすぐに業務ができるように、QiitaTeamなどでTipsを社内公開するようにしています。まとめフリルで行っているログの収集とそれの活用事例を紹介させていただきました。サービスを開発する上での仮説検証や、改善サイクルを回す上でログから分かるデータは非常に有用です。Fablicでは日々より良いサービスを作るために、データを活用し、プロダクト開発を行っています。CTOを退任しました。CTOを退任しました。(2)はてなブログをはじめよう!yutadayoさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。