サーバー監視

サーバー監視には死活監視とリソース監視があって、どっちも結局は監視対象のサーバーに対して監視サーバーからコマンドを投げたり、監視対象のサーバーが自ら収集したデータを監視サーバー宛に投げたりする。みたいな感じになっている。まだ使いこなせていないだけかもしれないが、あまり分ける意味が分からなかった。

既存ソフトウェアには監視対象とか層の違いはあれどNagios、Zabbix、Ganglia、Munin、Amazon CloudWatch、Monitとかがある。

うちではMuninとCloudWatchを使っている。というかCloudWatchに移行段階で、Muninは依存perlのバージョン管理とグラフ作成のプロセスがゴリゴリとCPU使いまくって非常に辛い。まあチューニングがされていないからなのだけれど。でもチューニングしたからといってゴリゴリならないかと言うとそうも言えないようで辛い。(チューニングしたらそれなりに動くようになった。)それで、新しく建てたサーバー群に入れたミドルウェアの要求perlとバージョンがバッティングしてうまく入れられなかったので辛くてCloudWatchに移行するという流れになった。

CloudWatchは我らがAmazonのサービスで監視とアラートを出してくれる。あとオートスケーリングするなら結局使わなければいけない。で、各サーバーがAmazonに対してデータを送信するのだけれど、その為にグローバルなIPを振らなければならなくて結局辛い。せっかくVPNで閉じているのに。

なので、うちではVPN内に監視サーバーを一個用意し、そこが各サーバーに対してsshでコマンド送ってデータ取得し、それを一括でCloudWatchに送るみたいな感じにした。これなら監視サーバーだけにグローバルなIPを振れば良い。因みにコマンド送りつけるところはFabricをcronで回してやっている。

という感じの構成にしたのだけれど移行途中でMuninがまだ生きていて、それが監視サーバーにいるのでCPUゴリゴリだし、さらにFabricが各サーバーにアクセスするcronと被ってロードアベレージ爆上げという感じになっている。最悪。監視されるサーバー群より監視するサーバーの方が危機。

広告


コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中