Kibanaでログ分析を1年続けてみたら業務システムの保守と運用が捗った / How&Why I have been leveraging Kibana for DevOps2015/4/4, Elasticsearch勉強会 in 名古屋 https://elasticsearch.doorkeeper.jp/events/21984 ブログ http://blog.exoego.net/2015/04/kibana4-use-case.html
[MongoDB] フロントエンドエンジニアにもできるMongoDBを使ったログ分析 - YoheiM .NET
このような表を作ることで、例えば以下のことがわかります。 経路002は流入数の割に獲得効率や翌日継続率も悪い。ここを改善するサービスをグロスできるかも。 経路003は獲得効率と翌日定着率が良い。何が良いのかをさらに分析すれば、他の流入経路の改善に生かせる。 Action2は翌日継続率に良い結果を与えている可能性がある。もう少し詳しく調べてみたい。 このようにユーザーの活性化は流入経路別に分析をすることで、問題点やチャンスを浮き彫りにすることができます。 今回はこの表を作るためにログ分析を行います。 ここまでで分析のスタート地点とゴール地点がわかりました。 あとはその間の道をつなぐためにプログラムを書くだけです。 次の章では、MongoDBでの分析を行うための準備段階を紹介します。 分析（準備編） ここでは分析の準備編として、サーバーログをダウンロードしてきて、整形して、MongoDBに登録
![[MongoDB] フロントエンドエンジニアにもできるMongoDBを使ったログ分析 - YoheiM .NET](https://cdn-ak-scissors.b.st-hatena.com/image/square/b26f45930fdedd4f83a397a5ca31bdc522aa697b/height=288;version=1;width=512/https%3A%2F%2Fwww.yoheim.net%2Fimage%2F348.jpg)
Hadoopを使ったログ分析システムにおける開発、デプロイのフローについて - wyukawa's diary
Hadoopを使ったログ分析システムっていうのを何回か経験してて、そういえば開発、デプロイのフローがあんまりうまく回せなかったよなあと思ったのでそのあたりについて今日は書きたいと思います。 まずネットワーク周りの前提から書きます。 サーバーにログインするには踏み台を経由しなければなりません。 なので、まあ例えばHadoopクラスタを構築してて、betaとrealの2つ環境があったら以下のようにログインすることになります。まあよくある話ですよね。 ローカルPC -> 踏み台 -> beta環境 ローカルPC -> 踏み台 -> real環境 でもってローカルPCとbeta,real環境との間の通信は制限されています。これもよくあるパターンだと思います。 beta,real環境からインターネットに出れない場合なんかは、ローカルPCからインターネットにアクセスしてtar ballとかrpmを持っ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
