20110727_AsakusaSCR第参回(#AsakusaReading )

close_yutori @kimukou2628

( #AsakusaReading live at http://ustre.am/z663 ) ・監視インスタンス単位＝＞Agentを立ち上げて＝＞監視、アラート管理 ・DSL・・ジョブ、構成 を書ける

tomo🐧@learning @cocoatomo

RT @nsiena: . @akimatter さん。 「アジェンダ: 01. ビジネス的背景, 02. 0.9系の問題, 03. 2.0の機能, 04. 今後のやりたいこと, 05. OSSとしてのTengine #asakusareading

Yuri Odagiri @ixixi

Monkey Magicで使ってるのはMongoDBだったのか… #AsakusaReading

Mikka @mikka_tech

受けるネーミングって、方向性があるんだなぁって実感したのは浅草を知ってからだなぁ。いや東京浅草も福岡天神も好きですよ。はい。

Hidenori Matsuki @mazgi

@null #AsakusaReading mmの中央サーバーが居て、各エージェントを取りまとめる。監視対象にエージェントインストール？

close_yutori @kimukou2628

( #AsakusaReading live at http://ustre.am/z663 ) MMサーバー ＜＝＞ 各サーバ（Agent）の構成イメージ ・グラフ用 ・監視用 にキューも立っている

close_yutori @kimukou2628

RT @ixixi: Monkey Magicで使ってるのはMongoDBだったのか… #AsakusaReading

Kazuma Andoh @KazumaAndoh

（・∀・）RT @cocoatomo: #AsakusaReading MonkeyMagic は Tengine に改名.

@nsiena

「MM とは、云々 (Getting Start からの引用なので略)。 0.9のアーキテクチャ概要: [各監視対象サーバ上のエージェント群] ←→ [メッセージングキュー群] ←→ [MMサーバ]」.o(小さい∧配色が悪いで見えないよー /_; #asakusareading

や 𝕏 た @yt_tb

Tengine ですね RT @yoshi_567: 天神？Tenjin? ( #AsakusaReading live at http://ustre.am/z663)

Sadayuki Furuhashi @frsyuki

良くあるagent型の管理システムのアーキテクチャか。サーバの単一故障点/ボトルネックの回避が、ありがちな問題か。OpenFlow のスイッチ管理システムも、大体こうなる。 #AsakusaReading

MATSUO a.k.a マッツォ @understeer

RT @ixixi: Monkey Magicで使ってるのはMongoDBだったのか… #AsakusaReading

MATSUO a.k.a マッツォ @understeer

RT @kimukou_26: ( #AsakusaReading live at http://ustre.am/z663 ) MMサーバー ＜＝＞ 各サーバ（Agent）の構成イメージ ・グラフ用 ・監視用 にキューも立っている

close_yutori @kimukou2628

( #AsakusaReading live at http://ustre.am/z663 ) MM鯖からポーリング形式ではなく、子供からプッシュ形式） 理由＞ ・エージェントがたくさんあると想定 ・バックエンドも分散 ・DBはMongo＜スケール可能にする為

tomo🐧@learning @cocoatomo

#AsakusaReading MM は分散性を考えて設計を決定した. それなら個別の agent に細かくアクセスできなくても構わないのかなぁ.

Mikka @mikka_tech

『問題のあるアーキテクチャです』www

Y.M @yoshi_567

monkey magicがTenginecに改名してオープンソースになるということですか？ ( #AsakusaReading live at http://ustre.am/z663)

DJらびたろ @rabitarochan

RT @kimukou_26: ( #AsakusaReading live at http://ustre.am/z663 ) MM鯖からポーリング形式ではなく、子供からプッシュ形式） 理由＞ ・エージェントがたくさんあると想定 ・バックエンドも分散 ・DBはMongo＜スケール可能にする為

@nsiena

「Q/A. ポーリングでなく、エージェントから MQ にプッシュするのは。大量の監視対象が存在するという想定があったから。遅延を減らすためにこのようにした。停止監視とかどうする、など。旧アーキテクチャで改善予定(?)。 #asakusareading

tomo🐧@learning @cocoatomo

#AsakusaReading 監視って監視してる人が死んだり狂ったときが面倒なんだけど, どう設計判断を行っているんだろう?? これから発表されるそうで楽しみ.

AOE Takashi @aoetk

メトリックはポーリングしない理由で、大量の監視対象があるのが一番の理由ですが、当初MMをSaaSとして提供することを考えていたこともあります。 #AsakusaReading

Hidenori Matsuki @mazgi

#AsakusaReading Ust見てる人は質問聴こえてるのだろうか？

@nsiena

「これは旧アーキテクチャであり、今後改善予定(?)」だった。 #asakusareading

close_yutori @kimukou2628

( #AsakusaReading live at http://ustre.am/z663 ) 監視振る舞いに関しては、DSLを書かないと駄目です。 ＜基本テンプレートのDSLとかってあるのかな？

DJらびたろ @rabitarochan

#AsakusaReading DSLでプラグイン的に拡張可能な運用ツールっていうイメージなんだけど、実際はどうなんだろう。