Docker 1.8 に Fluentd logging driver が入りました - たごもりすメモ
以前に書いた話の続きなんだけど、Docker 1.8が出た。 blog.docker.com で、それに Fluentd logging driver が入っている。これで Docker container で起動したプロセスのSTDOUTやSTDERRを直接Fluentdに向けて投げることが可能になった。Dockerにpull-reqを送ったのは初めてだったんだけど、無事マージされてリリースまでこぎつけたので、本当に出たときはほっとした。途中だいぶ大変だったので……。 Collecting All Docker Logs with Fluentd | Treasure Data Blog 5 Use Cases Enabled by Docker 1.8’s Fluentd Logging Driver | Treasure Data Blog Treasure Data blogで既に
fluent-plugin-secure-forwardの脆弱性とアップデートのお知らせ - たごもりすメモ
(追記 5/29 13:15) この更新の際、設定ファイルの shared_key についても変更されることをお勧めします。また変更をいくつか追加した v0.3.2 をリリースしましたので、このバージョンをお使いください。 これは v0.2.x を使用していたときに shared_key_digest を(あるいはshared_keyそのものを)攻撃者に入手されていた場合、認証情報をリプレイ送信されることで攻撃者が input plugin に接続できてしまう可能性があるためです。 深刻度は高くありませんが、念のため shared_key の変更をお勧めします。 また v0.3.2 は認証プロトコルに input plugin から送信するナンスをひとつ増やし、この種の攻撃可能性を排除するための変更を含んでいます。 (追記ここまで) fluent-plugin-secure-forward
就職しました - たごもりすメモ
結局3月からそのまま働くことにしました。 先日のエントリを書いて以来、本当に多くの方から声をかけていただきました。ありがとうございました。本来なら個別にご報告するべきところですが、ちょっと数が多くて厳しいので、このエントリをもって報告にかえさせていただきます。 またいろいろと話を伺う中で考えたことなどもあるので、そちらについては別途エントリを書くつもりです。 様々な話を聞いた上で、1月末の時点では自分でもわかっていなかったことがわかりました。最終的に重視したのは以下の点です。 技術ベンチャーであること ベンチャー企業として大きな成功を狙っていること、またそれが有望に見えること 優秀なプログラマが同僚に多いこと 退職エントリに書いた観点のほかに、この3点が今回の自分にとって重要だということは後から見えてきたことでした。 ということで Treasure Data に入社しました。Softwar
退職します - たごもりすメモ
先にまとめ 現在の勤務先を退職することにしました。本日が最終出社日です。 次はまだ決まっていません。というか、どことも具体的な話はまだしていない、という段階です。面白そうな職場はどこにあるかなと探している段階ですので、魅力的なところに心当たりがある方はぜひご連絡ください。色々な人と話ができるといいなあと思っています。 現職について 11月半ばくらいまでは転職はまったく考えていませんでした。が、その頃の世間の技術的な流れなどを見ていて、ちょっと技術的に異なることをやろうかなあ、と考えたのが直接的な理由です。今後どうするかを考えたとき、せっかくなら働く環境なども変えてしまった方がこれからの人生が刺激の多いものになりそうだということで、現職を退職することを決めました。 やりたいことを変えるだけなら社内でやればいいだろう、という話を会社側からはされましたし、もっともなことでもあるのですが、同時に前
YAPC::Asia 2014に行ってきた＆しゃべってきた - たごもりすメモ
YAPC::Asia Tokyo 2014 みなさんご存知のYAPC::Asiaに出したtalk提案が採択されたので、スピーカーとして参加してきた。スケジュールを見たら2日目の一番最後の枠(LTの直前)で、なんと初めてのホールでのtalk。 1日目午後は会社でお仕事上の用事があったので参加できず、2日目朝は前日夜に死ぬほど飲んでいたので動けず、2日目午後は自分のtalk前で気もそぞろ……という感じで聞く側としてはアレだったけど、いろんな人が会場にいていろいろ話したし、面白かった。 しゃべってきた "Handling not so big data." というタイトルで、今現在における分散データ処理プラットフォームの世界はどうなっておるのか、ということをざっと概観しつつ、そういう仕事に踏み込むときには何が重要なのかについて少し話した。 Handling not so big data fro
DISられないUIを作るために最低限守るべき5つの鉄則 - たごもりすメモ
ぼくらが迂闊にUIを作ると、そこにはユーザの正直な目線があり、非常に様々な、そして真っ当な反応がある。 曰く「わからん」「まさかそこをクリックするとは」「不思議な動作」「独自宇宙」「モリスUI」。 反応がもらえるのは非常に良いことだが、何度も何度も繰り返しているとつらくなってくるので、できれば避けたい。分かっている(いた)ことは最初から対応しておきたいものだ。*1 ということで、ここではブラウザで操作する管理画面等のWebUIを作るとき、真っ先に心得ておくべき5つの鉄則を紹介したい。これを守っていてもDISられなくなるというわけではないが、これを守らないと間違いなくDISられるので注意しよう。 なおこの記事ではオリジナリティというものについては考慮しない。オリジナリティとか犬に食わせろ。 クリックできる場所はcursor:pointerを指定しろ これを忘れるとこの世のものとは思えないくら
RedDotRubyConf 2014に行ってきた＆発表してきた - たごもりすメモ
シンガポールで行われるRubyのカンファレンス RedDotRubyConf 2014 に出したプロポーザルが通ったので、Fluentdについて紹介してきた。旅費は勤務先のLINE株式会社に出してもらいました。 RedDotRubyConf 2014 RedDotRubyConf のオーガナイザーは配慮がすごくて、accept後の旅行の手配やら向こうでの行動やら、いろいろ気にかけてもらった。カンファレンス前夜のスピーカーディナーとかあるのも個人的にはすばらしいと思う。あれで色々な人としゃべれて、イベントへの入りみたいな気分がかなりできて落ち着けた。 Fluentdは日本国内ではもうだいぶ認知されて使われているようだけど、海外だとアメリカで少し紹介されたくらいで、ユーザも少しずつ増えてはいるけどまだまだ、という状況だと思う。なので敢えて基礎から紹介する、という意味はあるだろうと思う。 実は自
Ansible勉強会#1 にいってきた＆しゃべってきた - たごもりすメモ
Ansibleの勉強会あるといいねーという話をしていたら開催されることになったAnsible勉強会#1にいってきた。んでしゃべってきた。 Ansible 勉強会 #1 - connpass Ansible 勉強会 #1 - 資料一覧 - connpass 開催はIanががんばりました。おつかれ！ あとレッドハットさんの会場を借りての実施がたいへんスムーズですばらしかった。なぜか申し込みが殺到して、新宿のほうでリモート会場まで用意されたようです。なんだそれすごい。 使ったこと無い人もけっこう参加してたようで、まあどういうものかは伝わったのかなあ。ユーザがどんどこ増えるとよいですね。 で、いろんな人がいろんな話をしててだいぶ面白い感じだった。わかりやすいansibleとはいえ他人の使いかたを聞いてると知らないこともちらほら出てくるものなので、勉強会やってるとそういうのがあってよい。 しゃべって
Norikra v1.0.0 - たごもりすメモ
English article 以前からスキーマレスなストリーム処理をSQLで！というソフトウェアとして作っていたNorikra、このたびあちこち機能改善したりしたので、既にお仕事で絶賛稼働中ということもあるし、区切りとして v1.0.0 としてリリースした。 ついでにロゴとかも作ったので、なんとなくいい感じになりつつある。 https://rubygems.org/gems/norikra/versions/1.0.0-java http://norikra.github.io/ 修正点は リポジトリ のChangesに書いてあるが、curlだけで操作できるようHTTP JSON APIが加わってたり、GCまわりでハマらないようなデフォルトオプションが入ってたり、分析系クエリを書きたい人のために Group-by with Rollup や Grouping sets, Cube などの
OpenLDAPサーバ(slapd)のperl backendを使う - たごもりすメモ
長いよ！ 社内Webアプリケーションの認証基盤としてあちこちでデファクトになっているのではないかと思われるLDAPだが、その管理は主に人事部がやっていたりして*1中身に迂闊に手を出せず歯がゆい思いをしているエンジニアに捧げるエントリ。俺得。 社内サービスのために認証をやりたいがパスワードの管理は別途LDAPがあるのでそっちに任せたい。しかしLDAPのディレクトリ構造のままだと権限情報がうまい具合に切り分けられず、ああああパスワードは持ちたくねえが権限情報は管理したり変更したり増やしたり減らしたりしたいよおおおおおお、という思いを抱いている人は多いと思う。 そこである日にOpenLDAPのオンラインドキュメントの目次を上から下までだらだらと眺めていると、なんと Perl Backend というものがあるらしい。サーバに来た問合せを任意のPerl moduleに移譲できるという。なんだって。す
OpenLDAPサーバを介してActiveDirectoryに接続する際の注意点ふたつメモ - たごもりすメモ
Windows ServerのActive DirectoryをLDAPサーバとして使用している人は多いと思うが、様々な事情によりWindows Serverに直接繋ぐのはアレなのでOpenLDAPサーバ(slapd)を立てて ldap backend を使用して中継サーバとしている人はそれなりにいると思う。いるよね。いるかなあ。 そのような構成にした場合、以下の2点に注意する必要がある。のでまとめてみた。 また 前のエントリ で書いた perl backend を使用した構成をとる場合にも影響する。 AD特有の属性値の扱いについて ActiveDirectory上のデータではアカウント名が sAMAccountName フルネームが displayName という属性に入っていることが多い*1。したがってこれらの属性が使えないといろいろと不便だ。 しかしOpenLDAPに含まれているスキ
Focuslight v0.1.0 - たごもりすメモ
グラフツールをひとつ作り、ひととおり動くらしいところまでいったので、とりあえず v0.1.0 としました。Focuslight と名付けています。 https://github.com/tagomoris/focuslight これは何かというと、このblogでも何度も紹介している GrowthForecast のRuby移植版です。同じ機能というだけでなく、内部データの互換性がありますし、HTTP APIの互換性も可能な限り保っています。ビューまわりは丸パクりしてます。 既に日本国内ではGrowthForecastは割と知られているだろう、という前提で説明をすると、これは「GrowthForecastの話は聞くが、でもPerlのツールはなー、ちょっとなー」というわがままさんのために作られたものであり、それ以上でもそれ以下でもありません。自分はおそらく今後もGrowthForecastを使
カスタマイズ済みのApacheログ書式もパースする Apache::Log::Parser の話 - たごもりすメモ
さて、Perlといえばテキスト処理、テキスト処理といえばPerlですね。そしてこのビッグでデータな現代においてテキスト処理といえばログの処理に決まっています。 ログの処理といってもいろいろですが、もちろん強く逞しく生きる現代っ子の我々は以下のようなログを扱います。 Apacheのログ Apacheのログなんだけどいくつかの書式が混ざってたりする combined に当然いろいろデータが足してある LTSVってなんですか？ そのような素敵な問題を解決するためのモジュールがCPANにあります。Apache::Log::Parserです。 あっ、そのページはダメ、こっち、こっちな。 Apache::Log::Parser Apache::Log::Parserは内部に2種類の解析器を備えており、パーサを初期化するときにどちらかを選びます。それぞれ以下のように動作します。 fast mode Ap
Fluentdとはどのようなソフトウェアなのか - たごもりすメモ
Fluentd というソフトウェアがある。日本国内ではそこそこ話題になってきたが、何ができるのか、何に使うと嬉しいのか、何に使えるのか、という点について詳細をよく知らないという人もおそらくまだ多いことでしょう。 なので、簡単にまとめる。 http://fluentd.org/ なお以下の個別項目ごとに書いていくが、その手前にまとめを置いておくので忙しい人はそれだけ読むとよい。インストールや設定については導入部分については日本語の記事はもう多くあるので、触れない。 概要 できること ログの収集 センサデータ等の収集 汎用データ処理プロセッサとして 頻出ユースケース ログの収集 データの集約 簡単なリアルタイム集計 ソフトウェアとしての特徴 コア プラグイン 安定性 性能 開発体制 コミュニティ ぶっちゃけどうなの？ まとめ 現時点で、複数の場所に分散したデータや常に増え続けるデータの安全な転
Cloudera World Tokyo 2013 行ってきた＆しゃべってきた - たごもりすメモ
Cloudera World Tokyo 2013で登壇する機会をいただいたので行ってきた。 Cloudera World Tokyo 2013 | Cloudera Japan しゃべってきた しゃべる方は最近作ってるNorikra……の話だけだとなんでCloudera World Tokyoだということになるので、集計処理をSQLに一本化してラクしよう、という文脈でHiveとNorikraで全部片付けるようにするといろいろ便利だしお仕事も回るよ！ という話。 で、ついでにv0.1.0をリリースしたばかりのNorikraというやつがどういうソフトウェアなのか、について簡単に紹介した。どういうソフトウェアなのかがいまいちわからん、という話が同僚からも聞かれていたので、分かりやすい話を一度しておこうかなと。*1 Batch and Stream processing with SQL fro
GrowthForecastの値をNagiosから監視できるようにすると #fluentd がより活用できる - たごもりすメモ
Fluentd からGrowthForecastへデータを投入するためのプラグイン fluent-plugin-growthforecast を作って使っている。 fluent-plugin-flowcounter および fluent-plugin-growthforecast released! #fluentd - tagomorisのメモ置き場 で、このGrowthForecastには最近、データをJSONで出力する機能がついた。 GrowthForecastに1分更新グラフ作成とサマリーなどのJSONフォーマットでの出力機能追加 - blog.nomadscafe.jp つまりFluentdからストリーム状に入力したデータを可視化しつつ、更に時系列データとしての(変則の)ストレージとしても使えるようになった、ということだ。つまりつまり、最近の3数値平均をとってそれを相手になんかチ
Fluentd Config DSLについての話 - たごもりすメモ
Fluentd に Config DSL を導入しろや！ つまり設定をRubyのコードで書かせろや！ という声は前から多かった。が、なんかいろいろ面倒な思惑が交錯し、あと「設定ファイルにrubyのコードでcallbackとか書いてプラグインの挙動を制御したい！」とか更に面倒なことを言いだした人がいたせいでDSL以外の設定書式でそれどうすんの……とコミッタの精神状態がどん底まで落ち込み長らく放置されていた。 みんなもOSSプロジェクトにfeature requestするときはあんまりステキすぎる機能のリクエストをする前に少し考えてみよう。まじで。 https://github.com/fluent/fluentd/pull/97 で、そんな数ヶ月ののち、ちょうど Fluentd v11 ハッカソンなるものがあったので、生ハム食べつつワイン飲んでたらConfig DSLのことを思い出した。まー
Fluentd v11移行を前に自分がAuthorのFluentd pluginについて - たごもりすメモ
ぶっちゃけ一人で全部移行とか無理！！！！！！！ あと自分で使ってないのとかもあるので、メンテナ(＆v11へのポーティング)を引き受けてくれる人を絶賛募集中です。v10の今から持っていっていただいて全く構いません。どうかよろしくお願いします。 まあ単純なプラグインもだいぶ多いのでよい練習・経験になるのではないでしょうか！*1 自分でやるよリスト これは自分で使ってるし、まあ多分やるだろうなー。でも誰か協力してくれれば早く進む！ あと共同メンテナはいつでも募集中です。 fluent-plugin-flowcounter fluent-plugin-datacounter fluent-plugin-forest fluent-plugin-growthforecast fluent-plugin-webhdfs fluent-plugin-numeric-monitor fluent-plug
Linuxサーバのディスク容量減少アラートが飛んできた！ってときにどう対処するか - たごもりすメモ
完全に このエントリ のネタパクりです。すいません。 何に使われてるかわかったもんじゃないマシンとか開発用サーバとかだと超巨大なバイナリとか置いてあるかもしれませんが、プロダクション用のサーバでそういうことは無いとしましょう。 その場合、原因はだいたい以下のどれかです。www/appとdbが別マシンに分かれてる場合は更に絞り込めますね。 wwwサーバやappサーバ ログ 圧縮してあるが保存世代数が多くて厳しいケース 圧縮し忘れてるケース 圧縮どころかローテーションすら忘れてて1ファイルどかんと存在するケース ローテーションがうまくいかなくて deleted ファイルなケース tmpデータなど(app) キャッシュサーバのディスクキャッシュ dbサーバ データ実体 (ib_data) バイナリログ ログの場合でも、ディスク上のどこにログが書かれてるかは色々なパターンがある可能性がありますね。
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
