Librato Metricsをうちではモニタリングに使ってるんですが，日本で全くと言って良いほど記事を見ないので，紹介記事を書いてみる．

何が出来る？

おおまかに分けて以下のようなことが出来る．

• メトリックスを作れる
• メトリックスに対してアラートを設定出来る
• ダッシュボードでメトリックスの一覧が見れる
• JavaScript SDKを使って自分のサイトに埋め込むことが出来る
• APIが提供されていて，いくつかの言語のクライアントがある

以下それぞれ簡単な説明．

メトリックス

LibratoにはMetricというのがあり，これが最小の単位．Metricに監視したいメトリックスの値を入れていき，他のMetricと混ぜたりすることでモニタリングを行います．

上の例のように，一つのMetricに複数の軸の値を入れることが出来ます．これはソースと呼ばれていて，保存する時にsourceを指定すれば良いです．指定しなかったら”unassigned”みたいなsourceにまとめられます．
後，右上にある時間を弄れば，そのレンジでグラフが表示されます．

左の欄に色々とグラフの設定内容があるので，必要であれば弄ります．”How should we aggregate your data over time?”の欄が少し大事で「どういう風にメトリックスを見るか」を指定できます(ここの説明参照)．

Instrument

Metricをまとめるのに，Instrumentというのがあります．ここで複数のMetricを重ねることで，関連のありそうなMetric同士を俯瞰出来るようになります．

単純なモニタリングだけだと，MetricとInstrumentが一対一になったりしてダッシュボードやJavaScript SDKでちょっと面倒だったりもします．

アラート

上の画像の左のカラムが例で，Metricの中でスレッショルドベースで指定出来ます．どこに飛ばすか設定出来るので，うちでは重要なメトリックスに関してはHipChatやPagerDutyなどに飛ばしてます．

複雑な条件設定や，Metricをまたいだアラートは出来ないので，そういうのが欲しい場合は自分達で頑張る必要があります．

ダッシュボード

これがダッシュボードの例です．実際はMetricじゃなくてInstrumentを並べてるんですが，こんな感じで表示出来ます．
ダッシュボードはいくらでも作れるので，自分の見たい粒度で作って，必要なメトリックスを並べます．某社みたいに一つのダッシュボードに数千数万のメトリックスにならないよう気をつけましょう．

API

APIページにリストと説明が載ってます．いくつかの言語には公式のクライアントライブラリがあるので，使うと良いです．
ただ，Ruby版とか試してもInstrument APIがなかったりと，まだまだサポートAPIにばらつきが多い印象．アプリケーションからガチで使うなら，自分でいくつか実装する必要があります．APIはREST + JSONなので，実装はそんなに難しくないです．

ユーザAPIはまだβ機能なのか，使いたい場合はLibartoに連絡して，使えるようにしてもらう必要があるっぽいです．

JavaScript SDK

こんな感じになります．好きなページに貼り付けることが出来るし，グラフは自動で更新されます． どういうコードになるかは，Libratoの記事を参照してください．

Fluentdの例

Fluentdにはfluent-plugin-metricsenseというプラグインがあって，これは保存先にLibrato Metricsが使えたりします． これはクライアント使ってないけど，こんな感じで，直接APIを呼ぶくらいなら簡単に実装できます．

その他

料金

料金ページを見てください．基本的にはデータの流量(これはLibrato側での保存ベース)，メトリックスの数，ソースの数，が影響します．
簡単に言うと，どれだけの頻度でどれだけの数のメトリックスを作るか，です．

サポート

料金ページにも載ってますが，オンラインチャットとメールとコールがあります．うちではOlarkを使ってますが，最近のスタートアップではこの手のオンラインチャットでの対応というのが広まりつつあって良い感じ．
緊急を要したり深いディスカッションが必要であれば，コールすることになるかなと．うちでも少し困ったことがあったので，コールして直接要望出したり設計を相談したりしました．

まとめ

AnnotationとかCRRELATEとか紹介してないのもありますが，Libartoの基本的な所を書いた．自分達でモニタリング環境を構築出来るなら良いんですが，スタートアップとかだとそこにリソースを割くのが難しかったりするので，そういう所はLibratoとか検討してみてもいいんじゃないかと思います．

8/29日に行われたElasticSearch勉強会 第1回に参加してました．ElasticSearchは前々から興味はあったけど，仕事とかで使うこともないのでずっと放置という状態だった．
主催者の方のブログに各発表スライドへのリンクとかあるので，興味がある方はそちらを参照．

発表を聞いて思ったのは，Solrよりも後発なのもあり，運用とかエコシステムの構築に関して，かなり頑張っているなという印象．REST APIでの簡単な操作はもちろんのこと，運用で使えるexplainやelasticsearch-headなど，色々とやりやすそう．
懸念点であるパフォーマンスに関しても，最後のニコ動を使った発表を見るに，かなり改善されて来ているようだ．

インデックスのsharding周りが少し気になっていて，文書IDをユーザが指定できるらしいので，その時のshardの割り当てとかどうやってんのかな，と．
shardの数は途中で変更出来ないらしく，増やしたい時は別のクラスタを使ってjoinみたいなことするようなんだけど，それはそれで重そう．ここはjohtaniさんが調べてくれるらしいので，それを待ちたい所．

次会はCookpadの人がFluentd + ElasticSearch + Kibana3の事例とか話してくれるようなので，次のイベントが楽しみな所． 最近KibanaのページにもFluentdが載ったりしたので，今後も踏まえて実運用の話とか気になってます．

皆さん，お疲れ様でした！

July Tech Festa 2013というイベントが7月14日にAIITで行われ，基調講演として呼ばれたので，Treasure Dataとして発表してきました． Best Speakerにも選んで頂き，ありがとうございます．

