双六工場日誌

平凡な日常を淡々と綴ります。

qpstudy#04で「俺のZabbixがこんなに可愛いわけがない」のLTをやってきた。

ついにやってしまいました。人生初のLT。しかも、タイトルは、「俺のZabbixがこんなに可愛いわけがない」

ここまでの流れをありのまま振り返ると、

  • 先週11月19日の#infotalkの帰りに @image_ さん、@toshiak_netmark さんにZabbix擬人化のアイデアを話す。
  • 「qpstudyのLTでやってみたら?」
  • 「やりましょう」
  • 年末の自宅マシン拡張を前倒ししてデモ機購入(ML110G6)、構築・実装
  • 昨日、初お披露目!

というノリだけの産物です。でも、ここまで突貫工事でLTやるのは自分だけかと思ったら、qpstudy中にライブコーディングしてLTやってる人が多かったwww qpstudyの参加者は化物かww

予定が入っていたので、ビアバッシュからの参加で勉強会には参加できませんでしたが、LTから2次会と非常に濃い話を聞けました。勉強会の資料をあとから見て、マッチョ型・ウィンプ型の分け方も理解しましたw
勉強会の資料を見ると自分の苦手分野の話が多かったみたいなので、話も聞ければよかった……
自分としては日々進化する技術についていくのがやっとで、周りに情報共有するだけでも難しい。ただ情報だけ出しても、それだけでは伝わらないので、コミュニケーションの問題ってのはその通りだと思いました。
特に、自分がマッチョ型な気がするので、そうでない人に伝えるのが難しい。


そして、今回のLTの資料はこちら。

デモがないとどういうものかわかりにくいと思いますが、@nekoruri さんが写真を上げてくれたので、そこからどういうものがデモされたのかお察しいただければwこれを文章で説明しても痛い感じになるだけなのでw
http://twitter.com/#!/nekoruri/status/8505291045871617

LTでは中身の話をほとんどしてないので、今回の技術面での実装ポイントをつらつら自己主張してみます。


