Google Data Studio で BigQuery ログを可視化してディレクターのデータ依頼から解き放たれる - Qiita
この記事は「エムスリー Advent Calendar 2016」の 10日目の記事です 今年の5月に無償版が提供されている Google Data Studio ですが、使った人たちのコメントを見ているとドキュメントを読まなくても、いきなり使えるというメリットがあったものの、SQLを書けないというデメリットがあって、 他の無料ツールの Re:dash (無料だとサーバーが必要)の方がデータ分析的に使えるかなと思っていました。 しかし、最近この記事を読んでいて、逆に SQLクエリを書かなくて良い ということが (ディレクターに丸投げできるという意味で) 最大の魅力ということに気づきました。ということで、 Google Data Studio を使うことで、ディレクターがよく見たい指標ランキングTOPに挙がるであろうユーザーのアクセスログを可視化したので、ログ収集部分からまるっと解説します。
Heroku アプリのログを fluentd で ElasticSearch に突っ込んで Kibana で監視する方法 - hakobera's blog
目的 Kibana で Heroku アプリのログを可視化したい。ただし、レスポンスタイムとかは New Relic でも見れるので、ここではアプリが出力したらログを可視化する方法を紹介する。 また、今回、アプリからの出力を可能な限りに簡単にするために、アプリからは Heroku の STDOUT に出力するだけで、ログを Kibana サーバに送信できるようにしてみた。 具体的にはこう。（Ruby の場合） 出力の形式は、Treasure Data addon の方法 を真似ている。 puts "@[tag.name] #{{'uid'=>123}.to_json}" これで、tag.name が fluentd の tag 名に、それに続く JSON 文字列が送信するデータとして処理される。 環境 Amazon EC2 上に Kibana サーバを構築 OS は Ubuntu 13.1
Collecting and Analyzing Ruby on Rails Logs | Fluentd
Scenario You have an application written in Rails and want to collect data into MongoDB, HDFS, Elasticsearch, et. al. for analytics/search. Logging directly into MongoDB/HDFS/Elasticsearch is not highly recommended since synchronous logging is slow/potentially hazardous for the backend. You can build asynchronous logging into your application, but Fluentd can sit between your application and backe
fluentdでnginxのログをElasticsearchとBigQueryに保存するお話 - ハウテレビジョンブログ
こんにちは。夏休みに長野に行って居酒屋で馬刺しをたらふく食べていたら 地元のおっさん人生の大先輩の絡み酒に付き合わされた祖山です。 4月に入社して以降、サーバサイドのWeb開発やスクラムの導入、サイト内検索の改善など様々な業務に 取り組んでいますが、最近の大きな案件としては、アクセスログ解析基盤の整備がありました。 nginxのアクセスログを分析しやすい環境を作るため、ElasticsearchとBigQueryにログを蓄積し始めたのですが、 その際に一番のキモとなるのは、みんな大好きfluentdです。 今回は、我々ハウテレビジョンがどのようにアクセスログを収集、保存しているのかについて、fluentdの設定を中心にご紹介します。 アクセスログ収集の目的 現在の我々のサービス環境を考慮すると、アクセスログの収集には下記2つの目的が存在します。 アクセス情報をもとにユーザーの行動を解析 閲
Fluentdとログ収集のパターン - Go ahead!
「ログを集めて保存する」と言うのは簡単だけど，ログ収集の構成にはいくつか方法があり，勉強会などでちょくちょく聞かれるので，いくつかのパターンについて書く． 「俺はもうバリバリログ収集やってるぜ！」という人は多分すでに知っていることが書かれているので，タブを閉じて良い． ここではログコレクタにFluentdを想定しているが，他のログ収集プロダクトにも適用出来るはず． ただ，Fluentdはタグベースのルーティングを持ち，単体でもキューのように動作させることが可能で，既存のものより複雑な問題を解決しようとしているので，少し工夫が必要かもしれない． Fluentdそのものについては公式ドキュメントや，Fluentdとはどのようなソフトウェアなのかを参考に． クライアントから直接保存する いきなりFluentdを使わないパターン．JavaScript SDKを提供している解析サービスやモバイル端末
マゾいログ回収の話と未来
Fluentd Meetup 新しい応用事例とv1に関する発表 http://eventdots.jp/event/49560
【進撃の巨大データ】Log集計用DBとシステム構成の美しい設計を考える - Y's note
[:W560] Log集計用DB設計 考える問題 Document無しのAgile開発をガチで推奨したい@yutakikuchi_です。【進撃の巨大データ】の第2回目として巨大アクセスLog集計用DBの設計について勉強した内容についてメモしたいと思います。DB周りはそこまで詳しく無いので詳しい皆様からの突っ込み大歓迎でございます。また図々しいですが知恵をください(笑)。 今日の主目的は下の2要件を叶えるためのDB設計を考える事です。特に問題になるのがRealTimeの話でTableにLogDataを書き込む処理と集計のSQLをどのように組み立てるか、それ以外にもSystemPerformanceとArchitectureにも関わってきます。 リアルタイムで大量データを集計したい 定期処理で大量データを集計したい 使うもの Fluentd : Fluentd: Open Source Log
広告ログ解析基盤にFluentdを使っている話 - すずけんメモ
これはFluentd Advent Calendar 14日目の記事です。 私は現在、VOYAGE GROUPの子会社であるadingoで、DMP cosmiの開発をしています。今日はcosmiでのfluentd利用の話をしようと思います。 DMPについて 過去に勉強会でアドテクまわり及びDMPについて話したのでそれを貼っておきます。ざっというと、いい感じにいろんなログを受けいられるようにして、それらをモニタリングしながら整理して使えるようにする、という役割をもったプロダクトです。 Head First Ad Technology and DMP http://www.slideshare.net/suzuken/head-first-ad-technology-and-dmp どこで使っているか ほぼ全てです。構成としては ログ収集サーバ | | out-forward (roundro
Kibana3 + elasticsearch + fluentd を試した
こんにちは。@jedipunkz です。 {% img /pix/kibana3.png %} 前回の記事で Kibana + elasticsearch + fluentd を試しましたが、ツイッターで @nora96o さんに “Kibana3 使うと、幸せになれますよ！” と教えてもらいました。早 速試してみましたので、メモしておきます。 前回の記事。 http://jedipunkz.github.io/blog/2013/09/07/kibana-plus-elasticsearch-plus-fluentd/ 前半の手順は前回と同様ですが、念のため書いておきます。 前提の環境 OS : Ubuntu 12.04 Precise (同じ方法で 13.04 Raring でも出来ました) 必要なパッケージのインストール 下記のパッケージを事前にインストールします。 手順を省くために
Kibana + ElasticSearch + fluentd を試してみた
こんにちは。@jedipunkz です。 自動化の流れを検討する中でログ解析も忘れてはいけないということで ElasticSearch を使いたいなぁとぼんやり考えていて Logstash とか Kibana とかいうキーワードも目 に止まるようになってきました。 ElasticSaerch は API で情報を検索出来たりするので自動化にもってこい。バックエ ンドに Logstash を使って… と思ってたのですが最近よく聞くようになった fluentd をそろそろ真面目に使いたい！ということで、今回は Kibana + ElasticSearch + fluentd の組み合わせでログ解析システムを組む方法をメモしておきます。 参考にさせて頂いた URL http://memocra.blogspot.jp/2013/04/kibanakibanaelasticsearchfluent
Amazon Linux でApacheのログを Fluentd経由でMongoDBに集約する - aws memo
10genからこんな記事が The 10gen Blog on MongoDB and NoSQL, Fluentd + MongoDB: The Easiest Way to Log Your Data Effectively. === ということで、Amazon Linuxでの環境構築メモ まずは、httpd+Fluentdを入れるインスタンス (web)と、MongoDBを入れるインスタンス(mongo)を用意して、インストール。 EC2: AMazon Linux にFluentdをインストール - aws memo EC2: AmazonLinuxにMongoDBをインストール - aws memo 次に、fluent-plugin-mongo をインストール $ sudo /usr/local/bin/fluent-gem install fluent-plugin-mongo
Kibana 3 + Rails + Fluentdのサンプルアプリを作ってみた - y_310's diary
miyagawaさんのPodcast Rebuild: 19でKibanaの話があってちょっと盛り上がり始めてるので、簡単に動作を試せるサンプルアプリセットを作ってみました。 https://github.com/y310/kibana-trial git cloneしてREADMEに書いてある手順を実行していくと大体動くと思います。 railsからfluentdにログを送る部分は、こんな感じでrack middlewareを使って送ります。 # application_controller.rb class ApplicationController < ActionController::Base around_filter :collect_metrics def collect_metrics yield # ensureを使うのは例外時のログも捕捉するため ensure # co
S3とFluentdを用いた効率的なログ管理 | SmartNews開発者ブログ
ゴクロの大平です。 私にとって一番大事で替えの効かないミュージシャンはさだまさしさんですが、私にとってクラウドコンピューティングのサービスの中で一番大事で替えが効かないサービスはS3です。 多種多様なAPIを用いて柔軟にファイルの操作が出来る事や、”99.999999999％”と謳われている高い耐障害性、S3にあるデータをElastic MapReduceやRedshiftなどを用いて手軽にデータ解析を行える基盤が提供されていることなど、あまりに便利すぎてS3の代替となるサービスを探しだすのが難しい状態です。 もちろん多くのAWSユーザーが同じようにS3の便利さを享受していると思いますし、インターネット上でも多くのブログ等でその魅力が語られています。その中で本記事は既に存在する記事と似たような内容を書いてしまうかもしれませんが、弊社なりのS3の使い方についてご紹介したいと思います。 なお
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - actindi/act-fluent-logger-rails: Fluent logger
OSS編～Fluented & Elasticsearch & Kibanaパート①～
Casual Log Collection and Querying with fluent-plugin-riak - RubyKaigi 2013 on Vimeo
Complex Event Processing on Ruby, Fluentd and Norikra #rubykaigi
OSSで支えられるライブドアの巨大ログ集計 #nhntech