Slideshare

Togetter

• JTF全体
• 自分の発表のみ

CTOから無茶ぶりされて「まぁいいか」と承諾したら実は基調講演だったというオチでした．他の発表者の人達がChefやOpenStackなどのいわゆるクラウドやDevOpsプロダクトの中，サービスであるTreasure Dataに講演依頼が来たということは，そういうことなんだろうなと上記の構成になりました．

Treasure Dataのサービスそのものやアーキテクチャに関しては，記事やイベントでぱらぱらと説明はしたものの，おそらくまとまった発表したのは今回が初めてだったんじゃないかなと思っています．こういう場を用意して頂いたJTFの方達には感謝です．

Togetterにまとめられているのを見て貰えれば分かるのですが

• なぜクラウドでやっているのか
• システム構築で気をつけていること
• どう運用しているか

の辺りを大まかに話しました．僕らはスタートアップということもあり速度がとても重要なので，自分達のビジョンを達成するためにどういう選択をしてきたかと，その考え方について一通り述べたつもりです．

懇親会でも色々な方と話すことが出来て，運用で使っているツール周り話したり，実はFluentd使ってるんですよという人にも会えたり，Treasure Dataのようなサービス検討中なんです，などなど色々と楽しい時間を過ごせました． Fluentdなんかはプラグイン機構でガンガンインフラの人にもコード書いて問題を解決してもらおうというプロダクトだったりするので，今後もユーザが増えるといいなという思います．

参加された方々，またスタッフの方々，お疲れ様でした！

フォーラムにポストしてブログで書くの忘れてました！

• プログラミング言語D
• 正誤表 : 誤字や誤訳などあれば，こちらから報告してもらえると助かります

Andreiが書いたD言語本，通称TDPLの日本語版が翔泳社さんから出版されました．俺と原さんが監訳者として参加してました．
翻訳された長尾さんの訳の質も高く，監訳のチェックは技術的なものに注力出来ました．

最初に断っておくと，TDPLはD言語の本であって入門本ではありません． ある程度，他の言語を触っていてプログラミングに関して知っていることが前提になっています．

その変わりと言っては何ですが，単なる文法の説明などにとどまらず「なぜD言語がこの機能を採用したのか」 なども書かれている本になっています．そのため，それなりに読み応えのある本だと思います．
また，Andreiのノリ？が極力残るように勤めました．

TDPL自体は2010年出版ですが，最新のバージョンである2.062までの変更はちゃんとフォローしています． モジュール名含めコードも一部新しくなってますし，新機能に関してはコラムなどで説明しています．
もし何か疑問などあれば，Twitterならば #dlang つけて呟くと，親切なD言語erが答えてくれると思います．

この本が出版されたことで，一つ肩の荷が下りたかなという感じです． D言語を始める始めないに関わらず，どういう言語なのかを知って貰える一冊なのは確かです．

Enjoy D！

P.S.

恒例のアレなリンクです．すでに1ヶ月経ってますが，こちらから買ってもらえると俺が喜びます :)

Amazon

O’Reillyの方からStormをはじめようを献本して頂いて読んだのでレビュー！

感想

最近増えてきている100ページくらいの本なので，さっくり読めました．

簡単にまとめると ”英語は読みたくないので情報が古くてもStormの概要を日本語で読みたい” という方向けの本．

大きな理由は以下:

• Stormの対象バージョンが0.7.1と古い．俺でもTridentというのが0.8から入っているのを知っているので，その辺の目玉機能は書かれていない
• 多分原著の方も少し書き方が雑．なんの説明もなく実装のクラス名を使って説明している所とかあるので「？」となる所がある
  • サンプルコードも少し雑で，使ってない変数があったり説明と実装があってなかったりもたまにある
• 翻訳が少し微妙．Cursorが”カーサー”だったり，原著の方の構成の不味さもあるのか，日本語的に理解しにくい文がちょくちょく混じっている (監訳はいない？)

メッセージングの信頼性に関しては，Storm本家のWikiの方が詳しく書かれていたりするので，本当に「Stormってどういう構成でどういう感じに機能追加するんだろう？ユースケースとかは？」みたいなのを日本語で読みたい場合には，とっかかりにもなるし，これで十分な感じ．

英語が読める人は，本家のWikiとか漁った方が情報も新しく結構細かに書かれているため，そちらの方が正確かもしれない．

正誤表

読んでて気になった所はgistにまとめておきました

Stormをはじめようのerrata

Stormについてのてきとうな所感

• NimbusはImpalaのstatestoreみたいな感じで，最初はいるけど落ちても致命的ではない

• Tupleは基本単体で送られて，それぞれにトポロジーのack tracker(Acker)がついてトラッキングされる

  • tupleが増えるとAckerも増え，数が増えると結構重そうに見えるけど，そこんところどうなのか
  • 再送は基本Spoutが判断．まぁこれは分からなくもない

• 0.8からのTridentはBatchをガリガリ使っていると聞いてるけど，通常の利用だとあまりない？ 1 Tupleでトポロジー内forwardしまくるのは結構パフォーマンス的に厳しそう

• トランザクションはSpout / Boltの両方が頑張る．この辺は今時のストリーミング処理系と同じ．コアで担保は難しい

• 各ワーカーのコアのメソッドはシングルスレッドで呼ばれるようなので，この辺で重い処理すると多分詰まる．at-least-onceっぽいので，多分これが連鎖するとデータ重複する．

• multilangはHadoop Streamingと同じ

• ZooKeeperに依存しているので，そこがまた面倒くさそう

とりあえずこんな感じ．0.8や0.9でもっと改善されているかもしれないので，その辺は必要があれば追う．