FluentdでバッファつきOutputPluginを使うときのデフォルト値 - たごもりすメモ
なんか自分で docs.fluentd.org へのpatchを書いてて混乱してきたのでまとめる。コードを読んでも関係する設定値がいくつものモジュールに分散しており、完全に把握することが困難である。具体的には、この組合せを記憶だけで答えられる fluentd コミッタはおそらく一人もいない。 概要 対象は BufferedOutput および TimeSlicedOutput を継承している output plugin の全て*1。out_forward, out_exec や out_exec_filter も含まれる。 基本的にはいくつかの設定により flush をするタイミングを制御するパラメータ一式、およびflush対象となるデータのチャンクを溜めておく量の上限を決めることとなる。fluentd をうっかり試したときに「アイエエエ、fluent-cat してみたんだけど、設定したと
GradleでMaven Centralにライブラリを公開する - たごもりすメモ
前にこんなエントリを書いたが、このときはmavenから実行してた。今回はgradleから。参考にしたエントリはいくつかあったけど、ずばりというのがなくてつらかった。あれこれ試して組み合わせた。 はじめてのmaven central 公開 - たごもりすメモ あとMaven Central(というかSonaType OSS)もちょっと変わってるのでそのへんも。なお環境は適当なMacに適当にgradleを入れた。以上。 前と変わらないところ GPGのセットアップ パッケージ名前空間を決める アカウント登録 パッケージ名前空間は今回は前のと違ったので、申請は今回もやった。前と同じようにやってさくっと完了。 gradle環境の設定 "$HOME/.gradle/gradle.properties" に行う。 org.gradle.daemon=true signing.keyId=DEADBEEF
小中規模のIT系企業における技術的選択と雇用戦略に関する雑感 - たごもりすメモ
でっかい主語で入ったが、要するに2月にあちこち会社巡りをしたときに感じたことについてつらつら書こう、というのが目的。 特定の会社について書いてもしょうがないので、あれこれ*1回ったうちから少なくとも2〜3ケースで該当するなあ、と思ったことについて書く。特定の1社のみに該当する事項はこのエントリにはひとつも出てきません。 またエントリの主旨からして超上から目線になりますが、どうかご容赦ください。 これから成長が本格化するのでインフラを支えられる人材がほしい 正直に言ってこれが一番多かったパターン。スタートアップ的にサービスを作ってきたがその一方でデプロイや監視などの運用まわりが後手後手になっており、そのあたりを支えられる人物がほしい。 話としてはわかるのだが、気になったのは、これを聞くとき、詳しい内容を突っ込んでみると、どうも実際にはそう困ってはいない、というケースがほとんどだったように思え
Ansible playbookで1台でも失敗したら即座に実行を止める方法 - たごもりすメモ
毎回あれー？ってなってドキュメント読んだりググったりするんだけどうまく見付けられないので書いておく。 Ansibleはデフォルトだとtaskの実行が全ホストで失敗しない限り続く。言いかえると、あるタスクがあるホストで失敗したらそのホストについては以降実行されないが、成功した他のホストについてはplaybookの実行は継続される。 これは特に分散ストレージのセットアップなどにおいて、大変よくない。 よくないので1台でもtaskの実行に失敗した時点で止めたいというタスクには以下のように書いておく。 - hosts: ippai max_fail_percentage: 0 tasks: - name: .... failしているホストのパーセンテージが max_fail_percentage を「超えた」場合にplaybookが停止するので、1台でも fail したら即座に止めたい場合は 0
Hadoopクラスタでulimitを設定するときの注意点 - たごもりすメモ
Hadoopクラスタを運用する際に ulimit で nofile (プロセスがopenできるファイルディスクリプタ数の上限)の設定を変更しておくべき*1というのはもはや常識的なお話ですが、そこには実は罠がある。たぶんRHELのデフォルト通りならハマらないんだろうけど、手を入れている環境だとハマる。ので、その話。 要するにハマった。のを解決したよ多分！ まだ最終的な確認できてないけど！ 各書籍での解説 とりあえず、国内で売られているHadoop関連書籍の記述を確認しておこう。まずHadoop徹底入門。 ファイディスクリプタの設定は、/etc/security/limits.conf に記述します。エディタを利用して、limits.conf に以下のように記述します。ここでは、Hadoopの各種ノードを起動するユーザーを hadoop とします[12]。 hadoop soft nofile
最近のHadoop distcpについて - たごもりすメモ
Hadoopクラスタ間でデータを移動するdistcpについては実はHadoop2系で新しくなっており*1、いろいろ機能が増えている。 たとえば以下のようなコマンドが実行できる。 hadoop distcp -i -m 20 -pb -bandwidth 2 webhdfs://cluster.old.local/path/of/data/dir hdfs://cluster.new.local/path/of/data/dirこのコマンドラインには、従来のdistcpでは不可能だったふたつの変更が含まれている。 bandwidth 前は指定できなかったが、今は mapper あたりが使う帯域をMB/sec単位で指定できる。べんり。 webhdfs:// 前はバージョンの異なるHadoopクラスタ間でdistcpする場合、新しいクラスタでdistcpを実行し、古いクラスタ(source側)の
MRv2/Tezで簡単にクエリのベンチをとった - たごもりすメモ
Hiveしか使ってないので以下のオプションを設定するだけで使える。楽。 SET hive.execution.engine=tez; なお HDP 2.1 with Hive 0.10, Tez 0.4 での話です。クラスタの概要は以下の通り。 master x3 slave x20 Xeon(R) CPU E5-2630L v2 (6core 12Threads) x2 RAM 64GB HDD x12 シナリオ データの流れとしては以下のようなシナリオを想定する。 外部から非圧縮plain text tsvでHDFS内のファイルにデータが書かれる LOADで hourly テーブルに読み込む dailyで INSERT により daily テーブルに書き込む このときファイルフォーマット変換や圧縮を同時に行う hourly テーブルの変換済みパーティションおよび元の生データは削除する
はじめてのmaven central 公開 - たごもりすメモ
前置き：このエントリはJavaおよびJava周辺の*1開発環境に全く縁の無い人間が、可能な限り依存ソフトウェアを少なく手順をシンプルに保ったままやろうとしたものであり、知識・経験のある人にとっては全く最適な手段でなかろうことをお断りします。 先日のエントリ で書いたとおり woothee 1.0.0 をリリースした。Perl, Ruby, Node.js および PHP などはそれぞれの言語毎のモジュールリポジトリに登録されている。 が、Javaについては自分が Maven Central の勝手がわからず、されてると便利だよなーとは思いつつ放置していた。 が、なんと @making さんからMaven Central登録用の pull requestがきた 。きてしまった。これで最大の問題(xmlを書く)はおおむね解決されてしまったので、覚悟を決めて登録作業をすることにした。 せっかくや
DISられないUIを作るために最低限守るべき5つの鉄則 - たごもりすメモ
ぼくらが迂闊にUIを作ると、そこにはユーザの正直な目線があり、非常に様々な、そして真っ当な反応がある。 曰く「わからん」「まさかそこをクリックするとは」「不思議な動作」「独自宇宙」「モリスUI」。 反応がもらえるのは非常に良いことだが、何度も何度も繰り返しているとつらくなってくるので、できれば避けたい。分かっている(いた)ことは最初から対応しておきたいものだ。*1 ということで、ここではブラウザで操作する管理画面等のWebUIを作るとき、真っ先に心得ておくべき5つの鉄則を紹介したい。これを守っていてもDISられなくなるというわけではないが、これを守らないと間違いなくDISられるので注意しよう。 なおこの記事ではオリジナリティというものについては考慮しない。オリジナリティとか犬に食わせろ。 クリックできる場所はcursor:pointerを指定しろ これを忘れるとこの世のものとは思えないくら
Hadoop Conference Japan 2014いってきた＆しゃべってきた - たごもりすメモ
Hadoop Conference Japan 2014- Eventbrite 今年も開催されたのでいってきた。主催者の方は本当におつかれさまでした。毎回規模がでかくて、これやるのは本当大変だろうなと思う。参加登録者は1299名だそうな。 全体的な空気としてはいよいよYARN移行が避けられず、その上に乗っかるデータ処理フレームワークとしてMapReduceも今後存在しつづけるもののSparkやTez*1が登場し、処理記述言語としてはもう単純な処理についてはSQL一択ですかね、という感じ。機械学習系やそのほかのワークロードはまた違うだろうけど。あとはMPP系のエンジンがその脇にある、という。 今回は事例の話が極端に少なくなって、みんな各コンポーネントについての話をしてた気がする。技術的には過渡期だということかな。いいことだ。 参加者アンケートでFluentdを使っていると答えた人が200人
業務とオープンソース活動の話 (日本OSS奨励賞 受賞報告にかえて) - たごもりすメモ
先日書いたエントリでも触れたけど、日本OSS奨励賞、というものをいただくことになりました。ご推薦いただいた方がいるということで、本当にありがとうございます。 「第9回 日本OSS貢献者賞・日本OSS奨励賞」受賞者を選定 | 日本OSS推進フォーラム で、せっかくの機会だし、普段思っていることを書いておこうと思う。この内容はほとんど将来の自分に対する自戒だ。アレな内容になることを申し上げておきます。先日に引き続いてアレですが、まあせっかくの機会なんですよ。ねえ。 ちなみに、ちょー長くなりました。あっはっは。 業務としてのオープンソース活動 自分はフルタイムのオープンソースコミッタではない。オープンソース活動に貢献すること、などという文言は自分の業務内容にはひと言も含まれていないし、自分が所属する部署の目標にも無い。自分の業務はあくまで自社サービスに貢献すること、自社サービスの開発および運用を
4年前、おれがSIerの片隅で、何者でもなかった頃 - たごもりすメモ
今からちょうど4年前の2010年2月、某巨大SIerの片隅でExcelやPowerPointばかりを眺めて過ごしていた頃、おれは仕事でも仕事以外でもコードなんかまったく書いていなかったし、GitHubのアカウントも持ってなかった。毎日見積書とWBSと納品書と請求書と、Excel方眼紙の詳細設計書と格闘してた。 当時おれは30歳だった。一度はプログラマとして生きるのは自分には無理だと思って入社したSIerで数年やってて、そこそこ成功した数年を送っているとは思っていたけど、でもやっぱり、そんな毎日に飽きていた。 技術力を重視とか言いながらプロパー社員にコードを書かせようとしない会社の方針にも、svnもgitも閉じられててガチガチに監視されたネットワークに繋がせておいてオープンソースがどうのと言う文化にも、手順や履歴を重視とか言いながらロクにバージョン管理システムを使おうとしない一部の同僚にも、
筑波大の集中講義 #GB37301 にいってきた/しゃべってきた - たごもりすメモ
筑波大学の川島先生にお呼ばれして「情報システム特別講義D」なるものを1コマ担当してきた。内容は「ビッグデータ基盤技術に関する国内のエキスパートをお招きし、講演を行う。」*1だそうで、ひええ、というか、自分でいいのか、という感じだが、何より2日間、1コマ75分を10コマもかけて他の人達の話を聞いたりツッコんだりしてよい場だというので、いってきた。結論から言うとめちゃくちゃためになった。たまらん。 参考1 参考2 予め聞いていたところでは「聴講者はどうせ10人くらいだろうから、あと講師10人でわいわいツッコミながらやりましょう」とか言ってたのに当日聞いたところでは履修登録が50人とかで、しかも割と当日に人がきてた。各講義の話題がかなり専門的な向きへの話を含んでいたので大丈夫かコレと思ってたら、なんか筑波の学生さんって学部のうちにゴリゴリとコード書いちゃうような人がすごい多いらしい……。「Has
カスタマイズ済みの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/ なお以下の個別項目ごとに書いていくが、その手前にまとめを置いておくので忙しい人はそれだけ読むとよい。インストールや設定については導入部分については日本語の記事はもう多くあるので、触れない。 概要 できること ログの収集 センサデータ等の収集 汎用データ処理プロセッサとして 頻出ユースケース ログの収集 データの集約 簡単なリアルタイム集計 ソフトウェアとしての特徴 コア プラグイン 安定性 性能 開発体制 コミュニティ ぶっちゃけどうなの？ まとめ 現時点で、複数の場所に分散したデータや常に増え続けるデータの安全な転
RubyKaigi 2013にいってきた＆しゃべってきた - たごもりすメモ
この5月30,31日および6月1日に行われた RubyKaigi 2013 にproposalが通ったので、スピーカーとして参加してまいりました。 http://rubykaigi.org/2013/ 面白いトークがいろいろあったし色んな人と話ができたし、空き時間にfluentdの修正についての話や作業も進んだし、本当にすばらしいイベントだった。 お台場は遠かったけどHerokuさんのおかげでお昼に困らなかったし、Microsoftさんのおかげで飲み物にも困らなかったし、Githubさんのかげで懇親会にも困らなかった。すごい。スポンサー様すごいですね。 セッションはいろいろ聞いたけどまとまらないのでパス。テクニックの話が多かったな。Rails以外にRuby本体の話がちゃんといくつもあるのがさすがRubyKaigiですごい。RGenGCはFluentdにすごい効きそうなので期待したいなあ。
OSS CEP Server 'Norikra' v0.0.1 released! - たごもりすメモ
みんな大好きFluentdはプラグインも自由に書けて好き放題にリアルタイム集計を行うことが可能なわけですが、やりたい処理にあわせて無限にプラグインを書き続けてるとプラグインの数が爆発し何がどんな処理をしているのかもよくわからず混乱の海に呑まれて消えるという未来がみなさんの脳裏にもおそらく想像されていることと思います。 で、世の中にはCEPエンジンというものがあってストリーム状に流れてくるイベントデータに対して処理を行う仕組みがあるわけですね。これ使いたい！ しかもあれだ、簡単に処理が書けるものがいい！ 何が言いたいかと言うとWE NEEEED xQL!!!!!!!!!!!!!!! そんなようなことをこちらのエントリを書いたときに思ったわけです。 http://tagomoris.hatenablog.com/entry/2013/02/19/142017 で、RubyKaigiにも通っちゃ
Fluentd meetup in Fukuokaにいってきた＆しゃべってきた - たごもりすメモ
東京以外で初となる Fluentd meetup が福岡にて行われました。 Fluentd meetup in Fukuoka on Zusaar 福岡で50人規模の勉強会はそうそう無いとのことで、fluentdすごい！ という話。で、スピーカーとしてお呼ばれしたのでいってきた。旅費は(自分で滞在延長した分以外は)某TDさんに出していただきました。ありがとうございました！ しゃべってきた "そのプラグイン、作るや作らざるや"が事前に出したタイトル。資料はこちら。英語で書きはじめたけど微妙な部分もあって日本語をけっこう混ぜた。 Should we write such like plugin or not? from SATOSHI TAGOMORI いまの Fluentd plugin まわりにおいて、プラグイン等がおもにどういうように分類できるか、書くときに何に注意すべきか、そもそも書く
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
fluent-plugin-parser supports LTSV! - たごもりすメモ
乗るしかない、このビッグウェーブに！ Labeled Tab Separated Values (LTSV) ノススメ - stanaka's blog LTSVフォーマットなログを fluentd + GrowthForecast で料理 - naoyaのはてなダイアリー Text::LTSV - naoyaのはてなダイアリー LTSV が行指向な Key-Value フォーマットで捗る話 - naoyaのはてなダイアリー ということで fluent-plugin-parser で 'format ltsv' をサポートし v0.2.0 としてリリースいたしました。 fluent-plugin-parser | RubyGems.org | your community gem host tagomoris/fluent-plugin-parser · GitHub あるキーがLTSVな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
