Ganglia + Nagios でメトリクス収集 + 監視をしている場合のリモートサーバに対する独自な監視
とりあえず書いておく。
- Ganglia gmetric をキックする処理を書く
- 単に gmetric をキックするだけでよい。あとは gmond + gmetad がなんとかしてくれるし、その後は check_ganglia.py に乗っかれば良い。
- gmetric はちゃんと man を読むべし。ググって頭の方に出てくるのは古い情報のようだ。
- やり方にもよるのだろうが、極めてやっつけ感が高く、結果、これホントにメンテすんの？感も高い
- 推移を見たい場合かつラクに済ませたいならこれしか選択しないのでは。
- Nagios NRPE と各種 Nagios Plugin を使う
- 監視対象のリモートサーバに NRPE をインストールする必要がある
- SSL を使う場合、 openssl, openssl-devel もインストールする必要がある
- 全サーバに共通の仕組みたるコード群はおいておきつつも、その呼び出し方は Nagios 本体側のサーバに委ねられているので、管理しやすさ高い印象
- いきなり Nagios なので、推移を見ることはできないが、それでいいケース（例えば固定的なプロセスの数のチェック）であれば問題なかろう。
- 結局、各サーバの nrpe.cfg を適切に各必要がある。が、これは全サーバ共通にしておけば、運用コストは低かろうし、ふつうそうなる。
- NRPE 自体は RPMFORGE にもあるので、それで簡単にインストールできる
- Nagios のプラグインは、極めて簡単なルールに則ってさえいればよいものなので、実はとてもラクで柔軟性も極めて高い
- Nagios check_by_ssh でリモート側の処理を任意に呼び出す
- Ganglia で独自のメトリクス収集モジュールを実装
- ネイティブよりの話。よく知らん。
- これも、ここさえやってしまえば、あとは check_ganglia.py とそれの呼び出しでよい。
- Nagios check_snmp + SNMP で返す処理
Hadoop + Ganglia 3.1.x + Nagios
なぜそうするのか
- Hadoop のメトリクスはファイルに書き出すこともできる（FileContext を指定すればよい）ので、それを読み込むとかでもいいんだろうが、せっかく GangliaContext, GangliaContext31 が用意されているので、それを使って Ganglia がメトリクスを収集した方が圧倒的にラクなようだから。
- 収集したメトリクスの監視に Nagios を利用するのも、 Ganglia が check_ganglia.py という Nagios 用の監視スクリプトを提供していて、極めてかんたんに導入できるから。
- Hadoop徹底入門にも Ganglia によるメトリクス収集が紹介されているから。
導入や設定の手順
マルチキャストを使うことの是非
- 是非と書いたものの、是非を挙げられるほどわかっていない。
- とりあえずは、ユニキャストでひとつの gmond に集めた場合、それが落ちれば、即座にメトリクス収集ができなくなるが、マルチキャストしておけば、そのマルチキャストグループに属する他のホストを見るように直せばよいだけになる。
- gmetad が見ているホストが落ちたかどうかは、別途、動かしている Nagios で検出すればよかろう。もちろん、冗長化として、Virtual IP を振って、というのもあるかもしれないが、そのあたりは言及できるほどには知らない。
- 天邪鬼に、手動で複数のホストにユニキャストで、というのもああるが、それやるぐらいなら素直にマルチキャストにする方がラクだろう。
