fluentd v1 configのチェッカを作った - たごもりすメモ
tagomoris/fluentd-v1-checker · GitHub fluentd-v1-checker | RubyGems.org | your community gem host Fluentdの設定ファイルについてはv1 config という新書式がある。v0.14からはデフォルトでこちらの書式でパースが行われる予定。 ここに @repeatedly さんが書いてるけど、今のうちから v1 config で書いて --use-v1-config しておくと将来的に困らなくてよいと思う。書式的にも綺麗になっているはず。 ところで v1 config といってもいろいろな経緯から、これまでの書式の設定ファイルをぶちこんでもなんとなくパースできるようになっている。値に # とかを含めたいとかでなければ設定を変更しなくても通る場合も多い。 「場合も多い」これが困る。起動してみて動
業務とオープンソース活動の話 (日本OSS奨励賞 受賞報告にかえて) - たごもりすメモ
先日書いたエントリでも触れたけど、日本OSS奨励賞、というものをいただくことになりました。ご推薦いただいた方がいるということで、本当にありがとうございます。 「第9回 日本OSS貢献者賞・日本OSS奨励賞」受賞者を選定 | 日本OSS推進フォーラム で、せっかくの機会だし、普段思っていることを書いておこうと思う。この内容はほとんど将来の自分に対する自戒だ。アレな内容になることを申し上げておきます。先日に引き続いてアレですが、まあせっかくの機会なんですよ。ねえ。 ちなみに、ちょー長くなりました。あっはっは。 業務としてのオープンソース活動 自分はフルタイムのオープンソースコミッタではない。オープンソース活動に貢献すること、などという文言は自分の業務内容にはひと言も含まれていないし、自分が所属する部署の目標にも無い。自分の業務はあくまで自社サービスに貢献すること、自社サービスの開発および運用を
tagomorisとDMM.comのはなし - たごもりすメモ
前にこんなblogエントリを書いた。 dmmのエンジニアと話をしてみたいという話(追記あり) - たごもりすメモ このエントリ、Cassandra Casualという勉強会でCassandraのようなそうでないような話を聞きながら、しかもビール2本飲んだ状態で書いたものだった。書いてさっさと公開して放っておいた*1ところ、だいぶ経ってはてブがやたらとついていることにびっくりしたものだった。 正直に言おう。対象はなんでもよかったんだ。世間に知られている大規模インターネットサービスを運営していて、会社としての・中の人としての雑誌記事やイベント登壇やblogエントリがあまり見られない企業であれば。DMMでなくても、たとえばFC2でも楽天でもNTT docomoでもY!Jでもドワンゴでも。 もちろんどんな会社の人でも行くべきところに行けば中の人がいるのは知っているけれども、そういう話じゃない。単に
OSS CEP Server 'Norikra' v0.0.1 released! - たごもりすメモ
みんな大好きFluentdはプラグインも自由に書けて好き放題にリアルタイム集計を行うことが可能なわけですが、やりたい処理にあわせて無限にプラグインを書き続けてるとプラグインの数が爆発し何がどんな処理をしているのかもよくわからず混乱の海に呑まれて消えるという未来がみなさんの脳裏にもおそらく想像されていることと思います。 で、世の中にはCEPエンジンというものがあってストリーム状に流れてくるイベントデータに対して処理を行う仕組みがあるわけですね。これ使いたい！ しかもあれだ、簡単に処理が書けるものがいい！ 何が言いたいかと言うとWE NEEEED xQL!!!!!!!!!!!!!!! そんなようなことをこちらのエントリを書いたときに思ったわけです。 http://tagomoris.hatenablog.com/entry/2013/02/19/142017 で、RubyKaigiにも通っちゃ
fluent-plugin-esper構想概略 - たごもりすメモ
Fluentd Casual Talks #2 で聞いた fluentd + esper によるCEP実現の話が非常に素敵な感じで、自分の手元でもああいう感じで書きやすく投入しやすいストリームクエリがやりたくてしょうがないお年頃なので、以下のようなものを作ろうかと考えている。勢いあまって(まだ1バイトも書いてないのに) the RubyKaigi 2013 のCFPにsubmitしてしまった。通ったら何がなんでも2ヶ月くらいで書いて動かさないといけない。 ということで以下のようなものを作ろうかと考えている。この内容は Fluentd Casual Talks #2 の懇親会でFluentdコミッタ陣と @angostura11 さんとで頭をつきあわせてゴニョゴニョ話していた内容で、100%自分で考えたものでないことは最初に記しておく。だいたいそもそものアイデアは @angostura11
2012年を振り返ってみる - たごもりすメモ
世界が滅亡することもなく2012年も本日で無事終わるようなので、すこし振り返ってみる。去年と同じようにやろうかと思ったんだけど時期ごとの特徴みたいなものがあんまりなかったので、トピックごとに適当にまとめる。 Fluentd とにかくこれでしたねー。Fluentdを本格的に使いはじめて、プラグインや周辺ツールを書きまくった。いま数えてみたら自分がリリースした fluent-* なgemは21個*1でした。けっこうがんばった。 fluent-plugin-delay-inspector fluent-plugin-ping-message fluent-mixin-config-placeholders fluent-plugin-config-expander fluent-plugin-woothee fluent-mixin-plaintextformatter fluent-plugi
fluent-plugin-numeric-monitor v0.1.0 and fluent-plugin-numeric-counter v0.1.0 released! - たごもりすメモ
Fluentdメッセージ中の数値の統計・集計をとるためのプラグインをふたつリリースしたのでその話。numeric-monitorは前に 0.0.x 系のバージョンでいちおう出してたけど、自分の手元でもちゃんと使い始めたので v0.1.0 として改めてリリースした。 fluent-plugin-numeric-counter fluent-plugin-numeric-counter | RubyGems.org | your community gem host tagomoris/fluent-plugin-numeric-counter · GitHub このプラグインは数値の上下範囲にマッチするメッセージをカウントする。数値版の datacounter みたいなものだと思えばよい。出力も datacounter の出力内容とまったく同じ。 Fluentd Casualのときの @fu
Fluentd meetup in Japan 2 にいってきた #fluentd - たごもりすメモ
Fluentd meetup in Japan #2 #fluentd on Zusaar ふらふらとお気楽に参加してきた。当方ささやかながらプラグインを作ったりしているので、他のひとがどのように使っているか、どのようなプラグインが他の人によって使われているか、あたりにたいへん興味があったので、そういう話をかなり聞けたのがすばらしく有益だった。主催者の方々、スタッフの方々、会場提供のグリーの方々、ありがとうございました。 以下だらだらとセッションごとに感想めいたものを書く。 「Fluentdの現在と未来」by @frsyuki 会場のFluentd利用者率が6割だか7割だかでびびる。本当に？ みたいな。あと日本語ドキュメントなんていらんかったんやー、俺達は間違ってなかったんやー、と安心したりする。*1 Fluentd次期バージョンの話、じつはこれをメインで聞きにいったけど、既にTwitte
たごもりすメモ
AWS LambdaでRubyランタイムを使っててzipアーカイブで関数コードをアップロードしてる人向け。 基本的にはGemfileに依存関係書いてbundle config set --local path 'vendor/bundle'してbundle installすればいい。以下のドキュメントを読もう。 docs.aws.amazon.com んだけど、Gemfileにrubygems.org以外から取得したgem、特にgitを指定したものを使っている場合にこれだけだとうまくいかないので、原因と対処を書いておく。 そもそもLambdaは何をやってるか 上述ドキュメントを読むとわかるが、zipファイルにはGemfile.lockもGemfileも入れない。それで動作する。これはどういうことかというと、AWS Lambdaのランタイム側ではBundlerを使わず(?)、vendor/b
fluentd のベンチマークとってみたよ！ - たごもりすメモ
入出力プラグインをrubyで書けるのがじつにいい感じの fluentd がいい感じに見える。 fluent/fluentd · GitHub ので使えるかどうか、使えるとしたらどれくらいのノードを用意すればいいのかについて考えるため、とりあえずベンチマークをとってみた。 結論 以下非常に長くなるので結論だけ書くと、大変使える感じ。現状だとほとんど何も考えずにデータ中継させても秒間1万メッセージ、100Mbpsくらいまでは処理できる。効率よくなるよう流す側も考えてやれば 300Mbps を超えるデータの転送に成功した。だいぶいい感じ。 なおこれは in_scribe および out_scribe を使用した場合で、開発者 @frsyuki によるとMessagePackでのデータ転送の場合はこの倍くらい出るらしい。 もちろんこれは右から左に流しただけなので現実にタグによるルーティングだとかロ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
