◆ Munin 2.0 (stable) が遂にリリース！

“リソース推移のモニタリング”  ただ、それだけに特化した、監視ツール Munin 。設計思想は、シンプルかつパワフルに。

Munin は、サーバの「リソース推移」を見るためのツール。簡単なセットアップで、ブラウザを通して、サーバの中の様々な状況を、グラフとして見ることができる。例えば、CPUの使用状況や、メモリ、ディスク等々。障害通知の機能は最低限。あくまでリソース推移を簡単に見ることに特化。

単純に数値を見るだけなら、sysstat(sar)や各種のログを見る事でも目的は達成できる。しかし、障害発生の現場においては、複数のサーバから、複数の指標を取得＆比較し、迅速な対応と判断が求められる。そこでは、ログの追跡は時間や人手がかかる。一方、グラフで障害発生ポイントを、視覚的に、迅速に把握できるようになる事は、原因切り分け時間の短縮に、貢献する。まさに Munin が力を発揮するシーンだ。私は、もう仕事でMuninを手放すことが出来ない。

そんな Munin の最新 2.0 stable が、一年以上もの開発期間を経て5月30日(米国時間)、遂にリリースされた。

SourceForge からダウンロード可：http://sourceforge.net/projects/munin/files/stable/2.0.0

2.0 の画面サンプルは、こちらで公開している。対象サーバは、このブログが動いている僕の個人鯖。実際にグラフのズーム機能や、動的生成されるグラフの速さを体感できるだろう。

インストールの仕方については、先日のエントリを参考にしてほしい。まだソースのみの提供だが、じきにパッケージも作成されることだろう。

さて、今日の投稿は、バージョンが 1.4 から 2.0 になり、何が変わったかに焦点を絞る。

◆「俺のMuninがこんなに軽いわけがない」 Munin 2.0 は 1.x 系の正統進化。

CPUリソースの拡大表示

Munin 2 は、従来の Munin 1.x 系の正当進化が伺える。特に、スケーラビリティ（拡張性）を意識した設計思想。動的にグラフを生成する機能や、グラフをズームする機能も標準搭載されている（ズーミング機能は、先日のエントリを参照ください）。

その中でも、一番変化が体感できるのが「軽さ」であろう。Munin 1.x 系は、対象ノードが増えると、とにかく重かった。重いのは、I/O 性能劣化という、構造上の原因があったからだ。

１つは、munin-master のグラフおよび HTML の生成。５分に一度、グラフと HTML ページを全て生成していた事が大きい。そのため、ノード数が増えると、誰かが見ているかどうかに拘わらず、常に画像を生成している状態だった。そのため、慢性的に munin-master が稼働しているサーバは、高負荷に悩まされることになる。

この問題に対しては、動的なグラフ生成機能(1.4以降)がサポートされた。しかし、CGI を使った実装は試験的なものであった。動的な生成により、サーバの負荷は下がったものの、閲覧者は遅いグラフ表示にイライラさせられる。まさに、諸刃の剣でもあった。対して、2.0 では、FastCGI 機能の実装が進み、動作が非常に軽快になっている。

もう１つは、プラグインのデータ取得方式の改善。従来は、１つ１つのノードに対して、順番にプラグインを実行していた。そのため、単純にノード数やプラグインが増えると、データ取得に時間がかかっていた。バージョン1.4 では並列読み込みが実装され、遂に2.0 では非同期読み込みが実装された。これにより、プラグインの処理に時間がかかる（ディスクI/O測定など）ものがあっても、他のノードやプラグインに影響を与えないような仕組みとなる。

このように、Munin 2 は、構造的に軽くなるような改良が施されている。

本当に動作が軽いかどうか、実際に画面をみていただきたい。以下 URL では、動画生成の状況を確認できる。動作しているサーバは、2世代前のスペックだ（Core 2 Duo P8600、2.40GHz、メモリ 2GB、SATA）

ちょっとこいつを見てくれ・・・どう思う？
http://node1.pocketstudio.net/munin2/pocketstudio.jp/www.pocketstudio.jp/index.html

2.0 を使い、思わず脳裏に浮かんだ言葉が、これである。

「俺のMuninがこんなに軽いわけがない」

同じサーバで、かつて 1.4 でグラフの動的生成していたが、ここまで軽いと感じることは無かった。

続いて、以下、新しく実装された機能を１つ１つ追って見る。

◆Native SSH 機能のサポート

一般的な Munin の構成は、munin-master (データ収集・グラフ描画)と、munin-node（エージェント）による､クライアント・サーバ構成である。通信は、TCP Port 4949 （デフォルト値、変更可能）を通しての、平文通信である。以下、一般的な構成図。

そのため、途中にファイアウォールがある構成ではポート 4949 を空けなければいけなかったり、ローカルネットワークが組まれている環境でも、工夫が必要だった。

少々脱線するが、ローカル環境側 Database サーバから情報取得する方法はある。iptablesで IP マスカレードと DNAT の設定を行う方法だ。たとえば、グローバル IP アドレスを持つ環境の、ポート 4950 を、ローカル側の 192.168.10.2 のポート 4949 にアクセスさせたいときは、次のように iptables を実行する。

# /sbin/iptables -t nat -A PREROUTING -s 0/0 -p tcp –dport 4950 -i eth0 \
-j DNAT –to-destination 192.168.10.2:4949
# /sbin/iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

ただし、通信はあくまで平文である。

そこで、Native SSH が登場する。2.0から搭載された機能によって、後述する munin の Proxy 機能も実装できるようになった。

Native SSH は、SSH 経由で munin のデータを取得できるようになる。具体的には munin.conf における、munin-node の記述方式が変わる。

