Sensuを使ってクラウド環境の監視を効率よく行おう

AWSなど様々な環境でサーバを管理してくると、すべて同一の監視ツールを使うのがなかなか難しくなってきます。そんなこともあり、私も定期的にいろいろな監視ツールを試しています。

http://nanapi.co.jp/blog/2013/09/11/monitor_nanapi_servers/

nagiosとクラウドの相性が悪い！

監視するには様々なツールがありますが、その中でも特に有名なツールはnagiosでしょう。古くから使われているツールで、プラグインも数多くあり様々な監視を行うことができます。

クライアント側にnrpeをインストールすることで、各ホストの詳細の状態まで監視することができますし、うまく活用すればかなり細かい監視までできます。

しかし、AWSのようなクラウド環境で使うには非常に使いづらいです。というのも、nagiosはサーバ側にどのホストを監視するのかという情報を持たなければいけません。そのため、EC2のように再起動することによりホスト名が変わったり、インスタンスを追加したりしたときも変更が必要です。

それに、nagiosの設定ファイルってすごく面倒じゃないですか？もう長い期間いじっていますが、しょっちゅう文法エラー出します。設定もぐちゃぐちゃになりますし、記述方法も独特ですしあまり好きになれません。

設定ファイルも、JSONで記述するので比較的わかりやすいです。

Sensuのインストール

まぁどれだけSensuがイケてるかって話は公式のページにたくさんかいてあるので読んでみてください。以下のスライドがわかりやすいです。

http://slides.sensuapp.org/

というわけで、インストールします。Sensu自体のインストールはChefを経由することが推奨されているので、こちらの公式で提供されているcookbookを使うと良いと思います。

GitHub - sensu/sensu-chef: Sensu Chef cookbook.

なおSSLあたりで若干ハマるので、READMEをちゃんと読んでくださいね。

Sensuのセットアップ

Sensuはnagiosと違い、SensuServer側では監視するホストのリストを保持していません。監視する側でClientを立ち上げることで、Server側に自分の存在を通知して自動的に監視対象に追加されます。newrelicを使ったことある人は、あれをイメージしてもらえればわかりやすいと思います。

サーバ側では以下の設定を入れておきます。

/etc/sensu/config.json

{
  "rabbitmq": {
    "host": "localhost",
    "port": 5672,
    "vhost": "/sensu",
    "user": "sensu",
    "password": "password"
  },
  "redis": {
    "host": "localhost",
    "port": 6379
  },
  "api": {
    "host": "localhost",
    "bind": "0.0.0.0",
    "port": 4567
  },
  "dashboard": {
    "bind": "0.0.0.0",
    "port": 8080,
    "user": "admin",
    "password": "secret"
  }
}

/etc/sensu/conf.d/check-cron.json

{
  "checks": {
    "cron_check": {
      "handlers": ["default"],
      "command": "/etc/sensu/plugins/check-procs.rb -p cron -C 1 ",
      "interval": 60,
      "subscribers": ["all"]
    }
  }
}

Client側では以下のようにして設定を入れます。

/etc/sensu/config.json

{
  "rabbitmq": {
    "host": "192.168.1.1",
    "port": 5672,
    "vhost": "/sensu",
    "user": "sensu",
    "password": "password"
  }
}

/etc/sensu/conf.d/client.json

{
  "client": {
    "name": "servername",
    "address": "192.168.1.10",
    "subscriptions": [
      "all"
    ]
  }
}

このようにして設定します。監視する項目自体は、Server側で設定してClient側はどの監視グループに参加するのかをそれぞれ設定するアーキテクチャになっています。そのため、監視する項目のマスタはServer側で管理できるので監視項目の変更なども簡単に行うことができます。

ただし、それぞれの監視につかうコマンドは各client側にインストールする必要があるので注意してください。監視のコマンドはこのリポジトリで様々なものが開発されています。

GitHub - sensu/sensu-community-plugins: Sensu community plugins for checks, handlers, & mutators.

ryuzeeさんのブログですごく詳しく説明されていました！

SensuのCommunity Pluginの一覧(日本語版) | Ryuzee.com

標準でAPIが提供されている

Sensuの良い所は、APIですべての操作ができることです。nagiosなどはWebから確認することが前提とされているため、他のシステムやscriptなどとの連携が面倒なことでした。ドキュメントはこちらにおいてあります。

http://sensuapp.org/docs/0.11/api

そのため、Sensuも基本パッケージにWebのフロントエンドが用意されていますがあくまでAPIを活用したツールなので自分なりに開発することもできます。また、SensuAPIをグローバル公開しても認証をかけることができるので様々なクライアントを開発することができます。

そんなこともあり、iOS開発の勉強も兼ねて私もSensuClientのiOSアプリを作っています。デザインはなんとかしないとマズイですが、ある程度動いているのであとはバグ潰して申請ということろです。（通るかな・・・）

nanapiでも順次導入

というわけで、なんかいけそうな雰囲気を感じてきたのでプロダクション環境にも順次導入していきたいと思います。４月にリリース予定の新サービスで活用予定です。

またプロダクション環境で動作したらいろいろな問題が発生すると思うので、ある程度知見がたまったところでブログにでもまとめてみようと思っています。

Nagios統合監視[実践]リファレンス (Software Design ｐlus)