fluentd pluginで集計処理をする(Norikra以外で) - Qiita
はじめに 世間的には「fluentdで集計 ≒ Norikra!!!!!」という流れで、それに対して一石を投じる気のかけらも私には無いわけですが、Norikraを用いるまでもない軽微な処理を実行する場合fluentdのプラグイン単体で処理を完結したいケースもあり、そしてNorikraが若干重厚に映るケースもあります（JRuby!! Esper!!!） ということで、集計が行えるようなfluentd pluginについてまとめてみます。チョイスは僕の独断と偏見です。 ユースケース fluentdの基本的なユースケースは、inputとして入力をしたデータをoutput先にrelayする、というものです。そして集計処理は、多くの場合output先のシステム内、もしくはシステムに蓄積されたデータを用いて別のシステムを用いて行う事が多いと思います。 (ex. HDFSに保存したログデータをHiveを
ApacheログをLTSV形式にする際の２つの落とし穴と対処法＋Apache＆FluentdのLTSV設定サンプル - Y-Ken Studio
ApacheのアクセスログをLTSV形式にしたいと思った方に是非お伝えしたい、 私がハマった落とし穴とその対処方法、その後にApacheとFluentdの設定サンプルを紹介します。 以下に1つでも該当するものがあれば、LTSVの導入メリットは高いでしょう。 テクニカルな正規表現のメンテナンスに疲れた awk等のテキスト整形ツールで加工や集計を容易に行いたい ログ収集ツールFluentdを使ってリアルタイム集計などを行いたい 落とし穴 その１「request_first_line」 一般的なApacheの設定ファイルhttpd.confでは、デフォルトで以下の設定が行われています。 LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined このLogFormatStringをそのままLT
「fluentd」と「Storm」の比較について - Tous Les Jours 攻防記
まず、両者はかなり性質の異なるプロダクトなので、以下の比較は筋違い。 筋違いであることを前提に、ストリームデータ処理プラットフォームとしての両者を比べてみる。 基本情報 fluentd http://fluentd.org/ 今をときめくログコレクター/イベントアグリゲーター。Rubyで実装されているが軽量高速。 RPC基盤ではなく、その下のレイヤーに位置するプロダクト。 Storm http://storm-project.net/ 分散RPC基盤。ストリームデータ版MapReduce風フレームワーク。Java+Clojureで実装されている。 概要については、下記のスライドがとてもわかりやすかった。 Twitterのリアルタイム分散処理システム「Storm」入門 ストリームデータ処理で何をするのかについて ストリームデータ処理のニーズについて、自分が理解している範囲での簡単な説明。 典
走れfluentd | quipped
fluentdというソフトウェアがある。読者の多くは聞いたこともないソフトウェアだろう。そりゃそうだ。AndroidとかiOSとかWindowsのように、消費者の目に毎日さらされるものとは違い、日夜静かにデータセンターで動いているソフトウェアだ。 このfluentdは、もともと古橋貞之くんが、自分がはじめた会社のサービスの一部で必要となり書いたものだが、この1年半ほどで瞬く間に広まり、今では日本中のウェブサービスで導入されている。どのくらい広まっているのかと言うと、もし読者が今日 はてブをチェックしたり クックパッドでレシピを探したり NAVERまとめを見てゲラゲラ笑ったり GREEのサービスで遊んだり ライブドアニュースで蒼井優の動向を探ったり1 したなら、どこかでfluentdの恩恵を受けているということになる。 ちなみにこの古橋くん、ゆとり世代のダメダメなピチピチな25歳の若者で、ど
Fluentdで収集したログのHTTPステータスコードを集計し、結果をGrowthForecastでグラフ化する - FAT47の底辺インフラ議事録
最近個人的にいろいろ弄っているFluentdでまた記事をかきます。 これからやること。 (1) Fluentdで収集したApacheログをGrowthForecastでグラフ化 (2) fluent-plugin-datacounterを利用して、ログのHTTPステータスコードのチェックと集計を行い、結果をfluent-plugin-growthforecastでグラフ化 Fluentdの説明と導入記事は前回の記事で。 Apacheログをfluentd+MongoDBで収集しRubyで集計 GrowthForecastの導入も前回の記事から。 様々な値をWebAPI経由でグラフ化できる「GrowthForecast」をインストールしてみた まず (1)Fluentdで収集したApacheログをGrowthForecastでグラフ化 GrowthForecastのWebAPIを叩いてくれるf
fluent-agent-lite と td-agent で、小さくはじめる fluentd - Studio3104::BLOG.new
fluentdを使ってみたいけど、「JSONでシリアライズしなくていいのに・・・生でいいのに・・・」と思ってなかなか使い出せないというケースはままあるのではないでしょうか。 こんなときに困ってしまうからですよね。 rsyncやscpで毎日深夜にやってくる生ログを解析するスパゲッティスクリプトたちを使えなくなってしまう アプリケーションサーバにログをパースさせるための負荷をかけたくない それでも使ってみたい、現存の古臭い解析機構をアクティブにしたまま、徐々にfluentdによる先鋭的なログ解析を始められたらいいなと思っている方、 fluent-agent-lite と td-agent で、fluentd を小さくはじめてみたらいいと思います。 結論を先に言うと、fluent-agent-lite + fluent-plugin-file-alternative + fluent-plugi
LTSV が行指向な Key-Value フォーマットで捗る話 - naoyaのはてなダイアリー
引き続き LTSV について。Text::LTSV はやってることは単にタブの split でしょうもないのだけど、せっかく作ったんだし何か利用方法はないかなと考えた。 LTSV のログは欠点があってそのままでは見づらいこと。 Text::LTSV でハッシュになるのだから、YAML とかで出力したらどうなるか試してみよう。さらに、YAML に色づけする YAML::Tiny::Color というのがあったぞ。 #!/usr/bin/env perl use strict; use warnings; use Project::Libs; use YAML::Tiny::Color qw/Dump/; use Text::LTSV; while (<>) { my $hash = Text::LTSV->parse_line($_); print Dump $hash; } こんなスクリプ
LTSVフォーマットなログを fluentd + GrowthForecast で料理 - naoyaのはてなダイアリー
ここ数年のデータ解析の重要性の高まりから、ログに関するソリューションが方々で活発に探求されている昨今でございます。ウェブサーバーの単純なアクセスログをそのまま保存するではなく追加情報を添加してみたり、あるいはアプリケーションから直接ログを吐いてそれらをデータウェアに投げ込んで･･･というのも当然のように行うようになりましたね。 しかしあまり自由度のない access_log の combined フォーマット。さてどうしたもんか･･･ ここで id:stanaka の登場です。 Labeled Tab Separated Valueというのは、はてなで使っているログフォーマットのことで、広く使われているTSV(Tab Separated Value)フォーマットにラベルを付けて扱い易くしたものです。はてなでは、もう3年以上、このフォーマットでログを残していて、one-linerからflue
fluentdでNagiosアラートの集約 « ボーダーレスライフ
RRDなどにメトリクスを書き込んでグラフを生成している場合、標準的なサーバだとCPUかHDDがボトルネックになって、Nagiosサーバ1台あたり持てるクライアントは、300台〜700台くらいが限度といったところでしょう。 数万台のサーバを管理する様な環境では、Nagiosサーバ単位で情報が分断されてしまうので、関連するシステム（特に他部署が管理している様な）の状況が把握しづらいことがよくあります。 全サーバの状況を横断して検索、リスティングができると、障害時の対応時間を短縮できるし、統計情報の取得ができるとメトリクスdrivenな運用＆開発もしやすくなり、プロダクトの質も向上するだろうということでfluentdでやってみました。とは言ってもまだ始まったばかりなのですが、下の図の様な構成で、Nagios上のイベントログをfluentdがtailし、必要なイベントログをfluentd serv
Perl から Fluentd にログ出力 - Fluent::Logger リリース - 酒日記 はてな支店
皆さん、ログ書いてますか！？(挨拶) Fluentd meetup in Japan も開催間近、最近大変熱いイベントログ収集システム Fluentd なわけですが、Perl からログを出力する Fluent::Logger というモジュールを CPAN にリリースしたのでお知らせします。 (最初の版は id:hirose31 さんが書かれて、それに同僚の id:shin1rosei と手を加えたものです) インストールは cpanm などでどうぞ。使い方は POD にもあるように簡単です。 use Fluent::Logger; my $logger = Fluent::Logger->new( host => "127.0.0.1", port => 24224 ); $logger->post( "myapp.info" => { foo => "bar" } ); 上記の例で送信す
イベントログ収集ツール fluent リリース！ - Blog by Sadayuki Furuhashi
こんにちは。Treasure Data の古橋です^^; 先日の Treasure Data, Inc. 壮行会 で、イベントログ収集ツール fluent をリリースしました！ Fluent event collector fluent は syslogd のようなツールで、イベントログの転送や集約をするためのコンパクトなツールです。 ただ syslogd とは異なり、ログメッセージに テキストではなく JSON オブジェクト を使います。また プラグインアーキテクチャ を採用しており、ログの入力元や出力先を簡単に追加できます。 Twitterでも話題沸騰中です：イベントログ収集ツール #fluent 周りの最近の話題 背景 「ログの解析」は、Webサービスの品質向上のために非常に重要です。Apacheのアクセスログだけに限らず、アプリケーションからユーザの性別や年齢などの詳しい情報を集め
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blog.inouetakuya.info/entry/20130216/1361015295
イベントログ収集ツール #fluent 周りの最近の話題 - Togetter
http://dl.dropbox.com/u/224433/kamakura_pm_2/index.html