Fluentdとはどのようなソフトウェアなのか - たごもりすメモ
Fluentd というソフトウェアがある。日本国内ではそこそこ話題になってきたが、何ができるのか、何に使うと嬉しいのか、何に使えるのか、という点について詳細をよく知らないという人もおそらくまだ多いことでしょう。 なので、簡単にまとめる。 http://fluentd.org/ なお以下の個別項目ごとに書いていくが、その手前にまとめを置いておくので忙しい人はそれだけ読むとよい。インストールや設定については導入部分については日本語の記事はもう多くあるので、触れない。 概要 できること ログの収集 センサデータ等の収集 汎用データ処理プロセッサとして 頻出ユースケース ログの収集 データの集約 簡単なリアルタイム集計 ソフトウェアとしての特徴 コア プラグイン 安定性 性能 開発体制 コミュニティ ぶっちゃけどうなの？ まとめ 現時点で、複数の場所に分散したデータや常に増え続けるデータの安全な転
ruby 2.0.0-p195 + fluentd v0.10.35 + msgpack v0.5.5 の組合せが素敵という話 - たごもりすメモ
fluentd v0.10.35 が出ましたね！ https://rubygems.org/gems/fluentd で、端的に申し上げまして fluentd をお使いの皆様は以下の組合せで使うのがおススメです。 Ruby 2.0.0-p195 Fluentd v0.10.35 MessagePack v0.5.5 なぜかというと以下のようなすばらしい利点があるからですね。 Ruby 2.0.0 でfluentdを走らせると大変高速 2.0.0 は each とかを回すときに非常に高速になるような改良が入っている 1.9.3 向けには funny-falcon patch として知られていたもの rvm を使ってビルドしていたrubyだと知らずに当たってるかも これが大量のメッセージに対してループが回りつづけるFluentdに超ハマる 手元計測で生の 1.9.3 の倍ちょっと高速 Ruby
Fluentd v0.11 の設計案、について - たごもりすメモ
このエントリは以下の記事およびFluentdの現状を受けてのものであり、Fluentdの実装についての知識を前提とします。 Fluentd v0.11 の設計案 — Gist また言うまでもないことですが、自分の使いかただったらこうだといいなー、という程度のものであり、それ以上の意味もそれ以下の意味もありません。 では順にいってみよう。 内部ルーティングラベルの導入 実際にはこれだけでは問題は解決しなくて、forward先のFluentdで、forward元のFluentdではどこまで処理をやったメッセージなのか、ということを知る必要がある場合があるので、結局タグの操作もする必要がある。そうするとラベルの操作で解決するケースとタグの操作も行われているケースが混在することになり、状況はむしろ悪くなる。 じゃあどうするかというと悩ましいけど。じつは個人的には現行 v0.10 のタグ操作 + o
Fluentd Casual Talks 開催してきた＆しゃべってきた - たごもりすメモ
なんとなく思い付いたら各所の協力を得られましたので、そのまま開催してしまいました。 勉強会を主催するのは初めて*1だったのですが、会場をお貸しいただいた株式会社ディー・エヌ・エー様、ならびに当日運営をまるっとお手伝いいただいた @riywo さんをはじめDeNA社員の皆様のおかげで全く問題なく、すばらしいイベントになりました。本当にありがとうございました。 またUstream中継については @ixixi さんにご協力をいただきました。たいへんな作業だと思いますが、本当にありがとうございました。 Fluentd Casual Talks : ATND 金曜夜に100人を超える参加者が見事に集まりまして*2、Fluentdを実際に使ってみた系の人々が大いにしゃべってました。個人的にはあれやこれやと面白い話がたくさん聞けたので、それだけでもう満足。SDのFluentd特集との内容のカブりについて
fluent-plugin-forest released! - たごもりすメモ
現状のfluentdでは、タグを動的に扱う方法がいまいち無い。具体的に言うと設定項目にタグに応じて変化するような指定をしたい場合、タグごとに分けて書くしかない。例えば out_file で出力先ファイル名をタグに応じてつけたい場合、タグの数だけ match 節を書く必要がある。 <match hoge> type file path /var/log/hoge.log </match> <match pos> type pos path /var/log/pos.log </match> # 以下いっぱいこれには極めて簡単にわかる範囲で、ふたつの大きな問題がある。 多数のタグを扱う場合、設定ファイル全体のボリュームが肥大化して管理コストが増大する(品質が低下する) 新しく扱うタグが増える場合、設定ファイルの更新と適用が必要となり、管理コストが増大する 既に手元でこの問題に悩まされていて、H
続 #fluentd の性能・リソースに関する最近のいくつかの傾向の話 - たごもりすメモ
前回の話から、メモリについては西海岸方面の協力を得てあれこれ試していた。 #fluentd の性能・リソースに関する最近のいくつかの傾向の話 - tagomorisのメモ置き場 最終的には ruby 1.9.3-p125 + jemalloc + fluentd v0.10.16 でメモリ使用量が安定した。 jemallocについてはこのあたりを読むといいんじゃないでしょうか(自分で説明するのはめんどくさいｗ) jemallocとかLD_PRELOADについて調べてみた - As a Futurist... 結果、ピーク時間帯になっても used 6GB に行かないくらい。ワーイヤッタヨー。 ということでjemallocは社内用rpm*1を用意し fluentd 起動用のshファイル(supervisordからこれを指定して起動している)を以下のようにした。LD_PRELOADを加えただけ
#fluentd の性能・リソースに関する最近のいくつかの傾向の話 - たごもりすメモ
いくつかそれぞれ違う内容のことについて書きます。また複数の変更をほぼ同時期にやったケースもあり「お前それ分けてやれよ」と言いたくものがあるかもしれません。いや分かってはいるんだけど、そうそう変更ばっかりもしてられないからまとめてやりたいじゃんよ。 前提ですが、今回出てくるサーバはすべて、fluentdのみを8プロセスずつ起動している物理サーバです。fluentd meetupのときに「deliverサーバ」として紹介したやつ。各Webサーバからログを受け、アーカイブサーバにscribeプロトコルで送ると同時にロードバランスしてログ変換サーバに forward で送る配送サーバ。out_forwardのインスタンスが57あります。 ruby 1.9.2 -> 1.9.3 にした 前々から全くトラフィックの流れていないスタンバイ用のサーバでもメモリの使用量が徐々に上がっていって定期的な再起動が
#fluentd 用ログ収集専用のエージェント fluent-agent-lite 書いた - たごもりすメモ
みんな大好きfluentdはたいへん便利ですが、ログの収集＆集約だけをしたい、というときにちょっとオーバースペック気味のところがあります。特に in_tail はログの読み込みと同時に parse をする仕組みになっており、まあログが書かれた場所ならparseのルールもわかってるでしょ、というところは合理的なものでもあるのですが、loadavgが高いサーバでそういうことをするのは正直にいってなかなか厳しいです。 そういうわけで以前に scribeline というエージェントツールを作ったのでこれを fluentd 以降後も使い続けていたのですが、ログをいったん集約するところの fluentd がCPU使用率的にいっぱいいっぱいになって厳しいものがありました。「scribe(Thrift)じゃなくてMessagePackにすれば倍くらいさばけるよ」ということを某開発者が言っていたような気もす
#fluentd のためのプラグインをイチから書く手順(bundler版) - tagomorisのメモ置き場
前に自分で書いた fluentdのためのプラグインをイチから書く手順 - tagomorisのメモ置き場 はたいへん重宝していたのだが、書いたすこし後になって実は現在すでに bundle gem コマンドを使うやりかたが良さそうだということがわかってしまったがばたばたしてて移行してなかった。 で、またひとつプラグインを書くことにしたのでついでに bundle を使った手順をざっくりまとめておく。以下のエントリをたいへん参考にさせてもらった。 T-POINTを取得するスクリプトをGistから移動, Bundlerを使ったGem作成メモ (自分用) - ただのにっき(2012-02-18) 準備とディレクトリツリーの作成 bundler は必要なので、なにはなくとも入れておこう。 gem install bundler そしてプラグイン用ディレクトリツリーを作成する。今回は DataCount
#fluentd な今だからこそふりかえる scribed のすべて - たごもりすメモ
最近 fluentd というツールのことがたいへんよく話題に上がっており、かく言う自分もささやかながら使用している身なのだが、それはそれとして比較対象に上がってくるツールに scribed というものがある。これがどういうものなのか、話には聞いていてもよくは知らないという人が多いようなので、これもささやかながら触ってみている自分としてはここらで一度まとめておかねばなるまい、と思った次第である。 日本全国に10人くらいはいるかもしれない scribed のヘビーユーザ各位に捧げる。 なお記憶と経験だけを頼りに書き殴るので、意思決定の重要な局面とかで「これこれこういうブログにたごもりすなる者がこのようなことを書き残しており」などと引用するのはくれぐれも避けていただきたい。 また途中から思いっきりビール飲みながら書いたので文章自体の品質にも問題のある可能性がある。 そも scribed とは何か
Hoop(httpfs)とwebhdfsの違い - たごもりすメモ
Hadoop 1.0.0がリリースされた。まあ中身のほとんどはただの 0.20.x 安定板リリースなので特別に言うことはないんだけど。詳しくは以下のblogを読むのがよろしい。 hadoopのバージョン表記について - 科学と非科学の迷宮 ただしひとつだけびっくりしたのは、webhdfsなる機能が入ってきたこと。(このblogでよく話題にしている)Hoopと並んでそんなようなものがあること自体は知ってたけどあんまり興味なかったのだが、Apache Hadoopのパッケージに(Hoopより先に)入ったとなるとちょっと注目せざるをえない。 が、httpfs(Hoop)とwebhdfsじゃ名前も似てて超まぎらわしい。いったい何がなんなの。 なお自分はWebHDFSはAPIリファレンスを読んだだけで、実際にはカケラも触っていない。その状況での理解による内容なので、注意して読んでください。 先に結論
fluent-plugin-hoop v0.1.0 released - たごもりすメモ
みんな大好き fluentd は素敵だと思うんだけどHDFSへの書き出しをするプラグインが無い！ なんで！ という全世界100万人のエンジニアの怨嗟の声が聞こえてきそうだったので、とりあえずどうにかするべく書いた fluent-plugin-hoop がだいたい動くようになったのでリリースした！ fluent-plugin-hoop | RubyGems.org | your community gem host tagomoris/fluent-plugin-hoop · GitHub → 公式リポジトリの仲間入りしました fluent/fluent-plugin-hoop · GitHub rubygems.org経由でリリースしてあるので gem install fluent-plugin-hoop で入ります。あとはなんだっけ、システム全体の環境に影響を与えたくなければ fluen
fluentd のベンチマークとってみたよ！ - たごもりすメモ
入出力プラグインをrubyで書けるのがじつにいい感じの fluentd がいい感じに見える。 fluent/fluentd · GitHub ので使えるかどうか、使えるとしたらどれくらいのノードを用意すればいいのかについて考えるため、とりあえずベンチマークをとってみた。 結論 以下非常に長くなるので結論だけ書くと、大変使える感じ。現状だとほとんど何も考えずにデータ中継させても秒間1万メッセージ、100Mbpsくらいまでは処理できる。効率よくなるよう流す側も考えてやれば 300Mbps を超えるデータの転送に成功した。だいぶいい感じ。 なおこれは in_scribe および out_scribe を使用した場合で、開発者 @frsyuki によるとMessagePackでのデータ転送の場合はこの倍くらい出るらしい。 もちろんこれは右から左に流しただけなので現実にタグによるルーティングだとかロ
fluentdのためのプラグインをイチから書く手順 - たごもりすメモ
(2012/02/21追記: bundle gem して作成する手順をこっちに書いた http://d.hatena.ne.jp/tagomoris/20120221/1329815126 ) fluentdがいい感じでパフォーマンスにも問題ない状況になってきたように見えるので、よっしゃいっちょプラグインでも書くか！ と思ったもののリポジトリをgithubに作ったはいいがコード書いてテストしてgemとしてリリースするまでには様々にめんどくさいことがあり gem とか作ったことない自分*1には摩訶不思議なあれやこれやが広がっていてコード書くところに辿りつくまでが長過ぎるというか、端的に言ってあちこちに散在する情報を集めるのに必要な時間とともにやる気がとめどなく流出していってもうだめだという気分になる。 というような主旨のtweetをしてみたもののどうにかなるわけでもないので、試行錯誤しながら
Hoopの性能を確認してみたらもうlibhdfsとかオワコンでHoop使えって結果になった - たごもりすメモ
前に書いた エントリ の通りHoopが有望な感じだったんだけどどのくらいの性能が出るのか見てみないことには本番投入して性能出ませんでした乙、ということになりかねない。ので見てみた。 なお検証に関係する環境としては以下の通り。ちなみに前はCDH3u1で試してたけど、今回はCDH3u2 (JDK6u29) on CentOS5。メモリが問題になることは全くないので全て省略。 ベンチ用サーバ Intel Xeon 4Core HT 2.4GHz データ中継サーバ (deliver) Intel Xeon 4Core HT 2.4GHz Hadoop NameNode (+JobTracker) (namenode) Intel Xeon 1Core HT 3.16GHz Hadoop DataNode + TaskTracker x9 Intel Xeon 1Core HT 3.16GHz Ho
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
