Vagrant を使って fluentd のクラスタリングを試す | DevelopersIO
Vagrant を使って、fluentd のクラスタリング（負荷分散とHA構成）を試してみました。 イメージはこんな感じ。 ログ受信側（log aggregators）のセットアップ ※Vagrant をインストールしてない場合は、別途インストールしてください。 2台のサーバを順番にセットアップします。 先ずは、1台目。 $ mkdir -p vagrant/server1 && cd vagrant/server1 $ vagrant box add server1 https://dl.dropbox.com/u/7225008/Vagrant/CentOS-6.3-x86_64-minimal.box $ vagrant init server1 Vagrantfile を以下のように編集します。 $ vim Vagrantfile config.vm.box = "server1"
OSS CEP Server 'Norikra' v0.0.1 released! - たごもりすメモ
みんな大好きFluentdはプラグインも自由に書けて好き放題にリアルタイム集計を行うことが可能なわけですが、やりたい処理にあわせて無限にプラグインを書き続けてるとプラグインの数が爆発し何がどんな処理をしているのかもよくわからず混乱の海に呑まれて消えるという未来がみなさんの脳裏にもおそらく想像されていることと思います。 で、世の中にはCEPエンジンというものがあってストリーム状に流れてくるイベントデータに対して処理を行う仕組みがあるわけですね。これ使いたい！ しかもあれだ、簡単に処理が書けるものがいい！ 何が言いたいかと言うとWE NEEEED xQL!!!!!!!!!!!!!!! そんなようなことをこちらのエントリを書いたときに思ったわけです。 http://tagomoris.hatenablog.com/entry/2013/02/19/142017 で、RubyKaigiにも通っちゃ
Fluentdの仕組み -バッファ機能でログ収集漏れを防ぐ- - Tech-Sketch
OSSのログ収集管理ツールFluentdを用いてログを統合管理している場合の懸念点として、ログの収集漏れが考えられます。 Fluentdでは、バッファ機能を活用することでログを収集漏れすることなく確実に収集することができます。 このバッファ機能のメカニズムを理解すべく動作検証した結果を紹介します。対象とするFluentdのバージョンは0.10.30です。 Fluentdとは Ruby実装のOSSのログ収集管理ツールです。 Fluentdは、Input、Buffer、Outputの3つのコンポーネントで実現されています。 様々な場所からログを収集、JSON形式に変換し(Input)、蓄積(Buffer)、様々な出力先にデータ出力(Output)します。 例として、あるサーバ(server01)のApacheのアクセスログを別のサーバ(server02)内にファイルとして出力する場合
「fluentd」と「Storm」の比較について - Tous Les Jours 攻防記
まず、両者はかなり性質の異なるプロダクトなので、以下の比較は筋違い。 筋違いであることを前提に、ストリームデータ処理プラットフォームとしての両者を比べてみる。 基本情報 fluentd http://fluentd.org/ 今をときめくログコレクター/イベントアグリゲーター。Rubyで実装されているが軽量高速。 RPC基盤ではなく、その下のレイヤーに位置するプロダクト。 Storm http://storm-project.net/ 分散RPC基盤。ストリームデータ版MapReduce風フレームワーク。Java+Clojureで実装されている。 概要については、下記のスライドがとてもわかりやすかった。 Twitterのリアルタイム分散処理システム「Storm」入門 ストリームデータ処理で何をするのかについて ストリームデータ処理のニーズについて、自分が理解している範囲での簡単な説明。 典
Treasure Data - naoyaのはてなダイアリー
少し前にログの話を書いた http://d.hatena.ne.jp/naoya/20130219/1361262854 ときに、Treasure Data については後日にもう少し詳細に書くと言ったので書くとしよう。 近頃 Treasure Data (以下、時折 TD) という名前をちらほら聞いたことがある人は多いのではないかと思います。「ビッグデータのクラウドサービスである」とか「日本人が創業したシリコンバレーのベンチャー」、あるいは Yahoo! 創業者の Jerry Yang が投資したとか、Fluentd と何か関係があるといった文脈などなど。 けど、具体的に Treasure Data がどういうサービスで、どういう機能を持っていて、どんな場面で利用されるものなのかはまだあまり良く知られていないかもしれない･･･ようにも見える。今日はその辺から少し紹介していこうかなと思う。
AWSを使ったデータ解析PaaSの裏側 - Go ahead!
JAWS DAYS 2013というイベントがあって，2日目にTreasure Dataとして発表してきました．実は1日目には弊社CTOがパネルディスカッションに登壇したりしてました． Slideshare Ustream Video streaming by Ustream 最初はfrsyukiが登壇予定に上がっていたんだけど，今彼はアメリカということで代打で役割が回ってきた，というのが発表の経緯． なんかラベルが”Dev”と”Ops”という超大雑把なくくりで「AWSで”Dev”って何発表すれば…」という状態だったので， AWS上で展開しているTreasure Dataサービスの仕組みについてつらつらと話しました． AWSべったりな感じではなくて Treasure Dataのサービス内容と目的 どうAWSのプロダクトを使っているのか なぜこのAWSのサービスを使わないのか というのを大まか
FluentdとGrowthForecastを使って自分の行動をロギング・可視化する - すぎゃーんメモ
おそらくはそれさえも平凡な日々: もにかじでオレオレ監視ツールについて話してきました GrowthForecast.plで自分ロギングしてみた - by edvakf in hatena の記事のように、FluentdやGrowthForecastを使ったロギングって面白そうだなーと思って自分でもやってみた。 アプリケーション毎のアクティブな時間を取る まず考えたのはこれ。キーイベント発火回数ほど細かくなくても、「アクティブにしている時間の割合」が取れたらそれはそれで良いかな、と。 1秒ごとにアクティブなアプリを調べてロギングしていく。Mac OS Xにおいてアクティブなアプリケーションを調べるならAppleScriptが簡単。 name of (info for (path to frontmost application)) これだけでアクティブにしているアプリケーション名が取れる。
#monitoringcasual vol3 に参加してきました · さよならインターネット
March 9, 2013 Monitoring Casual Talk #3に参加してきました。 会場をご提供頂いた株式会社paperboy&co.さま @ume3_さん、@tnmtさん、@lamanotramaさん、ありがとうございました。 会場へ向かう途中で、fujiwaraさんとsongmuさんが 今日はmizzyさんいないからイケるかもしれないとか物騒なこと言ってて怖かったです。 セルリアンタワー、曜日の夜にBARになるところがすごくて 入り口にイケイケのおねーさんいたりして華やかや〜！！！ってなっていました。 発表内容 発表資料はこんな感じです。 出発する30分前につくったのでそんなに大したものではないです。 一枚目は 「*RDSのメトリクスをCloudWatchからfluentdへ、slow_logを添えて*」 って書いてあります。 フレンチっぽくしたかったんですけどただの読
おそらくはそれさえも平凡な日々: もにかじでオレオレ監視ツールについて話してきました
オレ自身を監視するツールって話なんだけどな！発表資料は以下。 オレオレ監視ツール 自分が触っているアプリケーションでのタイプ数を可視化するツールです。 なんか手元のMacにGrowthforecastが簡単に入らなかったのでカッとなって VPS上に構築しました。これで僕の行動が世界中からまるわかりです！ 3/11追記 手元にHRForecast立ててそれで代用したのでURL消しました 適当に設定したら偶然にも調度良く赤系(iTerm,Macvim)が仕事、緑系(Chrome, Limechat) がサボり系になりました。Limechatがちゃんとライム色になっているのが素晴らしいですね。 仕組みとしてはごく単純で以下のような感じ。 KeyRemap4MacBookをdebugをONにしてキーイベントをログ出力 Slateでアプリの切り替えを検知してそれをログ出力 それらのログをtailで読
RRDtoolのPrediction - PolyPeaceLight
RRDtoolでも異常検知機能が備わっているので、とりあえず勉強のために翻訳しておく。 Aberrant Behavior Detection with Holt-Winters Forecasting RRDtoolでは、Holt-Wintersの指数平滑化法を使ってるぽい。 そういえば、@kzk_moverも .@muddydixonさんのfluent-plugin-anomalydetectに触発されて、未来の値評価機を作り始めた… > URL 2013-01-28 02:14:05 via YoruFukurou とかいって、こんなのを作ってる (paperはこちら )。 翻訳は以下 Holt-Winters 予測での異常振舞検知 アグリゲート関数に加えて、RRDtoolでも、データの平滑化(Holt-Winters 予測アルゴリズム)、信頼区間、時系列データソース中の異常振舞にフ
fluentd + mongodb+ node.js でリアルタイムにグラフを描く - stanaka's blog
追記 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
開発メモ#6 : ログの取り扱い : GrowthForecast, Amazon S3, Treasure Data で心労ゼロ - naoyaのはてなダイアリー
開発メモ#6 です。前回から少し間があいてしまいました。 開発メモ#2 : AWS でのホスト / クラウドネイティブなデプロイ - naoyaのはてなダイアリー で書いたように、EC2 へのアプリケーションのデプロイにあたっては Elastic IP の利点を活かしてカジュアルにホストを入れ替えまくっています。ちょっとこのデプロイは慎重になりたいな、と思ったらスナップショットからインスタンスを立ち上げては切り替える、の繰り返し。 この運用をしていると、スナップショットとの差分ができやすいのは chef-solo で吸収するというのが前回、前々回のはなし。 もう一点問題があります。アクセスログやアプリケーションのログです。フロントエンドのサーバをあっちこっち切り替えているうちに、そのままではログが分断されてしまう。ホストを Terminate しようものならログは消失してしまいます。 この
Fluentd::Integration: Utilities for Integration Test against Real Fluentd Processes - Kentaro Kuribayashi's blog
As all users of fluentd know, it's difficult to test your configurations work well with real fluentd process. Besides, through multiple fluentd processes, it becomes much more. Fluentd::Integration provides some utilities to help you test your fluentd configurations. https://github.com/kentaro/fluentd-integration You can simply write Ruby script to setup fluentd and throw some data into it like be
#fluentd Casual Talks #2 やってきた＆fluent-plugin-secure-forwardの話 - たごもりすメモ
なんとなく気分が盛り上がったところで会場も見付かったのでカジュアルに企画して開催してまいりました。 Fluentd Casual Talks #2 : ATND いつもながら大人数の入る設備完璧な会場を貸していただき、また受付などすばらしいご協力を:DeNA様にいただきました。ありがとうございました！ で、大入りでしたね。発表者だれも決まってなかったのに……ｗ 話すほうも何も事前調整無し、talk完璧に未決定の状態から募集を開始したのに、最終的に面白い発表者、というか豪華メンバーがずらっと並びました。ありがとうございました。 どの話も大変面白かったですが、特に fluentd + esper でストリームに対してクエリを投げるというのがもう、まさにやりたいことというか弊社のIssue Trackerにも項目があってですね、あれを全部rubygemsにパッケージできると夢のCEPエンジン o
My Presentation at #fluentd Casual Talk 2: Log Everything with Fluentd - Kentaro Kuribayashi's blog
At Fluentd Casual Talk #2 held today, I gave a presentation titled "Log Everything with Fluentd". It's based on my work for Puboo, an e-book publishing service. I couldn't use fluent-logger-php, but it eventually was good fo me. As I wrote in the slides above, I could hack up some useful modules as a result. I think the plugins can help you. Give a try to it. I appear from 14:35 in the movie below
走れfluentd | quipped
fluentdというソフトウェアがある。読者の多くは聞いたこともないソフトウェアだろう。そりゃそうだ。AndroidとかiOSとかWindowsのように、消費者の目に毎日さらされるものとは違い、日夜静かにデータセンターで動いているソフトウェアだ。 このfluentdは、もともと古橋貞之くんが、自分がはじめた会社のサービスの一部で必要となり書いたものだが、この1年半ほどで瞬く間に広まり、今では日本中のウェブサービスで導入されている。どのくらい広まっているのかと言うと、もし読者が今日 はてブをチェックしたり クックパッドでレシピを探したり NAVERまとめを見てゲラゲラ笑ったり GREEのサービスで遊んだり ライブドアニュースで蒼井優の動向を探ったり1 したなら、どこかでfluentdの恩恵を受けているということになる。 ちなみにこの古橋くん、ゆとり世代のダメダメなピチピチな25歳の若者で、ど
Fluentdで始めるリアルタイムでのログ有効活用
はじめに Fluentdは、ログを収集し格納するためのログ収集基盤ソフトウェアです。Fluentdにインプットされた、すべてのログをJSONに変換し、アウトプットします。インプットとアウトプットはモジュール化されており、モジュールを追加することでインプット元とアウトプット先を追加できるようになっています。 Fluentdは急速に知名度を高め、多くのWebサービス会社で実際に使用されるようになりました。従来のログが抱えていた問題も、Fluentdが適切な解決策となっていると認知され、かつ簡単に導入・スモールスタートできるミドルウェアであったことが大きかったと思います。 本稿では、Fluentdの簡単な仕組みと導入方法、シンプルな動作事例について紹介します。 対象読者 システム管理者 データサイエンティスト 必要な環境 UNIX系OS Ruby 1.9 ログを出力する理由 システム運用を始める
fluent-plugin-parser supports LTSV! - たごもりすメモ
乗るしかない、このビッグウェーブに！ Labeled Tab Separated Values (LTSV) ノススメ - stanaka's blog LTSVフォーマットなログを fluentd + GrowthForecast で料理 - naoyaのはてなダイアリー Text::LTSV - naoyaのはてなダイアリー LTSV が行指向な Key-Value フォーマットで捗る話 - naoyaのはてなダイアリー ということで fluent-plugin-parser で 'format ltsv' をサポートし v0.2.0 としてリリースいたしました。 fluent-plugin-parser | RubyGems.org | your community gem host tagomoris/fluent-plugin-parser · GitHub あるキーがLTSVな
LTSVフォーマットなログを fluentd + GrowthForecast で料理 - naoyaのはてなダイアリー
ここ数年のデータ解析の重要性の高まりから、ログに関するソリューションが方々で活発に探求されている昨今でございます。ウェブサーバーの単純なアクセスログをそのまま保存するではなく追加情報を添加してみたり、あるいはアプリケーションから直接ログを吐いてそれらをデータウェアに投げ込んで･･･というのも当然のように行うようになりましたね。 しかしあまり自由度のない access_log の combined フォーマット。さてどうしたもんか･･･ ここで id:stanaka の登場です。 Labeled Tab Separated Valueというのは、はてなで使っているログフォーマットのことで、広く使われているTSV(Tab Separated Value)フォーマットにラベルを付けて扱い易くしたものです。はてなでは、もう3年以上、このフォーマットでログを残していて、one-linerからflue
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - kentaro/fluent-plugin-extract_query_params
