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で既に
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 などの
GCP ja night 27 いってきた＆しゃべってきた #gcpja - たごもりすメモ
ひさびさに自分がしゃべれる面白技術ネタがあるかな、と思えるいい機会だったので、いってきた。 gcp ja night #27 - connpass appengine ja night だった頃(の、しかもだいぶ前)によく行ってたけど最近は長いことご無沙汰だったので、おひさしぶりです！ な人がいっぱいいて面白かった。いっぽうぜんぜん知らない人も多くて、人が入れ替わっているんだなあと思うことしきり。 問題意識が最初にあって、それをどう解決するためにどういう技術を用いたか、ということが明確なセッションは聞いていてやっぱり面白い。いっぽう単にこれをこう使ってみようという話は、そうですか、という感じでどうもなー。事例について話すなら、どういう問題意識があるのかを聞きたいですね。 しかし、一番面白かったのが事例紹介の非公開セッションだというのはちょっと寂しい感じがする。こう、GAE/GCEを変な使い
fluentdとシステム設計の小ネタ - たごもりすメモ
あるいは http://yugui.jp/articles/879 へのreply。 システム監視をfluentdに統合してしまうべきか否か システム監視は分けておいた方がいいと思う。分けるべき、とまでは言わないけれど。 それらの仕組みには相応の必要な機能セットがあり、それらは長い歴史の中で比較的決まった機能セットに収斂してきており、その収集・モニタリング・可視化・アラート通知など決まりきったパターンを様々な項目について停止なく行う必要がある。 Fluentdの各種プラグインを用いることで同じような機能は実現できる。そのプラグインのうち数割は自分が書いものだったりする。とはいえ各ホストのシステム監視までそこで行うことを想定して書いたかというと、もうちょっと高いレイヤでの監視・集計、つまりサービス単位などを目的としたものが多い。サーバ単位で行おうとしたときに設定が雑多なものになるのはおそらく
isucon3本戦いってきた＆勝ってきた！ #isucon - たごもりすメモ
isucon3の本戦にLINE選抜チームとして出た。ガッカリな感じだった予選時の状況はこちら。 isucon3予選参戦の記録 - tagomorisのメモ置き場 引き続き @kazeburo @sugyan @tagomoris の3人チーム。 ざっくりまとめ みんなこれまでこんな楽しいイベントに参加してたのか！ ずるい！！！！！！ 普段やってることを普段通りやる、と思っていたが焦って普段やらないようなミスを次々連発、社会は厳しい 思いきった構成変更とかできるのがisuconでしょｗｗｗｗ とかドヤ顔していたが、やりきれた。ドヤッ。 これからisuconという名前を口にするときに堂々とドヤ顔しようと思います。嘘です。元出題者のくせに成績出ないとかｗｗｗみたいにならなくて本当に安心しました。終わったあとのビールおいしかったです。 ということで、勝ちました。優勝と、あと僅差で特別賞もいただきま
Fluentd meetup in Japan 2 にいってきた #fluentd - たごもりすメモ
Fluentd meetup in Japan #2 #fluentd on Zusaar ふらふらとお気楽に参加してきた。当方ささやかながらプラグインを作ったりしているので、他のひとがどのように使っているか、どのようなプラグインが他の人によって使われているか、あたりにたいへん興味があったので、そういう話をかなり聞けたのがすばらしく有益だった。主催者の方々、スタッフの方々、会場提供のグリーの方々、ありがとうございました。 以下だらだらとセッションごとに感想めいたものを書く。 「Fluentdの現在と未来」by @frsyuki 会場のFluentd利用者率が6割だか7割だかでびびる。本当に？ みたいな。あと日本語ドキュメントなんていらんかったんやー、俺達は間違ってなかったんやー、と安心したりする。*1 Fluentd次期バージョンの話、じつはこれをメインで聞きにいったけど、既にTwitte
尊重されたいすべてのソフトウェアエンジニアへ - たごもりすメモ
自分はソフトウェアエンジニアとして毎日の糧を得ている。今のところはサラリーマンエンジニア以外の存在になる予定はない、が、とはいえ唯々諾々とつまんない仕事ばっかりやる毎日はできればごめんだと思っている。コードを書くのは楽しいからコードを書ける仕事をしたいし、特に面白い問題やまだ誰も手をつけてなさそうな問題を解決する仕事ができれば最高だ。 つまり、そう、尊重されたい。自分のやれること、やりたいことを尊重されるようになりたい。自分がやった仕事には価値があると思われるのは嬉しいし、そのように(勤務先以外の)他人から認められれば面白い話も聞けるようになるかもしれない。尊重されるソフトウェアエンジニアになれれば楽しそうだ。 尊重されるソフトウェアエンジニアであれば、もしかしたら自分の仕事についてある程度の自由が効くかもしれない。突然わけのわからない政治でがんじがらめの炎上プロジェクトのPMをやってこい
fluent-plugin-sampling-filter and fluent-plugin-datacounter released! #fluentd - たごもりすメモ
Fluentd において特定パターンのデータをもっているメッセージ数をカウントする、およびメッセージ数に対してパターンごとの割合を算出する fluent-plugin-datacounter をリリースしました。また fluent-plugin-datacounter のようにメッセージの傾向を算出するためのプラグインに入れるデータを作るため、全メッセージからサンプリングを行う fluent-plugin-sampling-filter もリリースしました。 fluent-plugin-datacounter | RubyGems.org | your community gem host fluent-plugin-sampling-filter | RubyGems.org | your community gem host fluent-plugin-sampling-filter
node.js用のThriftライブラリにパッチを書いた - たごもりすメモ
先日の node.jsからThrift経由でHiveServerに通信しようとして力尽きた - tagomorisのメモ置き場 の記事に書いた件、しばらくThriftの BufferedTransport の他言語実装を眺めていたらなんとなく作れそうな気がした*1ので、transport層を置き換え可能にするためのリファクタリングに半日、BufferedTransportの実装に半日をそれぞれかけてパッチを書いた。 github上でmasterを公開してる人にpullreqを送ってみたら取り込んでくれるようだ。その上 upstream(Apache Thriftプロジェクト本家)への取り込みへの提案もやってくれた。Rejectされることがなければ、待ってるとそのうちThriftを使う全プロジェクトで node.js でも実装できるようになる。自分が書いたパッチを当てたものを使うように意識し
node.jsの非同期I/Oにおけるデータ受信のパターンのバリエーション - たごもりすメモ
そもそもなんでnode.jsのThriftライブラリではBufferedTransportがサポートされず、FramedTransportのみが使える状態だったのか。Thriftの歴史的にはBufferedTransportの方が先行して存在しており、また仕様自体も単純のようだ。*1 実装を開始してみてわかったが、node.jsが採用する非同期I/OアーキテクチャのAPIと実に相性が悪い。Thriftが定義ファイルから各言語用のコードを自動生成する仕組みであることも関係している気がする。いざnode.jsの都合に合わないからといって、カジュアルに生成結果のコードを修正するわけにはいかない。また受信データ(を持っているはずのI/Oストリーム)からデータを読み出すところまでがThriftによる自動生成の範囲に含まれる。 (Twitterで言及を読んで追記) 普通にアプリケーション側のコードをコ
"Hbase at Facebook" に行ってきた - たごもりすメモ
名称表記が揺れてて微妙だけど Hbase at FaceBook on Zusaar このイベントに行ってきた。Facebookの人は "HBase Tokyo meetup" と認識していたようだ。 内容のまとめはやらないので、以下の各ページなどをご覧になると良いのではないでしょうか。 Tokyo HBase Meetup - Realtime Big Data at Facebook with Hadoop and HB… Hbase at FaceBookのまとめ - Togetterまとめ FacebookがHBaseを大規模リアルタイム処理に利用している理由（前編） － Publickey FacebookがHBaseを大規模リアルタイム処理に利用している理由（後編） － Publickey セッションの内容と自分が考えたことと人としゃべったことをいっしょくたにここに書いておく。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