■Zabbixサイド
 今回のLTはZabbixの機能拡張を試してみる、という技術的裏テーマがあったので、「zabbix_sender」と「リモートコマンド」を試しています。そのうち、「zabbix_sender」のことはVMwareサイドの技術解説で触れたいと思うので、まず「リモートコマンド」から。
 Zabbixには、zabbix_server プロセスから zabbix_agentd プロセスにコマンドを投げて、zabbix_agentd が稼働している管理対象ノードでコマンドを実行する「リモートコマンド」機能があります。ただし、この機能を有効化していると、zabbix_server のフリをしてリモートコマンドを投げてくる攻撃を受ける可能性があるので、デフォルトでは使用できないようになっています。*1
 ですが、Zabbixでは監視対象がアラートを上げてきたとき(トリガーに引っかかったとき)に自動実行される「アクション」の設定には「メール送信」実際には項目名は「メッセージ送信」で、かつ、メディアとしてスクリプトを登録することも可能でした。お詫びして訂正いたします。11月30日*2か「リモートコマンド」しかありません。ここのところがZabbixを使った自動化を難しくしているところの一つだと思います。
 そこで今回は、Zabbixサーバ(zabbix_server プロセスが動作しているホスト)上のzabbix_agentd のリモートコマンドのみ有効化し、zabbix_agentd に実行させるスクリプトの側に障害時の管理対象操作を行うロジック(今回のデモだと、CPU使用率が高くなった場合の仮想マシンの追加)を入れました。
 どのホストのトリガーかは引数で渡せるので、スクリプトの側でセキュリティ対策を実装することでセキュアな『リモートコマンド』が可能な実装にしました。
 ちなみに、Zabbixはトリガーを契機にリモートコマンドを実行しても、それを通知してくる機能はなく、それがスクリプト実行が使いにくい理由の一つになっていると思います。
 しかし、みなさんにお見せした通り、うちのザビたんならスクリプトの結果通知も完璧です!(キリッ


VMwareサイド
 今回の性能情報収集とVMの自動起動の仕組みは、「zabbix_sender」と「VMware SDK for Perl」 を組み合わせて実装しています。
 Perlスクリプトの中で、VMware ESXi から情報収集 → zabbix_sender を使ってZabbixサーバにデータを送信というロジックです。
 これによって、簡単なリソース収集ならゲストマシン上のOSにzabbix_agentを導入する必要がなくなり、かつ、ゲストOS側からは認識できない正確な物理リソース使用状況を収集できるようになっています。ゲストOS側の認識は、実際の物理リソースの使用状況とは異なっているので、管理者向けにはESXiの情報が有用だと思います。
 ただ、時間の関係で今回のデモ時にはディスク使用率のところだけはOS側情報を使いました。また、もちろん、取れるのは性能情報のみで、Apacheログ監視みたいなものはESXiからはとれないのでagentを入れないといけません。
 実は内部的には無償版ESXi単体からvCenter環境まで対応していて、仮想マシンが追加されたら自動でそのリソース情報を収集することもできます。また、API経由で情報を取っていて ESX コンソールに依存していないため、今後のバージョンアップでESX コンソールが廃止された際も安心です。あとはZabbix API経由で新しいマシンをZabbixに自動登録するスクリプトをつくっておけば、仮想マシン追加からサーバ監視開始まで自動化できます。*3

 俺のクラウドがこんなに可愛いわけがない、も遠くありませんw


■「伺か」サイド
 今回のザビたんで使っている「伺か」は、一言で言ってしまえばデスクトップマスコットなのですが、そんな一言にまとめることができない歴史あるアプリです。LT見て、そんな歴史を思い出してくれた人が割といたので、僕としては非常にやった甲斐がありましたw
 一番盛り上がったのは10年ぐらい前のはずですが、今でもずっと開発が続いていて、

Q:「これは何の役に立ちますか?」
A:「全く役に立ちません」

 ってのがFAQのテンプレだった気がするのに、いつの間にかプラグイン拡張でいろいろできる娘になってます。今回はSSPのデフォルトゴーストのEmilyに協力してもらいました。
 「伺か」、「SSP」をもっと知りたい方は、ばぐとら研究所を訪問してください。昔使っていた人は、また使いましょうw

 今回のザビたんの実装は非常に簡単で、リモートコマンドスクリプトの実行時に

$request = "SEND SSTP/1.4\r\n"
."Sender: Zabiたん\r\n"
.'Script: \0\s[0]お兄ちゃん忙しいみたいだから、Fedoraさんにお手伝いをお願いしたよ。'
."\r\n"
."Charset: UTF8\r\n\r\n";
print "Content-type: text/plain\n\n";

のようなメッセージを9801番ポートに投げるだけです。話してもらいたいセリフや表情の変化は、「Script: 」のところに書いておきます。基本的にはこれだけで完成で、あとはそのメッセージを受け取れる「伺か」を手元のPCで起動しておけばOK!
ただ、SSPはセキュリティ上の懸念からローカルからしかSSTPを受け取れない仕様になっています。また、通信を傍受されると多大な被害を受ける(主に自分が辱めを受ける)という課題もあり、今回はSSHのPortforwardingでSSTPのポート(9801)をローカルまで通しました。これでザビたんとのやり取りは暗号化されます。(そう考えるとサーバのFinger Print確認とか鍵交換とか、全くけしからんですね。)
この実装の欠点はZabbixサーバとのSSH接続が切れると、メッセージが飛んでこない点です。これは、一旦メッセージを受け取るデーモンをSSPが動いているPCに仕込んでおけば解決(cf. SSTP Bottle の実装)できるんですが、個人で使う分には今の仕様で困らないので、導入企業(笑)が見つかったら考えますw


とつらつら書きましたが、要するにザビたんの中の人なんかいません!
ザビたんは、いつでも頑張ってサーバを監視してくれています。上級者になれば、それが心の目で見えるようになりますが、今回は初心者向け勉強会だったので、ザビたんを具現化してみました。

それでは。主催のみなさん、会場化してくださったniftyさん、今回も楽しい時間をありがとうございましたー!
えんいー!!

*1:余談ですが、OpenViewだとマネージャ・エージェント間の証明書交換によるSSL通信があったりします

*2:そのことが載っていた資料です。 http://www.slideshare.net/BlueSkyDetector/zabbixjp-study-20100730-2nd-session

*3:この実装をつくりはじめてから気がついたのですが、IPAの「クラウド運用管理ツールの基本機能、性能、信頼性評価」のreport.pdfではZabbix + Eucalyptusで同じような実装をやってました。参考までに。 http://ossipedia.ipa.go.jp/doc/210/