Muninの構造

munin-node デーモンは監視側からの計測要求を受けると、各種の計測を行う小さなプログラム (Munin プラグイン)を実行し、その結果を送り返します。
Munin プラグインは、CentOS で yum からインストールした場合には /etc/munin/plugins ディレクトリに配置されます。
FreeBSD で Ports からインストールしたときは /usr/local/etc/munin/plugins です。

まずはプラグインディレクトリを覗いてみましょう。(CentOSの例)

中身はシンボリックリンクばかり、どれも同じディレクトリ(/usr/share/munin/plugins)にあるファイルを参照しています。

実は、標準添付の Munin プラグインの実体はすべて /usr/share/munin/plugins ディレクトリにインストールされていて /etc/munin/plugins には作動させたいプラグインへのシンボリックリンクを置く、という仕組みになっています。

ほとんどのシンボリックリンクは実体のファイルと同じ名前で作られています。
実体のファイル名がアンダースコアで終わっているもの(if_err_, if_ など)は、何かがプラグインファイル名に くっついた名前でシンボリックリンクが作られていますが、これは、監視対象(ネットワークデバイスなど)を 連結した名前でシンボリックリンクを作成することで、ひとつのプラグインが複数の監視対象を別々にグラフ化する 場合に用いられる方法です。

最初に Munin をインストールしたままの状態だと、ケーブルがささっていないネットワークデバイスなど、監視の 必要がないものまでグラフ化されているはずです。

そこで、まず不要なプラグインを外していくところから始めてみます。
今回は eth0 以外のネットワークデバイスと、MTA に Postfix を採用しているので監視の必要がない Sendmail 関連の プラグインを外していきます。
と言っても、作業はシンボリックリンクを削除するだけです。

# rm /etc/munin/plugins/if_err_eth[12] /etc/munin/plugins/if_eth[12]
# rm /etc/munin/plugins/if_err_eth[12] /etc/munin/plugins/if_eth[12]
# rm /etc/munin/plugins/sendmail_*

munin-node の設定を変更したときは、稼働中の munin-node を再起動するまでは設定内容が反映されません。 忘れずに再起動しておきましょう。

# /etc/init.d/munin-node restart
Stopping Munin Node agents:                                [  OK  ]
Starting Munin Node:                                       [  OK  ]

少し待ってからブラウザで Munin の出力を見てみると、グラフの数が少なくなっているのが確認できます。

次に、新しいプラグインを導入してみましょう。
今回は Apache、MySQL、Postfix を監視するプラグインを追加してみます。
と言っても、削除と同様にシンボリックリンクを作成するだけです。

#ln -s /usr/share/munin/plugins/apache_accesses /etc/munin/plugins/apache_accesses
#ln -s /usr/share/munin/plugins/apache_processes /etc/munin/plugins/apache_processes
#ln -s /usr/share/munin/plugins/apache_volume /etc/munin/plugins/apache_volume
#ln -s /usr/share/munin/plugins/mysql_bytes /etc/munin/plugins/mysql_bytes
#ln -s /usr/share/munin/plugins/mysql_queries /etc/munin/plugins/mysql_queries
#ln -s /usr/share/munin/plugins/mysql_threads /etc/munin/plugins/mysql_threads
#ln -s /usr/share/munin/plugins/postfix_mailqueue /etc/munin/plugins/postfix_mailqueue
#ln -s /usr/share/munin/plugins/postfix_mailstats /etc/munin/plugins/postfix_mailstats
#ln -s /usr/share/munin/plugins/postfix_mailvolume /etc/munin/plugins/postfix_mailvolume

忘れずに munin-node を再起動して、少し待ってからグラフを見てみましょう。
プラグインを追加した分だけ、グラフが増えているのが確認できます。

/usr/share/munin/plugins ディレクトリの中を見てみると、ほかにもいろいろ役に立ちそうなプラグインが 見つかると思います。

グラフが出ないときは

もしかすると、書いてある通りに設定してもグラフに何も出てこない!!とお怒りの方がいるかもしれません。
そこで、そのような場合の対処法についても説明します。

まず、グラフのタイトルだけが表示されていて画像が出てこない場合ですが、これは munin-node がプラグインの 実行中にコケて何も返せなかった状態が考えられます。
通常インストールした状態で運用されていれば、/var/log 以下のどこかに munin-node のログファイルが 作成されているはずなので、そちらをあたってみるのが解決の近道です。

