沖縄Ruby会議01発表「Rubyによるバッチ業務のストリーム処理化の設計と実装」 http://regional.rubykaigi.org/okrk01/
最近、Fluentd + ElasticSearch + Kibana 3 の構成でお試し運用を始めました。 すると下記のような事をやりたくなったが Apache アクセスログをURL毎に集計したい DB スロークエリログをクエリ毎に集計したい 単純に文字列のフィールドで pie/bar チャートなどを利用すると、期待を打ち砕かれる(打ち砕かれた) ふむふむ、遅いクエリーには select, where, from が多いのか.... orz 見事に単語毎に集計されてしまった。 どうもトークナイズを止めるには ElasticSearch の multi field を利用するのが良さそう。(Solr で言うと copy field?) fluentd + ElasticSearch + Kibana + logstash フォーマットを下記の構成で利用する場合 fluentd のタグは m
Github: GitHub - bash0C7/fluent-plugin-dashing: Fluentd output plugin to post data to dashing rubygems: fluent-plugin-dashing | RubyGems.org | your community gem host いつものように、fluent-gemからインストールください。 Dashingとは see: Dashing - The exceptionally handsome dashboard framework. そういえば[ruby][dashing]Dashingを使って簡単きれいなダッシュボード - こしば技術にっき(2012-11-24)なエントリーも書いていたのでした。 やってること http://shopify.github.io/dashing/#da
ゴクロの大平です。ごくろうさまです。 Redisは高速で、かつデータの永続化や、複数のデータ型によるストア(list,set,sorted set等)も対応しており、機能的が豊富ということから愛用者の多いKVS実装の一つだと思います。 特に私のようなアプリケーションエンジニアの人間にとってはデータ型のバリエーションの豊富さが便利さを感じる部分で、たとえばlistを用いてタイムライン的な情報や履歴情報の管理、sorted setを用いてランキング情報の管理、などのようにアプリケーションの需要の多くにRedisが対応することができます。 これらの情報を登録する際のフローとしては自作のアプリケーションから直接、というケースが多いと思いますが、せっかくFluentdのような便利なlog collector実装があるので、FluentdとRedisを組み合わせる事でカジュアルに情報の蓄積を行いたい
OSSのログ収集管理ツールFluentdを用いてログを統合管理している場合の懸念点として、ログの収集漏れが考えられます。 Fluentdでは、バッファ機能を活用することでログを収集漏れすることなく確実に収集することができます。 このバッファ機能のメカニズムを理解すべく動作検証した結果を紹介します。対象とするFluentdのバージョンは0.10.30です。 Fluentdとは Ruby実装のOSSのログ収集管理ツールです。 Fluentdは、Input、Buffer、Outputの3つのコンポーネントで実現されています。 様々な場所からログを収集、JSON形式に変換し(Input)、蓄積(Buffer)、様々な出力先にデータ出力(Output)します。 例として、あるサーバ(server01)のApacheのアクセスログを別のサーバ(server02)内にファイルとして出力する場合
まず、両者はかなり性質の異なるプロダクトなので、以下の比較は筋違い。 筋違いであることを前提に、ストリームデータ処理プラットフォームとしての両者を比べてみる。 基本情報 fluentd http://fluentd.org/ 今をときめくログコレクター/イベントアグリゲーター。Rubyで実装されているが軽量高速。 RPC基盤ではなく、その下のレイヤーに位置するプロダクト。 Storm http://storm-project.net/ 分散RPC基盤。ストリームデータ版MapReduce風フレームワーク。Java+Clojureで実装されている。 概要については、下記のスライドがとてもわかりやすかった。 Twitterのリアルタイム分散処理システム「Storm」入門 ストリームデータ処理で何をするのかについて ストリームデータ処理のニーズについて、自分が理解している範囲での簡単な説明。 典
追記 2/22 毎回微妙に追記していますが、今回も追記です。最後にmongodbのinsert性能について80lines/secで厳しくなった、と書いてますが、環境か設定まわりがあやしいので訂正します。もうすこし検証してみようと思います。 → 検証して fluentd側の設定の問題であることが分かりました。詳しくは、http://blog.stanaka.org/entry/2013/02/22/171053 追記ここまで 最近は、fluentd + mongodb でログを蓄積していろいろ便利に使っているわけですが、数分に一回集計スクリプトを周したり、 GrowthForecast の画面をリロードしまくるのではなく、もっとリアルタイムで見たい! という欲求が募ってきたので、 node.js を使って実装してみました。( https://github.com/stanaka/realti
fluentdというソフトウェアがある。読者の多くは聞いたこともないソフトウェアだろう。そりゃそうだ。AndroidとかiOSとかWindowsのように、消費者の目に毎日さらされるものとは違い、日夜静かにデータセンターで動いているソフトウェアだ。 このfluentdは、もともと古橋貞之くんが、自分がはじめた会社のサービスの一部で必要となり書いたものだが、この1年半ほどで瞬く間に広まり、今では日本中のウェブサービスで導入されている。どのくらい広まっているのかと言うと、もし読者が今日 はてブをチェックしたり クックパッドでレシピを探したり NAVERまとめを見てゲラゲラ笑ったり GREEのサービスで遊んだり ライブドアニュースで蒼井優の動向を探ったり1 したなら、どこかでfluentdの恩恵を受けているということになる。 ちなみにこの古橋くん、ゆとり世代のダメダメなピチピチな25歳の若者で、ど
fluentdのプラグインを書く練習をする為にsecureログをparseしてZabbixで値が取得できるようにしてみた(作成編) January 20, 2013 https://github.com/kenjiskywalker/fluent-plugin-securelog-parser ,j;;;;;j,. ---一、 ` ―--‐、_ l;;;;;; {;;;;;;ゝ T辷iフ i f'辷jァ !i;;;;; 全く触ったことがなくてもpluginを書いたらfluentdがわかる ヾ;;;ハ ノ .::!lリ;;r゙ `Z;i 〈.,_..,. ノ;;;;;;;;> そんなふうに考えていた時期が ,;ぇハ、 、_,.ー-、_',. ,f゙: Y;;f. 俺にもありました ~''戈ヽ `二´ r'´:::. `! 最初Postfixのmaillogつくってやろうかなんて 思っていたり
fluentdのプラグインを書く練習をする為にsecureログをparseしてZabbixで値が取得できるようにしてみた(設定編) January 20, 2013 https://github.com/kenjiskywalker/fluent-plugin-securelog-parser ,j;;;;;j,. ---一、 ` ―--‐、_ l;;;;;; {;;;;;;ゝ T辷iフ i f'辷jァ !i;;;;; 全く触ったことがなくてもpluginを書いたらfluentdがわかる ヾ;;;ハ ノ .::!lリ;;r゙ `Z;i 〈.,_..,. ノ;;;;;;;;> そんなふうに考えていた時期が ,;ぇハ、 、_,.ー-、_',. ,f゙: Y;;f. 俺にもありました ~''戈ヽ `二´ r'´:::. `! 最初Postfixのmaillogつくってやろうかなんて 思っていたり
前編の続き。 続きとはいってもGrowthforecastの複合グラフを作るスクリプト書いたっていうだけの記事です。 スクレイピングでがんばった!w 書き捨てもいいところですね… config.yaml 先ほどのdstatの複合グラフを作りたい時はこんなかんじでしょうか --- host: localhost:5009 complex: - name: cpu_complex regex: ^cpu - name: disk_complex regex: ^dsk - name: io_complex regex: ^io - name: load_avalage_complex regex: ^la - name: mem_complex regex: ^mem - name: net_complex regex: ^net スクリプト実行 以下のコマンドを叩くと自動で生成されます。 p
Agent ログの量やFluentd&CPUの性能を考えると、負荷的には1サーバ1Agentで十分足りるので、ステータス検知などの監視だけしっかりしておけばOKと考えます。なので例えばWEBサーバに普通に1Agent入れてそれが数百・数千台になることを想定します。 Collector 複数台用意し、Agentからroundrobinで送信することで均一化します。Collectorダウン時や復旧時は、ログのロスト無しにすみやかにroundrobinから外れたり復活することを確認済みです。台数が増えすぎた時の懸念点は、HDFSに対する1ファイルへのAPPEND数が増えることですが、ここまでの試験を見る限りはおそらくかなりの数まで大丈夫ですし、仮にHDFSへの書き込みが問題になる場合はAgent -> Collectorの選択条件や、書き込みファイルパスで工夫すれば大丈夫です。 とはいえ、APP
今日は Fluentd meetup in Japan >http://www.zusaar.com/event/193104 に参加してきました。 そのメモを少し書き換えて、感想を書かせていただきます。 ※かなり雑ですみません。 ※あと私のフィルタがかかってしまい、メモし切れていない箇所が多分にあります。 ご容赦ください。。。 ====================================================== 「What's Fluentd? - The missing log collector」 http://www.slideshare.net/treasure-data/fluentd-meetup-in-japan-11410514 Treasure Data, Inc. 古橋 貞之 (@frsyuki) =======================
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く