Hadoop + Ganglia 3.1.x + Nagios

概要

  • Hadoop のメトリクスを Ganglia 3.1.x で収集し、さらにそれを Nagios で監視する件。

なぜそうするのか

  • Hadoop のメトリクスはファイルに書き出すこともできる（FileContext を指定すればよい）ので、それを読み込むとかでもいいんだろうが、せっかく GangliaContext, GangliaContext31 が用意されているので、それを使って Ganglia がメトリクスを収集した方が圧倒的にラクなようだから。
  • 収集したメトリクスの監視に Nagios を利用するのも、 Ganglia が check_ganglia.py という Nagios 用の監視スクリプトを提供していて、極めてかんたんに導入できるから。
  • Hadoop徹底入門にも Ganglia によるメトリクス収集が紹介されているから。

図

導入や設定の手順

  • Hadoop徹底入門の第8章を読めば大体わかる。この際、 OS もその内容に合わせ、 CentOS5 系であれば圧倒的にラクになるはず。むしろ CentOS4 系でどうなるかは知らない。
  • man gmond.conf を読めば大体わかる。大した英語ではない。
  • その他、 Hadoop にしても Ganglia にしても Nagios にしても、公式ドキュメントをまずは読めば大体わかる。大した英語ではない...ような気がする。

マルチキャストを使うことの是非

  • 是非と書いたものの、是非を挙げられるほどわかっていない。
  • とりあえずは、ユニキャストでひとつの gmond に集めた場合、それが落ちれば、即座にメトリクス収集ができなくなるが、マルチキャストしておけば、そのマルチキャストグループに属する他のホストを見るように直せばよいだけになる。
  • gmetad が見ているホストが落ちたかどうかは、別途、動かしている Nagios で検出すればよかろう。もちろん、冗長化として、Virtual IP を振って、というのもあるかもしれないが、そのあたりは言及できるほどには知らない。
  • 天邪鬼に、手動で複数のホストにユニキャストで、というのもああるが、それやるぐらいなら素直にマルチキャストにする方がラクだろう。

注意事項

  • まだ加筆するし、図にも手を入れる。
  • Ganglia は 3.0 系と 3.1 系では、プロトコルに互換性がないらしい。
  • Ganglia 3.0 系の場合、 hadoop-metrics.properties で指定するのは GangliaContext である。図示したのは 3.1 系での場合。
  • hadoop-metrics.properties を書き換えた場合、その変更を反映させるには、 Hadoop 関連の daemon をすべて再起動させる必要があるようだ。従って、すでに実運用しており、再起動がおいそれとできない場合は、十分に計画を練る必要があろう。