[B! log] Yamashiro0217のブックマーク

ログ解析における統計値の妥当性 - wyukawa's diary

ログ解析における統計値の妥当性をどうやって担保するのかは難しい問題だと思っていてぶっちゃけ最終的にはオレを信じろ、でも間違ってたらゴメンの世界な気がする。社内で閉じていて外に出ない統計値ならまあいいんだけど、世の中そんな統計値ばかりではない。例えばWebサービスを展開していてそこに広告を出稿してもらって売り上げをたてたいとする。広告を出す方としてはそのサイトにどれぐらいPV/UUがあるか知りたいと思うのは当然ですよね。広告を出したら出したでインプレッション数が知りたいとかあるかもしれない。このような統計値はログを集めて集計することによって求めるわけなんだけど、数値が正しいかどうかをどうチェックするかというのは難しい問題ですよね。本来ならいろんなバリエーションのテストデータを作ってテストするんでしょうけど、テストデータ作るの大変だし、このビッグデータ時代？にはどんなデータが来るかわ

Yamashiro0217 2013/09/15

log
Hadoop

リンク

Kibana: What's Cooking

Search and analytics, data ingestion, and visualization – all at your fingertips.

Yamashiro0217 2013/08/30

kibana
log

リンク

Mozilla、Goで実装されたサーバーログ収集・分析ツール「Heka」を公開 | OSDN Magazine

Mozillaは4月30日、サーバーのログデータ収集や分析の簡素化を図るフレームワーク「Heka」のベータ版「Heka v0.2b1」をリリースした。サーバーの稼働状況に関するさまざまなデータの収集・分析などを簡素化・容易化するツールで、初めてのベータ版公開となる。 HekaはMozillaのサービスチームが開発したツール。メッセージのルーティング、収集、分析などの機能をもつ「hekad」とクライアントライブラリから構成されている。logstasch、statsd、syslogなどさまざまなツールが持つ役割を統合するもので、ログファイルやサーバー診断などのデータを収集し、標準形式に変換した後にルーティングルールセットに基づき評価してルーティングするという流れ。hekadはデータパイプラインの構築に適しているとの理由から米GoogleのGo言語で作成されており、軽量でほとんどのホストで動くと

Yamashiro0217 2013/05/03

go
log

リンク

LTSVフォーマットなログを fluentd + GrowthForecast で料理 - naoyaのはてなダイアリー

ここ数年のデータ解析の重要性の高まりから、ログに関するソリューションが方々で活発に探求されている昨今でございます。ウェブサーバーの単純なアクセスログをそのまま保存するではなく追加情報を添加してみたり、あるいはアプリケーションから直接ログを吐いてそれらをデータウェアに投げ込んで･･･というのも当然のように行うようになりましたね。しかしあまり自由度のない access_log の combined フォーマット。さてどうしたもんか･･･ここで id:stanaka の登場です。 Labeled Tab Separated Valueというのは、はてなで使っているログフォーマットのことで、広く使われているTSV(Tab Separated Value)フォーマットにラベルを付けて扱い易くしたものです。はてなでは、もう3年以上、このフォーマットでログを残していて、one-linerからflue

Yamashiro0217 2013/02/06

[ltsv

log
fluent

リンク

Labeled Tab Separated Values (LTSV) ノススメ - stanaka's blog

追記(2/8 11:30) id:naoyaによる一連のまとめが【今北産業】3分で分かるLTSV業界のまとめ【LTSV】 - naoyaのはてなダイアリーにあります。また、仕様などをまとめるために http://ltsv.org/ を立ち上げました。追記ここまで Labeled Tab Separated Values (LTSV) というのは、はてなで使っているログフォーマットのことで、広く使われているTSV(Tab Separated Value)フォーマットにラベルを付けて扱い易くしたものです。はてなでは、もう3年以上、このフォーマットでログを残していて、one-linerからfluentd、Apache Hiveまで幅広く便利に使えています。ログフォーマットに期待されることは、フォーマットが統一されている → 共通のツールで集計し易い新しいフィールドの追加が容易 → サー

Yamashiro0217 2013/02/06

log

リンク

combinedに代わるオレ流ログフォーマット - （ひ）メモ

こんにちは、combinedログ撲滅委員会のひろせです。 ApacheのcombinedやNginxのデフォルトのlog_formatは、機械処理(日付でのソートやパース)がしづらい上に、人の目にもあまり見やすいフォーマットとはいえないと思っています。なので自宅のサーバーでは、日付は ISO8601 にする sortコマンドとかで簡単にそぉーっとソートできるようになる日付、レスポンスコード、所要時間とか固定長的なフィールドは左に寄せる URLとかUAとか可変長で長いのは右に寄せるリクエスト(%r)も右に寄せた方ががいいような気がしてきた。。。数値だけだとわかりづらいのでなんとなくわかるようにフィールド名も添えるフィールド名を長くするとわかりやすくなる反面、ログサイズが大きくなるので注意という観点で次のようなログフォーマットにしています、 # Apache LogFormat