判ったつもりのmunin wildcard plugin

munin node は基本的にlocalhost内部からしかデータを取れず、sshで接続できないような所からのデータは、pluginを書いて間接的に取り出すしかないらしい。amazon RDS とか amazon ELB とか。
http://munin-monitoring.org/wiki/HowToWritePlugins

複数台対応の場合はwildcard pluginを書くしかないらしいのですが、いきなりスクリプトソースしかなくて、オフィシャルドキュメントですら「手段」の話までbreak downしちゃてるので、要するにどうやるの？が判らなかったのですが、ようやく解読できました。

http://munin-monitoring.org/wiki/PluginWildcard

• munin pluginはファイル名自身が全て
• 引数を取ることは出来ない。
• 厳密には後述のwildcard configのために"config"文字列をとる場合はある
• 引数を取らない場合は、標準出力にいきなり結果を返す
• munin-node経由であれば、マスタにそれが返る
• 全く同じ機構で、複数の接続先がある場合は、wildcard pluginを使うしかない
• plugin-confは、特定のファイル名のpluginに対して、環境変数等の初期値の設定に使う
• env.user は、実行アカウント指定
• env.* は、環境変数の初期値指定
• つまりpluginの機能が要らない場合、confをコメントアウトしても意味なかったという、、
• munin-node.confのignoreを使うらしい
• wildcard plugin
• 本体スクリプトはファイル名の末尾が下線で終わらなければならない
• munin-node-configは、そのファイル名に反応して、「ああwildcard pluginデスネ」と解釈する※らしい
• 例えばSATA HDDのSMART情報をとるpluginの場合 http://munin-monitoring.org/wiki/PluginPortrait/smart_ http://munin-monitoring.org/browser/munin/plugins/node.d/smart_.in
• smart_が本体で
• 前述のconfigを返す場合がある
• smart_sdaとsmart_sdbでsymlinkを張る
• SATA HDDの場合は、/devを見れば必要な情報を引っ張れるので、手動に頼らなくても適切なファイル名を作れる可能性がある。それが(auto) config
• smart_sdaとしてスクリプトを実行する場合、末尾hdaを切り出して「sdaへの処理デスネ」と解釈する※らしい
• 系列ひっくるめて環境変数を与える場合は
• 前述のsmart_の場合は、plugin-conf.d/* で [smart_*]で指定する
• 標準のMySQL系が [MySQL*] になってるのは、個々のパラメタ毎に複数プラグイン構成になってるからで、認証情報は共通だという前提による。

30秒でわかったつもりのmunin

出稼ぎでmuninの設定をした（しかし使わなかった）のですが、シンプルって評判で、たしかにシンプルではありましたが、意外とハマったので、他所様のブログ等で言及してないことを重点的にメモります。※大概localhostで試して「わーい動いた動いた」で終了って記事だったり、step-by-step式で、「解説として」は冗長だったり。

時間が10分ぐらいおありの場合はこちらをどうぞ http://www.slideshare.net/zembutsu/practical-resource-monitoring-with-munin

1. 中身の大部分がperl
1. CPANがドッサリ付いてきます
2. そのアンチテーゼとして軽量互換も存在します https://github.com/munin-monitoring/contrib/tree/master/tools/pmmn/
2. 集約サーバ(マスタ?)とノードの2構成になってる
1. 大概のディストリビューションでは別パッケージになってる。
2. 片方だけでも動く※筈
1. もちろんノードだけではグラフは見られない。慌てるな。
2. ノードのポート4949を叩いてプロトコルを喋ればデータは取れます
3. munin自身の最終的な出力はhtmlと画像ファイルだけなので
1. 厳密にはapacheじゃなくても良い
2. ※apacheのインストールとセットで紹介してる場合が非常に多いが
3. munin-cgiとかは、一部のグラフ画像のリアルタイム生成に使うっぽい
4. マスタからノードに接続して、データを引っ張るタイプ
1. 故にサーバ側にノード一覧記述がある
1. 小生は /etc/munin.conf に書いたが
1. [グループ名;サーバ名] 
2.  address 接続先定義
1. sshトンネルとかも行けるらしい
3.  use_node_name yes
1. 中級の運用ではたまにnoとか書くらしい
2. /etc/munin.conf.dに
1. ノード毎にファイルを置くのが想定運用らしい
• amazon ec2はインスタンス立ち上げでプライベートIPごと変わるが何かよい方法は無いものか？
• MongoDBのreplciasetsにも通じる議題
• 大概は、「elastic IP使うとイイよ」に落ち着くらしい
• それもどうかと
2. 故にノード側に、マスタからのアクセス制限記述がある
1. デフォルトの記述ではamazon ec2のクラスBプライベートに対応してない
2. 基本ホワイトリストで、「許す」方を記述する
1. 正規表現表記があるが、
2. cidr表記と、
3. ディストリビューションパッケージで入れるとcidrで認識する場合が多いので
4. cidr_allowを書く
3. マスタからノードにtelnet 接続先 4949で動作確認
1. 成功すれば、1行目にノードバージョンっぽい文字列が出ます
2. 前述の通り内蔵アクセス制限があるので、まずはlocalhostでも telnet 接続IP 4949でテスト優先
5. ホスト側はcronで、スクリプトがブン回るだけ
1. 急ぎだったら手動起動しても可
1. /var/cache/munin/www とかにhtmlを出来る※ubuntu系
2. /var/lib/munin にノードデータ履歴を保存する※ubuntu系
3. データの引き継ぎは履歴ファイル名ありきなので、IPが変わっても履歴継続することは可能らしい。round robbin datafile とか言うらしい rrd
6. プラグインはノードに設置するらしい

以上の内容を読み返してみると、まあ30秒ぐらい？