監視ツールの覚書

「監視ツール」について、それが監視するものと各ツールの特徴をざっとまとめました。

監視対象はおおざっぱに3種類に分けられます。

  1. ホスト、サービス、プロセスなどのヘルスチェック
    • 死んでいたらアラートを上げる。
  2. CPUの負荷、メモリ使用量などのリソース使用状況監視
    • 数値を記録する。
    • 閾値を上回る/下回るとアラートを上げる（オプション）。
  3. ログ監視
    • ログを記録する。
    • 属性ごとに集計する（オプション）。
    • 変なログが出たらアラートを上げる（オプション）。

ヘルスチェック

ヘルスチェックを行うツールは、何らかの形でリソース使用状況監視もサポートしています。実際、「Apacheが死んでたらアラートを上げる」と「CPU loadが30を超えてたらアラートを上げる」はできれば一緒にしたいです。

Nagios

たぶん最も広く使われているヘルスチェックツールです。古くてガタピシしていますが、機能豊富で理解は容易です。

Nagiosサーバから監視対象のホストやサービスをつつく中央集権的アーキテクチャです。

プロセスの死活など、監視対象のホスト上でチェックを行う必要がある場合、NRPEというエージェントを介してチェックを行います。具体的には、Nagiosサーバが監視対象のNRPEをつつき、NRPEがチェック用コマンドを実行します。

チェックコマンドの標準出力にリソース使用状況などの数値データを含めることで、数値の記録と可視化が可能です。見た目がいけていないので、Nagios+Muninの構成の方がいいかも。この場合リソース使用状況のアラートは、Muninから下記のNSCAをつつくことになります。

cronジョブの成功・失敗のように、Nagiosのあずかりしらないタイミングでチェックを行う必要がある場合には、NSCAを使います。具体的には、cronジョブがNSCAサーバに成功・失敗の情報を送りつけます。NagiosサーバはNSCAに送られてきたチェックをポーリングします。通常とは逆に、「監視対象→Nagios」という制御の向きになります。

長所:

  • 機能が豊富
  • 構成が単純で理解が容易
  • ホストのping監視とポートの監視だけであれば、エージェントは不要

短所:

  • Nagiosサーバ、NRPE、NSCAクライアントに設定が重複・散乱する
  • 監視対象をNagiosサーバの設定に記載する必要がある。スケールアウトに不向き
  • Web APIがない
    • Nagiraという、APIを無理やりくっつけるツールがある
  • 冗長構成に適していない
Sensu

分散的アーキテクチャです。Sensuサーバと監視対象内のエージェントはRabbitMQ (メッセージキュー) を通じてやりとりします。チェックはエージェントが行い、結果をSensuサーバがRedisに格納します。

Web APIが提供されており、ダッシュボードはサーバから切り離されたAPIクライアントとして動作します。

監視対象のホストは、エージェントが立ち上がった時に勝手に追加されます。削除はAPIを叩く（むー）。

長所:

  • 分散。疎結合。スケールアウトしやすい
  • Nagiosのチェックコマンドが使える
  • たぶん冗長構成に適している
  • Web APIがある

短所:

  • 構成要素が多く複雑

わからない・調べてないこと:

  • そもそも使ったことがない
  • アラートはどこがやってんだろう。Sensuサーバ？
  • NSCA相当のことはAPIをつつけば良いのだろうか
Consul

ZooKeeperによく似た、分散システムの協調サポートツールであり、応用の一つとしてヘルスチェックが可能、という位置づけです。低レベル層にSerfやLMDBを使っています。

SensuでRabbitMQが担当しているノード間通信は、Consul/Serfが提供するメッセージング機能を使います。SensuでRedisが担当しているデータ保管は、Consul/LMDBが提供するKVSを使います。

Web APIが提供されています。

長所:

  • Sensuとだいたい同じ
  • ConsulとSerfは同じ会社 (HashiCorp) が開発してるので、Sensuほどバラバラな感じじゃない
  • シャレオツ

短所:

  • 情報が少ない

わからない・調べてないこと:

  • だいたいわかってない
Zabbix

なんかJP1とかTivoliみたいなやつ。統合監視ツール。

リソース使用状況

リソース使用状況は、一定間隔で数値が発生するログとみなすこともできます。このため、後述のログ監視の仕組みに流し込むことも考えられます。

ここでは、リソース使用状況の収集に特化したツールについて書きます。

Munin

Muninサーバが監視対象のエージェント (munin-node) をつついてリソース使用状況を報告させ、時系列データファイルであるRRDファイルに記録します。

cronで定期的にリソース使用状況のページを作って/var/www/htmlに置きます。具体的には、RRDファイルからPNGの画像を作って、HTMLページを更新します。したがって、CGIなど表示系のプログラムはありません。

閾値を超えたり下回ったりしたときに、任意のコマンドを叩いてアラートを上げることができます。たとえばNSCAをつついてNagiosにアラートを上げさせる、など。

監視対象はMuninサーバの設定に集約します。

長所:

  • 構成が単純で理解が容易
  • インストール時点でだいたい見たいものが見える。ひねったメトリクスも簡単に追加できる

短所:

  • ページの更新がとても重い
  • APIはない
  • スケールアウトに向かない。Nagiosと同様
Cacti

Muninと大体同じ。RRDファイルを使っているのも同じ。

Muninより設定が小難しい代わりに、詳細な設定が可能なようです。

Ganglia

大規模システム用のリソース使用状況監視ツールです。個別のサーバの状況が見られるのに加えて、「Webサーバぜんぶ」、「Appサーバぜんぶ」のように「クラスタ」ごとにまとめて情報が見られます。また、CPU loadが高い時はグラフが赤くなったりして、ひと目で状況が分かりやすいです。

Gangliaサーバ上のgmetadが、監視対象ホスト上のgmondというエージェントをつついて、RRDファイルに結果を書き出します。ここでクラスタごとにマルチキャストIPアドレスを割り当てると、gmond同士がデータを共有するので、gmetadの設定が少なくて済みます。

長所:

  • 大規模システム向き
  • スケールアウトしやすい

短所:

  • 細かい情報を見るものではない
sysstat

sarやvmstatやiostatなど、ローカルホストのリソース使用状況を調べるツール群です。いずれも/proc以下をパースして集計しています。たいていのLinuxディストロでは、sarコマンドが調べた各種リソース使用情報が、/var/log/saディレクトリに出力されるようになっています。

なにか異変が起きた時に、事後的に状況を見れば良いのであれば、sysstatというかsarで充分かもしれません。

sarの情報の可視化については下記を参照。

ログ

下記を参照。