次に、グラフの画像は表示されているのに、数字がすべて非数(NaN)になっているケースがあります。
これは、Munin プラグインの実行は正常に完了していても、有効な計測値が得られていない状態が考えられます。
こちらのケースについても、munin-node のログファイルに解決のヒントがあるはずです。

もっともこれだけでは不親切なので、先ほど追加したプラグインを導入したときに起こりそうなトラブルについて 解決方法を紹介しておきます。

1.Apache の場合

Apache を監視するプラグインは、実は Apache の mod_status モジュールにアクセスし、結果を返す仕組みに なっています。
Apache をインストールしたときに、この mod_status が組み込まれていなかったり、組み込まれていても アクセスが拒否されていたり、Munin プラグインが期待する情報を返していないと、munin-node が値を返せない 状態になります。

Apache の設定を確認して、1)mod_status モジュールが組み込まれていること、2)localhost(127.0.0.1)から /server-status へのアクセスを許可していること、3)ExtendedStatus ディレクティブが On に設定されていること、 を確認してみてください。

2.MySQL の場合

MySQL を監視するプラグインは、mysqladmin コマンド経由で実際に MySQL データベースに接続して情報を取得します。
このとき、mysqladmin コマンドに PATH が通っていなかったり、MySQL の root ユーザーにパスワードが設定されて いたりすると、Munin プラグインは情報を取得することが出来ません。

実は、/etc/munin/plugin-conf.d ディレクトリ以下に Munin プラグインの設定ファイルがあり、ここに設定を記述 しておくことで、プラグインに実行時オプションを渡すことができます。
※FreeBSD の場合は /usr/local/etc/munin/plugin-conf.d ディレクトリ
※設定ファイル名はOS環境によって異なります。各自の環境で確認してみてください。

以下は mysql のプラグインについての設定例です。
mysqladmin コマンドがインストールされているパスと、MySQL ユーザー名とパスワードをそれぞれ設定しています。

[mysql*]
env.mysqladmin /usr/local/bin/mysqladmin
env.mysqlopts --user=muni --password=hogehoge

1行目で、設定を適用するプラグインをmysqlで始まる名前のプラグインに限定しています。
2行目以下は Munin プラグインに環境変数を渡すときの書き方です。mysqladmin と mysqlopts という環境変数を セットしています。

3.Postfix の場合

Postfix を監視する Munin プラグインは、実は /var/log 以下にあるログファイルを解析して、その 結果を返すようになっています。
munin-node は一般ユーザー権限でプラグインを実行するため、ログファイルへのアクセスにroot権限が ないと必要な場合には結果を返すことができません。

この場合も、munin-node の設定変更によって問題を解決できます。
MySQL のときと同じように、プラグインの設定ファイルに以下の設定を書き加えます。

[postfix*]
user root
env.logdir /var/log
env.logfile maillog

1行目で、以下の設定の適用範囲を"postfix"で始まる名前のプラグインに限定しています。
2行目では munin-node がプラグインを実行するときのユーザーを指定しています。
3行目以下ではプラグインが参照するログファイルが置かれているディレクトリとログファイル名を指定しています。

このように各プラグインの設定を行い、最後に munin-node を再起動すれば、今度こそグラフが見られるように なっているはずです。

もし他にこのような問題に遭遇したときは、プラグインのソースコードを読んでみてください。
大抵は Perl で書かれた小さなプログラムです。
各プラグインが参照する環境変数についても、ソースの冒頭でコメントしてあるはずです。

また、いちいちグラフが更新するまで待たないと設定を確認できない、というのは非常に不便ですが そういうときのために、munin-run コマンドが用意されています。
下記のようにプラグインの名前を引数で渡すと、指定したプラグインを実行してくれます。

# munin-run apache_access
accesses80.value 182410

もっとプラグインを増やしたいときは

標準添付のほかに、色々なプラグインを集めた MuninExchange というサイトがあります。
MuninExchange http://muninexchange.projects.linpro.no/

"Search"をクリックして検索画面を開き、カテゴリーと対象のOSを選ぶとプラグイン名の一覧が出てきます。
一覧からプラグインを1つ選ぶと、簡単な紹介とグラフのサンプル、コメントが見えます。
気に入ったプラグインがあったらダウンロードしてみてください。

