https://inokara.hateblo.jp/entry/2014/01/16/064456

はじめに

docker と puppet を使って sensu の環境を構築してみた
sensu についてざっくり理解する
構築では chef ではなく puppet で試してみる
ベタなタイトルですいません（記事の中身はセンスありません）

参考

sensu について

sensu の詳細についてはこちらやこちらがとても参考になったので割愛させて頂く。以下は sensu のダッシュボード。

f:id:inokara:20140116064847p:plain

以下は自分が使ってみてセンスを感じたポイントと「？」なポイント。

sensu のセンスを感じるポイント

設定から各種ログの出力が JSON 形式
JSON 形式なので可読性が良いのと応用が効く（ログを fluentd とかに流せる等）
Nagios のプラグインが流用可能、又、Ruby 等で簡単に実装出来そう
ダッシュボードもアーキテクチャもシンプル、シンプルが故に動作が軽快
監視に必要な要素（チェック、収集、イベントハンドリング）の見通しがよくて拡張し易そう
Chef や puppet で構築することでクライアントへの設定ファイルが自動配布出来そう

sensu の？なポイント

rabbitmq が中心となりクライアントからメトリクスや API との橋渡しをしている？
Chef や puppet を利用することのメリットの裏返しかもしれないけど設定ファイル等を直感的に理解するのに時間が掛かるかもしれない？（JSON 形式にすることでその時間を短縮する一助となる？）
従来の監視システムの場合には「監視設定＝監視設定ファイル」を書くというイメージだけど、sensu の場合には「監視設定＝chef のレシピや puppet のマニフェストを書く」というイメージになり初めは混乱する？
redis が何に使われているのかイマイチ解らない？

構築について

今回は環境を docker で用意してサーバー用とクライアント用に Dockerfile を作り*1、その中 Dockerfile の中で puppet-apply を叩いて設定するようにしてみた。構成としては以下のような構成。

f:id:inokara:20140116072643p:plain

構築についてはここで説明するより Dockerfile を見たほうが何をやっているのかが解ると思うのでそちらを見て頂くとして、今回 puppet で構築したのでそのマニフェストについて以下にちょっとだけメモ。ちなみにマニフェストとは chef で言うところのレシピみたいなもの（という理解）。puppet の詳細についてはこちらやこちらを。

sensu サーバー用のマニフェスト

sensu サーバーを構築するには以下のようなマニフェスト一発。

node default {
  file { '/etc/rabbitmq/ssl/key.pem':
    source => 'puppet:///files/sensu/key.pem',
  }
  file { '/etc/rabbitmq/ssl/cert.pem':
    source => 'puppet:///files/sensu/cert.pem',
  }
  file { '/etc/rabbitmq/ssl/cacert.pem':
    source => 'puppet:///files/sensu/cacert.pem',
  }
  class { 'rabbitmq':
    ssl_key => '/etc/rabbitmq/ssl/key.pem',
    ssl_cert => '/etc/rabbitmq/ssl/cert.pem',
    ssl_cacert => '/etc/rabbitmq/ssl/cacert.pem',
    ssl => true,
  }
  rabbitmq_vhost { '/sensu': }
  rabbitmq_user { 'sensu': password => 'mypass' }
  rabbitmq_user_permissions { 'sensu@/sensu':
    configure_permission => '.*',
    read_permission => '.*',
    write_permission => '.*',
  }
  class {'redis': }
  class {'sensu':
    server => true,
    purge_config => true,
    rabbitmq_password => 'mypass',
    rabbitmq_ssl_private_key => "puppet:///mount_point/sensu/key.pem",
    rabbitmq_ssl_cert_chain => "puppet:///mount_point/sensu/cert.pem",
    rabbitmq_host => 'localhost',
    subscriptions => 'sensu-test',
  }
  sensu::handler { 'default':
    command => 'mail -s "sensu alert" hoge@huga.com',
  }
}

但し、事前にモジュール（chef で言うところの cookbook）を導入しておく必要がある。今回の例だと、以下のように rabbitmq と redis とコアとなる sensu のモジュールをインストールする必要がある。

sudo puppet module install example42/redis
sudo puppet module install puppetlabs/rabbitmq
sudo puppet module install sensu/sensu

上記のようにして puppet のモジュールをインストールする。

クライアントを構築するマニフェスト

クライアントはサーバー側で稼働している rabbitmq と通信をすることになるので、以下のように rabbitmq への接続情報等を記載する。

node default {
  class {'sensu':
    client => true,
    purge_config => true,
    rabbitmq_password => 'your_pass',
    rabbitmq_ssl_private_key => "puppet:///mount_point/sensu/key.pem",
    rabbitmq_ssl_cert_chain => "puppet:///mount_point/sensu/cert.pem",
    rabbitmq_host => 'xxx.xxx.xxx.xxx',
    subscriptions => 'sensu-test',
  }
  package { 'nagios-plugins-basic': ensure => latest }
    sensu::check { "cron":
      handlers    => 'default',
      command     => '/usr/lib/nagios/plugins/check_procs -C cron -c 1:10',
      subscribers => 'sensu-test'
    }
}

また、チラチラ登場している Nagios という文字からも解るように泣く子も黙る監視システムの大御所、Nagios のプラグインを流用することが出来る。

その他

上記、クライアントのマニフェストに記述されている handler は監視イベントを検知した際の挙動を指定するものでサーバーのマニフェスト内で以下のように設定している。

  sensu::handler { 'default':
    command => 'mail -s "sensu alert" hoge@huga.com',
  }

handler 以外の subscribers 等の各種項目については引き続き触ってみる。

引き続き...

sensu の監視の仕組みについて少し掘り下げてみる
puppet サーバーから監視の設定を自動配布する構成を試してみる
従来の監視システムとはちょっと違った印象のある sensu を引き続き使っていきたい
従来の監視システムから即移行というのはちょっと難しい（アーキテクチャや思想を理解するまでに）かもしれないけど、自由度が高く、他システムの連携のし易さ等が個人的には評価出来る
ロゴが好き
sensu とは関係無いけど...久しぶりに puppet を使ってみたけど面白かった

*1:各 Dockerfile は十分なテストが出来ていないのでうまく動かないことがあります...すいません