LogstashからFluentdにデータを転送する
このエントリはFluentd Advent Calendar 2015の12月25日分の記事です。4日遅れ!
で、本題ですが、もうタイトルそのまんま、logstash-output-fluentd を作りました。
logstash-output-fluentd | RubyGems.org | your community gem host
tagomoris/logstash-output-fluentd · GitHub
How to install / use
先日書いたものと全く一緒ですが、いちおう書いておきます。
とりあえずインストール。
$ bin/plugin install ../logstash-output-fluentd-0.1.0.gem Uninstalling logstash-output-fluentd Validating ../logstash-output-fluentd-0.1.0.gem Installing logstash-output-fluentd Installation successful
そしたら以下の設定ファイルを用意します。stdinから読み込んで 127.0.0.1 (のデフォルトポート 24224)に送るやつ。
input {
stdin {}
}
output {
fluentd {
host => "127.0.0.1"
tag => "logstash"
}
}起動すればもう使えます。簡単ですね!
$ bin/logstash -f example.conf Settings: Default filter workers: 2 Logstash startup completed line 1 line 2 line 3 line 4
Yay!
注意点など
まだごくシンプルに指定したホストの in_forward に向けてデータを投げ付けるだけですが、まあ、使えなくもないかなというところです。Fluentdのforwardプロトコルにはいろいろと機能があるんですが、そのへんやover SSL*1やらはまだ全くしておりません。また複数ホストへのロードバランスやら死活確認(つまりHA)やらも対応しておりません。
そのうちやろうかなあ、どうしようかなあ。
バッファは logstash-output-treasure_data と同じでオンメモリに適当に持っているだけです。デフォルトは短めで50イベントもしくは5秒。これも flush_size および flush_interval で制御できます。正常にシャットダウンすればflushされるけどその時に失敗したり異常終了したりしたらイベントが失われるのも同じです。
まとめ
Enjoy logging!
*1:つまりin_secure_forward対応
LogStashからTreasure Dataにデータを投入する
このエントリは(2日遅れましたが)Treasure Data Advent Calendar 2015の12月25日分の記事です!
みなさんTreasure Dataにログ入れてますか? FluentdやEmbulkで入れてますよね?
しかし世界的に見てFluentdはまだまだ最有力のソフトウェアとは言えず、特にUSやヨーロッパのスタートアップ界隈ではLogStashが強い勢力を誇っています。Treasure Dataにログを投入するためだけにFluentdをインストールするのには抵抗のある向きもそちらには多いのです。
ということで、しょうがないから作りました! 本日から使えます。
logstash-output-treasure_data | RubyGems.org | your community gem host
tagomoris/logstash-output-treasure_data · GitHub
ただし現状ではdev releaseのライブラリに依存しており、この後ちゃんとメンテナンスリリースが出せるよう直すつもりです。また公式のlogstash-pluginsに入れてもらえるようにするつもりです。2016年かな。
How to install / use
LogStashを手元に展開したら、以下のコマンド一発でインストールできます。
$ bin/plugin install logstash-output-treasure_data Validating logstash-output-treasure_data Installing logstash-output-treasure_data Installation successful
そして設定ファイルを用意します。以下の設定は stdin を用いて標準入力から1行ずつ読み込み message というフィールドに入れ、そのイベントを treasure_data プラグインを用いてTreasure Dataの指定したデータベース/テーブルにアップロードします。(API Keyやデータベース名、テーブル名は実際に使用するものに置き換えてください)
input {
stdin {}
}
output {
treasure_data {
apikey => "0/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
database => "dbname"
table => "tablename"
}
}準備できたら起動するだけです。コンソールにメッセージを適当に入力し、終わったら Ctrl-D で入力を終端できます。終端したら自動的にflushされ、Treasure Dataへのアップロードが行われます。
$ bin/logstash -f ~/example.conf Settings: Default filter workers: 2 Logstash startup completed line 1 line 2 line 3 line 4 line 5 Logstash shutdown completed
簡単ですね! やった!
注意点
LogStashはソフトウェアの機能としてはバッファリング機構を持っておらず、そのため logstash-output-treasure_data では他の多くのプラグインにあわせる形で、オンメモリでのキャッシュを行っています。
Treasure Dataにあまり細かい単位でbulk importを行うのは非常に効率が悪いため、現在はデフォルトでは10,000レコード、もしくは5分毎にflushを行うことになっています。*1
通常の手順でLogStashをシャットダウンすればその際にflush/uploadが行われますが、プロセスの異常終了などが起きた場合はメモリ内のデータは失われるのでご注意ください。
まとめ
Happy Logging!
*1:これらの設定は flush_size および flush_interval で制御できます。
WEB+DB PRESS Vol.90にコラムを書いた
明後日ですね、12月23日発売の WEB+DB PRESS Vol.90 の15周年記念エッセイ「私を変えたソフトウェア」にて2ページ、記事を書きました。
たまに(?)このblogでもエモいアレを書いたりしますが、なんかそういうやつです。原稿料をもらってこういうのを書いたのは初めてです。たぶん。
内容は本誌を読んでいただきたいんですが*1、要するに今現在に毎日ミドルウェアを読み書きして生活するようになったきっかけは何だったか、という話です。きっかけひとつというわけでもなく幾つか段階があるなあと思ったので、それについてつらつら思い出話のようなものを書いてます。
改めて読んでみると最後の1ステップ(現職への転職)が抜けているのでそこに何の迷いもなかったようになってますが、もちろん実際はそんなことはありません。が、まあそれはソフトウェア開発者としての転機というよりは人生どう生きるかみたいな部分なので、いいかなと思います。
しかし他の3氏がものすごくて、Rubyの人とHSPの人とLispの人ですよ……。ひええ。あと他がみんな1990年以前の話なのに、自分のやつだけ2010年代になってます。並んでるソフトウェア名も Emacs、スペースインベーダー、Lisp と並んで "FluentdとNorikra" とか、うああ。*2
他の方よりもうちょっと卑近な例ということで、これはこれで存在意義があるに違いないと自分に言い聞かせてます。
他の記事だと自分には特に特集2のドラクエXの話が興味深くて、ほほうKTにCassandraにExadataとな……みたいな感じです。まだざっと目を通しただけなのでじっくり読みたい。大規模MMORPGのバックエンドについて詳しく雑誌に書かれるとはすごい時代だなと思いますね。
ということで、興味があれば読んでみてくださいな、という話でした。
RubyKaigi 2015に行ってきた＆しゃべってきた
この週末にあったRubyKaigi 2015に参加した。
RubyKaigiはRubyコミッタやその他の人々に、特に低レイヤや各種OSの事情に詳しい人なんかも多くて、これはこれで非常に刺激になっていていいなあ。言語ランタイムの最適化の話を何セッションも聞くとかは国内の他のカンファレンスでは自分はあまり経験しないので、いつも楽しい。
しゃべってきた
EuRuKo 2015で話したのと同じタイトルだけど内容はけっこう違ってて、なぜTDではRubyでqueue/workerシステムを必死に作っているか、みたいな話をメインに据えて話してきた。あまりRubyのコードそのものに触れることができなかったのがちょっと残念だけど、前提条件から丁寧に、必要性とどうなっているかを説明できたかなという気はする。
あとシステムを改善するときにどうしたらいいかという方針の話を質疑応答で少しできて、それもすごくよかった。質問してくれた @joker1007 さんのおかげです。
来年
京都だ! 楽しみ。行きたいなあ。そのためにもうちょっとコードそのものについて話せるようなネタを作りたいなー。
ISUCON5の出題をやった
(11/2 11:03 末尾に追記と得点経過グラフ掲載)
正確にはいままさに決勝のイベント中なのだが、思った以上に順調にイベントが進行していてヒマな上、完徹の後でコードとか書いてる最中に意識が飛んだりするのでコードも書けない。のでつらつらこれを書いている。
9月末にISUCON5予選をやり、10月末のいま決勝をやってます。3年ぶりのISUCON出題側でしたが、いやはや、過去最高にきつかった回だった。ちょっとday jobのほうでもクリティカルなあれこれが重なったのもあるけど。
しかし両方とも、直前までの死ぬ寸前みたいな追い込み状況に対し、イベントとしては*1大きな破綻もなく進み、本当に良かったと思っている。このイベントがイベントとして成立したことが本当に嬉しい。
そういったあれこれは本当に一緒に出題をやってくれた@kamipoさん、そして実装を手伝ってくれた@hydrakecatさん、@najeiraさん、@makingさん、@taroleoさん、@hokacchaさんのおかげだと思う。出題の傾向・内容ともにだいぶハードだった上、じぶんの作業の遅れがモロにイベント直前に皺寄せでいってしまった。
このような状況でコンテストが成立したのは本当にこの人達のおかげだ。ありがとうございました。
これまで何度か言っていたけど、ISUCONを予選だけで終える人達が大多数になってしまった以上、一度は「自分たちが知っている決勝の問題」を予選でもやってみたかった。今年の予選は(ちょっとギリギリ感があったけど)、それがいまできる最大限にできたと思う。今年の予選に参加した人には胸をはって言える。あれはISUCONだ。
決勝はこれまでとだいぶ方向性を変えてみた。詳しい解説は別途書く機会があると思うが、これまでのISUCONとはだいぶ違う。
これはふたつの理由があって、ひとつは*2これまでと同じような問題では同じような人達が勝ってしまうから、やはり方向を変えたい、ということ。もうひとつは、なんとなくだけど、ISUCONの出題内容・傾向をいちばんドラスティックに変えやすいメンタリティを持っているのは自分なのかなと思ったことがある。
ISUCONはまだ、たかだか5回しかやっていないだけの技術イベントだ。守らないといけないものはないし、これだけ出題というものが大変なんだから、出題者はなんでもやりたいことをやればいいと思う。参加者は不満があれば、自分で勝手にイベントをforkして出題をしてみればいい。
そうやって、全体として面白い、幅広く懐の深い開発者コミュニティになっていければいいなと、そう思う。
ああ楽しかった! 2年参加して今回出題したから、次は少なくとも4年は参加側かな! 超疲れたし!
結果
また! またしても! fujiwara組に勝たれてしまった!!!
他チームの得点が見えなくなった時間帯も含めた得点グラフはこちら。最終計測のもプロットされてます。
ベンチマーク走行は全体で1409回、優勝チームは46回実行リクエストがあったようです。最多チームは91回でした。
ということで
夜な夜なコードを書いていてゆっくりビールも飲めなかった俺の冷蔵庫を溢れさせてやろうという方は ぜひこちらのwishlistをどうぞ! 本当に溢れたらまたmorisniteやるかー?
EuRuKo2015に行ってきた
EuRuKo 2015 に出したトークのproposalが通ったので話しに行ってきた。往復旅費は現勤務先であるTreasure Dataに出してもらいました。ありがたや。宿泊費はなんとオーガナイザーが出してくれた。すごい。
2ヶ月ぶり生涯二度目のヨーロッパ、今回はオーストリアのザルツブルク。あいかわらず行くのは遠いし乗り継ぎも必要でちょっと大変だけど、それでも行ってよかった。たいへんよかった。
前のドイツ行きとちがって今回は日本から他の参加者もいたので、というかまつもとさん、笹田さん、鳥井さんという……ひええ、超豪華メンバー、だったので、英語で疲れたときに普通に日本語で話ができるのがありがたかった。あんまり大勢日本人がいるのも風情がないが完全にぼっちというのもきついので、このくらいだと英語でしゃべる機会もそこそこあるし、いいな。
ということでしゃべってきた。
ふつうに会社名をタイトルに入れてCFPに応募したのが通ったからそのまましゃべってきたんだけど、カンファレンス全体的に他のスピーカーの人達がまったく自社企業のアピールをしないので、ええコレまずかったのかな、という気分にちょっとなったのは事実。でもこれで通ったしなあ。
データ解析系の話は縁が遠い人が多いのかなという印象の反応だったけど、それでも終わったあとで色んな人とあれこれ話をした。自分で作ってる人はやっぱりデータストアやら何やらに苦しんでいる人が多いいっぽう、自分でHDFSとかをホストせずS3に頼ったほうがよいアーキテクチャだということには懐疑的な人も多いようだった。いやー、S3のパフォーマンスすごいよ、という話を何度かした。
いっぽう縁が遠い人にはなんでいちいちそんなソフトウェアを自分達で(Rubyで)書いてるんだ、ということがうまく伝わらなかったようなので、その部分はもっとちゃんと話すべきだなあという感じ。じつは同じ話で RubyKaigi 2015 にも通っているので、そのあたりを直してやりたいと思ってる。
他のスピーカーの話は、なんというか、いろいろ。あまりプロダクションシステムの話をする人は多くなくて、教育だとか素朴な要素技術(SSL/TLSの話とか!)とか、良くも悪くもアカデミックに近いというか開発者コミュニティそのままのカンファレンスという手触りだった。これはEuRuKoだからなのかヨーロッパだからなのか、興味深いところ。隣に座ってた人と話してたらPerl6を話の例に出されてうおっヨーロッパっぽい! と思ったこともあった。
雑談してるときの英語にほとんど困らなくなってたのはよかった。プレゼンテーションも資料を作るところ含めて日本国内でやる場合とほぼ同じ程度の準備、で、まあ英語についてはそう悪くなくやれたんじゃないかな。これはTreasure Dataに入ってから明らかに進歩したところだと思う。
しかしザルツブルクはとにかく街がすごい。まさに多くの日本人が色んなものの刷り込みの結果脳裏に思うような、古き良きヨーロッパの街だ! という感じがする。だって川と橋と教会・聖堂と広場と市壁と断崖と城だぞ。石造りの建物が密集してその間に狭い路地がはりめぐらされてるし、ちょっと山っぽいところを歩いていると木々のむこうから古い城館が現れるし、あちこちに怪しげな門があるし。もうたまらん。
あとは肉を食べ肉を食べ芋を食べチーズを食べ肉を食べ。
ビールビールビールビールビール。
ザルツブルクにも大きいビールメーカーがあるらしいし、そのほか地方のビールもあれこれあった。そんなに多く飲んだわけじゃないけど、けっこう満足できる感じでたいへんよい。
ウィーンだと甘いものがすごいことになってたらしいが、ザルツブルクでもちょっとだけ楽しんだ。よかった。
ということで、非常に良い旅行だった。来年はブルガリアのソフィアらしい。
とにかく普段と異なる経験、USやアジアのカンファレンスに行くのとはまた全然違う経験ができるので、未経験の人には本当にお薦めです。楽しかった!
java-ja.OSS でOSSの話をしてきた
自分はべつにOSSの偉い人でもなんでもないのだが、YAPCで話したこととその発展みたいな感じでどうよということがあって、ざらっと話してきた。イベントはこちら。
で、スライドはこちら。YAPCの再演でもいいよってことだったけど自分がそれじゃつまらんので、その後の話なんかも含めて取捨選択した。これまでの話は知ってる人が(会場には)やっぱり多かったので、発展的な話題とか細かいところをひろっていくような話にしたつもり。
OSSそのものについてどう思うかっていうの、実際に自分に強い意見があるかというとそんなにはなくて、ストレスを感じなくていいケースではいちばんストレスのない方法を淡々と選びたいなあ、と思うくらい。
そうでないもの*1にはそれはそれで色々あるけど、それはまあ仕事だからなあ、という感じ。日本国内のコミュニティだと仕事としてOSSをやっている会社がほとんどない関係で、そのあたりの話はちょっと興味深い人はいたかもしれない。あるいは、現実離れして聞こえたかもしれない。……ところで仕事としてOSSをやっているTreasure Dataという会社があるらしいよ!
ところでOSSの話をするときに自分がどの視点に立脚しているかを前提として話しておくのは本当はけっこう大事で、それによって考え方や行動様式がだいぶ変わるから。というのは、イベント翌日にTwitterで流れてたtweetを見ても思った。
俺が「後方互換性はソフトウェア作者と利用者の信頼関係の源なんだよ。だから努力に努力を重ねて守るんだよ！！」という講演をした後で、松田さんが Rails の文脈で「互換性なんて💩」という講演を始めたの、かなり面白い流れだった #java_ja_oss
— Takuto Wada (@t_wada) 2015, 10月 6@t_wada そうですね。和田さんも、あと @tagomoris さんも、基本的に同じテーマについて喋ってるはずなんだけど僕が言おうと思ってたこととあんまり重ならないというかむしろ真逆みたいなことをけっこう言ってて、すごい面白いなーと思いながら聞いてました。
— Akira Matsuda (@a_matsuda) 2015, 10月 6これは当日に @a_matsuda さんの話を聞いててもすごく思っていたところで「あー莫大なユーザと大規模な開発者コミュニティをかかえてる超強力OSSプロダクト*2はやることが違うなー強いリーダー*3もいるしすげーなー」みたいな。立場が違うとやることが変わる。
ただし唯一(?)共通していたのが「走り続けないと死ぬ」みたいなやつで、これはRubyの開発とかでもコミッタの人々*4がよく言っていることだと思う。違う視点の話だけど毎日コミットするのを継続するっていうやつ、自分は怠惰なので不可能だけど、なるほどなあ、ということを思いはする。
なんにしろ、こういう機会があって自分の思うところをしゃべったり、他の人の話を聞きながら適度にツッコんだりできる機会はたいへんありがたい。
あと夜中まで超面白かった。ありがとうございました。