社内では、この中から apache_activity、mysql_qcache、 mysql_qcache_mem、passenger_status、memcached 系の各種プラグイン などを追加しています。

このあと更に続きます。

今回は、Webサイトの運用・保守に欠かせない監視ツールの話です。

最近、当事業部では監視ツールにMuninを採用し、続々と監視範囲を拡大しているところです。 まずは Munin のインストールと初期設定について紹介します。

Muninについて

Munin の構成ですが、監視対象のサーバー側で各種の情報を計測するノード(munin-node)とmunin-node が計測した情報を定期的に収集してレポートを生成するプログラム(munin)に分かれています。

munin-node はデーモンとしてサーバーに常駐し、munin は通常5分間隔で munin-node を巡回します。
このとき、通常は TCP/4949 ポートが使用されます。

今回は munin を CentOS5 に、munin-node を、CentOS5 と FreeBSD 7.1 にそれぞれインストールしました。

CentOS の場合は、RPMforge から yum で簡単にインストールできます。

# yum --enablerepo=rpmforge install munin munin-node

FreeBSD の場合は、Ports からインストールできます。

# portinstall sysutils/munin-node

今回は munin-node だけですが、munin もインストールするときはこのように行います。

# portinstall sysutils/munin-main

どちらも、依存している RRDTool や各種 CPAN modules と一緒にまとめてインストールが完了します。

初期設定

まず最初に munin-main 側の設定を行います。

CentOS の標準では、munin が HTML のレポートを生成し出力する先は /var/www/html/munin/ 以下になります。
とりあえず標準設定のまま munin のレポートが生成されるように、出力先ディレクトリの所有者を変更しておきます。

# chown -R munin:munin /var/www/html/munin

また、Apache の DocumentRoot を /var/www/html 以外に設定している場合や /munin 以外のパスでレポートを公開したいときは、Apache の Alias 設定が必要になります。
CentOS の yum でインストールすると、標準では /etc/httpd/conf.d/ に munin.conf というファイルが作られているので、このファイルに Alias の設定を追加します。

Alias  /munin/  /var/www/html/munin/

次に、munin に監視するサーバーを認識させるための設定を行います。
CentOS の場合、/etc/munin/munin.conf が munin の設定ファイルになります。
まず munin が動作するサーバー自身を監視対象に加えるには、munin.conf に以下の情報を追加します。

[munin.local.oro.co.jp]
    address 127.0.0.1

次は FreeBSD サーバーを監視対象に加えるときの設定例です。

[freebsd.local.oro.co.jp]
    address 192.168.7.1

最後に、munin-node を各サーバーに常駐させます。
まず CentOS の例です。

# /etc/init.d/munin-node start

次は FreeBSD の例です。

# /usr/local/etc/rc.d/munin-node.sh start

ここまで終わったら、10分ほど待ってから munin が出力したレポートを見てみましょう。
ブラウザで http://munin.local.oro.co.jp/munin/ を開いてみましょう。
うまくいっていれば、きれいなグラフ入りのレポートが見られるはずです。

では、続きは次回。

私はオロに入社してから1年半、システムのログを確認したり、サーバを監視したり、プログラムを書いたり、動作検証をしたりする毎日を過ごしています。

オロに入社する前に何をしていたかというと、人一倍長く学生生活を過ごしておりました。

チーム開発で大切なこと

大学でプログラムを書いていたときと、会社に入ってプログラムを書くことの大きな違いはチーム作業であるということ。

学生さんは自分の研究は自分だけがソースコードに手を入れるという状況が多いかと思いますが、会社ではほとんどの場合、プロジェクトチームが組織され、バージョン管理システムを使って、共同でシステムを組み上げていきます。

また、バージョン管理システムと連携してプロジェクト管理を行うことができるシステムに、Trac、Redmine等があり、作業の担当割当や進捗の管理、ソースコードの閲覧等が行えます。

現在はSubversionとRedmineを使って開発を行っていますが、慣れると非常に便利です。

個人で開発を行うときにも役に立つことは多いので、これから何か作ろうとしている方や学生さんもどんどん使ってみるとよいと思います。

それぞれのツールの便利な使い方については次回以降に。