[RemoteNetwork;frontend-web]
    address ssh://210.129.154.192/usr/bin/nc 127.0.0.1 4949

通常、address ～の記述にはホスト名か IP アドレスが入る。しかし、設定さえ行えば、上記のように、netcat(nc)経由で、ローカル(127.0.0.1)のポート 4949 を通し、データを取得できるようになる。当然、通信は SSH 経由なので、ファイアウォール配下の munin-node だとしても、不用意にポートをオープンする必要は無い。セキュリティ保持という意味でも、この機能の役割は大きい。なお、実際の動作には、muninアカウントによる、SSH 鍵認証の設定が必要となる。

◆プラグインの非同期通信とデータ取得、そしてPROXY機能

Munin 1.2 までのバージョンは、munin-node のデータ更新に根本的な問題があった。それは、ノードからのデータを逐次処理するしかできない点である。そのため、ノード側の応答が遅いと、munin-master 側のアップデートが追いつかず、データが欠損しグラフが欠けるという事が有り得た。

さらに、監視対象の munin-node が増えると、データ取得に時間がかかるようになってしまう。そのため、中規模・大規模な環境向けや、拡張性に Munin は問題があると言われてきた。

そこで、version 1.4 では並列データ取得(Parallel Fetching) の機能が取り入れられた。これは、複数のノードに対して同時にデータを取得しにいく方法である。

一見これでデータ取得の問題は解決されたかのように見えたが、新たな問題が浮上する。それは munin-master 側の I/O に関する課題。munin は、RRDtool をベースに開発されている。そのため、大量の rrd ファイルに対するランダムな I/O のため、サーバの負荷になってしまう。

そして、2.0 ではこの問題に対処すべく、Stateful plugin（ステートフル・プラグイン：情報保持型）と、Asynchronous proxy mode（非同期プロキシモード)が実装された。

Stateful plugin は、プラグイン自身がデータを保持することができるようになる。munin-update によるアクセスが munin-node に対してあったときに実行されるのではなく、予め取得した値を返すようにする事ができる。ただし、プラグイン自身の改造が必須である。

そしてもう１つが非同期プロキシモード。これは、プラグインを改造しなくてもよい。従来の munin-master と munin-node に成り代わり、munin-async-server と munin-async-client が介在するようになる。

大きく違うのは、munin-mater の通信先が munin-node ではなく、munin-async-client である点。また、munin-async-server を介在させることで、分離されているネットワーク上のデータも、取得出来るようになっている点である。

async という名にあるとおり、munin-async-server は、munin-node から非同期にデータを取得するように設計されている。また、プラグイン毎に、データ更新の間隔を変化させることも可能だ。例えば、トラフィックや CPU の推移は60秒毎だか、変化の少ないディスクの容量は300秒（デフォルト）のまま、のような設定も可能である。

munin.conf の記述も、非同期プロキシを使うときは少し工夫が必要だ。具体的には次のような記述が必要となる。

[RemoteNetwork;backend-DB]
    address ssh://210.239.46.254/opt/munin/lib/munin-async-client --spooldir /var/opt/munin/spool/192.168.0.230 --spoolfetch
    use_node_name yes

先ほどの Native SSH のような記述を踏襲する事になる。また、データを取得するため、munin-node 内（図中 munin-node α) では、munin-async-server をデーモンとして常駐させる必要が有るので、注意が必要だ。

なお、Native SSH および 非同期更新(munin-async-server および munin-async-client )の具体的な記述方法は、改めて投稿する。

◆データ互換性について

Munin 1.x 系と 2.0 系は、データ構造が一緒である。なので、1.x -> 2.0 へのアップグレード、2.0 -> 1.4 へ戻すことも可能だ。もし、不具合が出るようであれば、戻すこともできるので、比較的安心であろう。このあたりは、UPGRADING を参照して欲しい。

アップグレードすべきかどうかについては、バイナリパッケージの配付はまだのようなので、慣れない方は待ったほうが良いかもしれない。なお、開発者ブログには、次のように書かれていた。

「1.4 系ユーザは、躊躇無く 2.0 にバージョンアップすべきである」
( 原文：you can use it right away in the 1.4.x series)

◆今日、伝えたかった事

今日の書き込みは、多くの運用現場の方に、Muninの事を知って貰いたい、そして、Munin を通して、運用現場の負担を減らせたらいいなと、そういう思いを込めたつもりだ。

世の中には、様々な監視ツールや運用支援ツールが存在している。繰り返しとなるが、その中でも、Munin2 は「リソース推移の変化」に特化しているのが大きな特長だ。しかも、取り扱いが、比較的簡単である。データベースのセットアップも必要なければ、エージェントのコンパイルも不要である。

私自身、既に Munin 2.0 αの頃から使っている。個人的な趣味でなく、私の仕事（ホスティングサービス）における、業務上の運用支援ツールとして、実戦投入済みである。Munin単体だけでなく、Nagiosベースの統合監視ツールとを併用している。Muninは障害発生前後の対応に、Nagiosは通知用にと役割を分けている。

このあたり、仕事でどのように Munin を活用しているかは、改めてblogに投稿するつもりだ。機会があれば、どこかの勉強会で LT させていただけると、とってもうれしいかなって。

さて、ひとまず第１回は概要のみ。次回は、具体的な Native SSH および 非同期プロキシの利用法について記述する。

Munin（ ＾ω＾）ﾍﾟﾛﾍﾟﾛ　←結論

◆References

Waiting for Munin 2.0 – Introduction – Personal Workflow Blog
http://blog.pwkf.org/post/2010/06/Waiting-for-Munin-2.0-Introduction

/tags/2.0.0/ChangeLog – Munin – Trac
http://munin-monitoring.org/browser/tags/2.0.0/ChangeLog