ようへいの日々精進XP

よかろうもん

トップ > sensu

Sensu Server を chef-solo でインストールするメモ

chef sensu monitoring

はじめに

  • もはや何番煎じか解らないけどやっておきたかったので
  • ただいま検証、作業中

参考

前提

  • Chef がインストールされていること
  • chef-solo がインストールされていること
  • berkshelf がインストールされていること
  • Ruby は例によって Chef に同梱されている Ruby を使う

手順

こんな感じで出来た

Sensu

f:id:inokara:20140510161113p:plain

クライアントも追加されている。

f:id:inokara:20140510161131p:plain

Chef Handlers + Graphite

f:id:inokara:20140510161225p:plain

気づいた点

  • Berkshelf を使ったけど特にハマることは無かった
  • Sensu client のセットアップってどうするのか解らず一瞬焦った（結局 client_service.rb に追加した）

2014/05/08 ほげほげ、ふがふが

monitoring mackerel sensu infrataster

最近のトゥウィート

Sensu について

mon という監視ツールを Sensu に置き換えた方のブログ。詳しい。

bash のテストフレームワーク

これは試してみたい。

ここにきて...

やるしかないが、ちょっと困ったちゃん。

Mackerel ベータ版リリース

以下の通り試してみた。

知ったかぶり

mackerel というはてな謹製の監視ツールがベータ版リリースされたので試してみた。

ホスト単位はもちろん、ホストを役割毎にまとめたロール単位で監視が出来たりとクラウド環境を意識した（？）監視ツール。Sensu のメトリクスプラグインでユーザー定義メトリクスを登録出来たり、API 使えたり。

あと、infrataster の mysql_query リソースを試している。

サンプルを動かしただけなので、引き続きクエリを変えたりしながら試していきたい。

2014/05/04 の知ったかぶり

chef 知ったかぶり puppet sensu serverspec rabbitmq aws

最近のトゥウィート

Chef活用ガイド の書評

「Chef活用ガイド　コードではじめる構成管理」の書評を書かれた方のトゥウィート。

自分も改めて読みたいと思います。

Sensu のステッカー！

おお。

知ったかぶり

既に Chef で構築されている方はいらっしゃるので、自分は Puppet 使って Sensu Server を構築してみました。後で Chef でも試してみたいと思います。

難しいことはありませんでしたが、マニフェストの書き方の問題ではないかと思うのですが一発では Sensu Server の起動まではしてくれませんでした。

2014/05/03 の知ったかぶり

sensu Elasticsearch serverspec specinfra Docker

最近のトゥウィート

自分のツイートやお気に入りのツイートを転載。

sensu 関連

sensu 関連で是非参考にしたいトゥウィート二件。

当ブログもご紹介頂いて有難うございます！

chef-solo を使って Sensu Server をセットアップする手順やハマりポイント等が書かれています。このゴールデンウィークの間に chef-solo 使ってセットアップを試してみようと思います。

AWS 関連

これはイイ。

Elasticsearch 関連

API のまとめと tips が有り難いです。

その他

Growthforecast と異なるのがデータストアとして MySQL を利用している点と一定期間を過ぎたあとはメトリクスデータをシェイプアップしてくれるところ。是非、試したいですな。

Vagrant の作者、ミシェルハシモト氏の HashiCorp の新作。紹介されているブログに日本語でConsul の使い方が書かれていてこれも是非、試したいですな。

知ったかぶり

引き続き Specinfra を触っています。

バックエンドとして Docker を利用する手順、ソースコードを追いながらでかなり楽しかったです。

2014/04/23 の知ったかぶり

よくわからん InfluxDB aws sensu 知ったかぶり

InfluxDB は楽しいけど、自分自身に色々と足りてないことに実感しつつ書いた。

Grafana や Tasseo まで辿りつけてない状況...。ただ、sensu からのメトリクスデータは放り込むのは特に難しいことは無かった。

2014/04/22 のほげふが

middleman sensu InfluxDB 知ったかぶり

色々とテンパってしまったけど sensu からInfluxDB を扱える Extension を試してみた。これで Grafana や Tasseo とも連携出来そうってことで。

ちなみにテンパったのは middleman のレイアウト崩れが治らないってことで...（汗。

今後の todo

Sensu 関連

  • Extension についても少し調べる
  • FAQ をちゃんと読み込む
  • いよいよ sensu-chef に手を付ける
  • docker 関連のプラグインを色々と作ってみる

chef 関連

  • kitchen-docker がバージョンアップしたので試す
  • Chef Server リベンジ
  • 「Chef 活用ガイド」を頂いたので読む

LXC / Docker 関連

  • Ubuntu 14.04 の非特権コンテナを体験する
  • Docker と OpsWorks について調べる
  • cgroup を触ってみる

その他

  • Elasticsearch の 0.9 系のバックアップとレストアについてベストプラクティを調べる
  • Influx DB を引き続き触る
  • RabbitMQ のクラスタ化と運用についてもう少し
  • Riak CS について調べる

sensu で docker コンテナの数をチェックするプラグインを作ってみた

sensu ruby Docker

はじめに

参考

こんなの

スクリプト

目指したこと

  • Docker Remote API を使う
  • 起動中のコンテナの数をチェック
  • しきい値を超えたり、下回ったりしたら Warning や Critical を上げる

動いてるところ

以下のように設定を書いて...

{
  "checks": {
    "docker_running_containes_check": {
      "handlers": ["default"],
      "command": "/etc/sensu/plugins/check-docker-containers.rb -w 3 -c 3",
      "interval": 60,
      "subscribers": [ "test" ]
    }
  }
}

暫くすると...

f:id:inokara:20140417062349p:plain

こんな感じ。

上記の例だとローカルホスト上にコンテナが 4 つ起動していたら CRITICAL となる（なっている）。

さいごに

調子こいて

sensu プラグイン

  • 標準出力に critical / warning / ok をそれぞれ出力すれば良さそう
  • あとは sensu がよしなにやってくれる

rubocop

  • コードをチェックしてくれる
  • 怒られてばかりだが書き方について勉強になる

なんかこんなのも作れそう

top

curl localhost:4243/containers/${container_ID}/top

みたいな感じで投げると以下のようにレスポンスが返ってくる。

{"Processes":[["root","1788","1225","0","06:47","pts/1","00:00:00","/bin/bash"]],"Titles":["UID","PID","PPID","C","STIME","TTY","TIME","CMD"]}

ちょっとドキュメントと出力が異なるのが気にはなるがコンテナ内のリソース見るのに使えそうな気がする。

sensu + fluentd + norikra で sensu server のログを眺めてみる（2）

fluentd sensu norikra monitoring

続き

  • 前回は sensu server のログを fluentd → norikra で眺めてみた
  • 今回は sensu の監視イベントを fluentd ハンドラプラグインから norikra という流れを作ってみる
  • 前回同様に sensu のデバッグやリアルタイムなイベント監視等に応用出来そうかな

準備

sensu の fluentd ハンドラプラグインの設定

repeatedly さんが作られたこちら と こちらを利用させて頂く。

cd /etc/sensu/handlers
curl -k -o fluentd.rb https://raw.githubusercontent.com/sensu/sensu-community-plugins/master/handlers/notification/fluentd.rb
chmod 755 fluentd.rb
cd /etc/sensu/conf.d/
curl -k -s -o fluentd.json https://raw.githubusercontent.com/sensu/sensu-community-plugins/master/handlers/notification/fluentd.json

fluentd.json のみを fluentd の環境に応じて修正する必要があるが今回は http のポート番号のみを変更した。

{
  "fluentd": {
    "host": "localhost",
    "port": 9800,
    "tag_prefix": "sensu"
  }
}

fluentd(td-agent) 側の設定

input プラグインで http を使うことになる。

<source>
  type monitor_agent
  bind 0.0.0.0
  port 24220
</source>

<source>
  type http
  port 9800
</source>

<match sensu.*>
  type copy

  <store>
    type file
    path /tmp/test.log
  </store>

  <store>
    type norikra
    # Please change your norikra server's IP
    norikra localhost:26571

    target_map_tag yes

  </store>
</match>

<match norikra.**>
  type stdout
</match>

monitor_agent は個人的な趣味です。

あとはお好きに...クエリ投げたりしてみて

前回とは異なり sensu server のイベントデータのみが fluentd を介して norikra に流れるようになるのでクエリの結果は少ないものの以下のようにイベントデータを見ることが出来る。

f:id:inokara:20140416065409p:plain

例えば、監視項目ごとにクエリ書いておいて件数見たりすることでリアルタイムに監視イベントのトレンドをキャッチアップ出来るのではないかと期待している。

おまとめ

今回の構成

以下のように sensu server 自身のログやイベントデータを fluentd を介して norikra に流し込み SQL ライクな DSL を使ってデバッグで利用したりリアルタイムの監視イベントの確認が出来るような構成を作ってみた。

f:id:inokara:20140416071642p:plain

試してみて

前回も書いたが sensu がイベントデータやログまでも JSON という共通言語でやりとりされていることにより fluentd との相性が良く、ログデータやイベントデータを簡単に fluentd を介して fluentd の各種プラグインでやりたい事がやれそうな気がした。また sensu の community plugin を組み合わせることで同じような目的を達成することも出来るとは思うが様々なツールを組み合わせる事ができる sensu の自由度と柔軟性の高さの良い部分ではないかと考えている。

色々と楽しいですな。

sensu + fluentd + norikra で sensu server のログを眺めてみる

fluentd sensu norikra monitoring

追記

追記（1）Failed: Incorrect syntax near 'output' (a reserved keyword) のエラー

はじめに

  • タイトル通り
  • sensu server を検証するあたりログをチラチラ見れたら嬉しいよね
  • しかもせっかくログまでも JSON な sensu は fluentd との相性は抜群！ということで試した

準備

  • 細かい設定については割愛させて頂きます...
  • 既に稼働している sensu server に td-agent と norikra をインストールする
  • 以前に作った Dockerfile を一部流用

fluentd.conf(td-agent.conf)

今回は td-agent を利用したので td-agent.conf は以下のような感じでシンプルに。

<source>
  type monitor_agent
  bind 0.0.0.0
  port 24220
</source>

<source>
  type tail
  format json
  path /var/log/sensu/sensu-server.log
  tag sensu.streame
  pos_file /tmp/fluentd.pos
</source>

<match sensu.*>
  type copy

  <store>
    type file
    path /tmp/test.log
  </store>

  <store>
    type norikra
    # Please change your norikra server's IP
    norikra localhost:26571

    target_map_tag yes

  </store>
</match>


<match norikra.**>
  type stdout
</match>

起動

準備も整ったところで関係者（sensu server や td-agent や norikra）を起動していく。

norikra

norikra には Web のダッシュボードが備わっているのでブラウザから確認することが出来る。今回は MacOS X の boot2docker を使っているので Web ダッシュボードにバインドされたポートに対してブラウザからアクセスする。

f:id:inokara:20140415070653p:plain

その他の関係者の起動については追って書くかも。

sensu server のログ

Target

いよいよ松本伊代、本題の sensu server のログ。関係者を起動後に暫くすると norikra のダッシュボードの Target に以下のように td-agent 経由で流れてくる sensu server のログが登録されている。（※「登録」という言い方が正しいかは不安）

f:id:inokara:20140415071029p:plain

Query

簡単なクエリを投げてみる。

f:id:inokara:20140415071328p:plain

以下のような感じでクエリにマッチしたログが表示される。

f:id:inokara:20140415072452p:plain

また、コマンドラインからも...

norikra-client event fetch test1

と実行すると以下のようにクエリにマッチしたログが出力される。

{"time":"2014/04/07 20:15:04","timestamp":"2014-04-07T20:15:03.154364+0000","level":"info","message":"pruning aggregations"}
{"time":"2014/04/07 20:15:14","timestamp":"2014-04-07T20:15:13.123437+0000","level":"info","message":"determining stale clients"}
{"time":"2014/04/07 20:15:24","timestamp":"2014-04-07T20:15:23.157341+0000","level":"info","message":"pruning aggregations"}
{"time":"2014/04/07 20:15:44","timestamp":"2014-04-07T20:15:43.125402+0000","level":"info","message":"determining stale clients"}
{"time":"2014/04/07 20:15:44","timestamp":"2014-04-07T20:15:43.158266+0000","level":"info","message":"pruning aggregations"}
{"time":"2014/04/07 20:15:52","timestamp":"2014-04-07T20:15:50.814024+0000","level":"info","message":"handling event"}
{"time":"2014/04/07 20:15:54","timestamp":"2014-04-07T20:15:52.777894+0000","level":"info","message":"handling event"}

おお、便利そう。

最後に

まとまってないまとめ

  • ログが JSON で流れてくると色々嬉しいかも
  • Elasticsearch 等に放り込んでも検索等は出来るが「リアルタイム」と「SQLライクな検索が出来る」という点では norikra が優位だと思う

次回は

気になる点としては

output というフィールド名を含むクエリを投げようとすると...

norikra-client query add test "select * from sensu_streame where output like '%check-disk.rb%'"

以下のようなエラーになってしまった。ガビーン。

2014-04-07 20:24:00 +0000 [INFO] : ClientError Norikra::QueryError: Incorrect syntax near 'output' (a reserved keyword) at line 1 column 34, please check the where clause [select * from sensu_streame where output like '%check-disk.rb%']
Failed: Incorrect syntax near 'output' (a reserved keyword) at line 1 column 34, please check the where clause [select * from sensu_streame where output like '%check-disk.rb%']

どうやら output は予約語になっているようだ...。引き続き調べたいと思う。

sensu の Mutators をドキュメント通りに試した

sensu Ruby monitoring

どうもご無沙汰してます自称 sensu 芸人のかっぱです。

はじめに

  • sensu の Mutators を試せていなかったのでまずはドキュメントを見よう見真似で試す

Mutators とは？

ざっくり言うと...

  • 監視イベントをハンドラに渡す前にイベントデータに手を加える処理
  • イベントデータに手を加える必要がなければ特に設定は不要

試す

ドキュメントの Handlers と Mutators を参考に試してみるよです。

Handlers

こちら に従って /etc/sensu/handlers 以下にスクリプトを設置する。

#!/usr/bin/env ruby

require 'rubygems'
require 'json'

# Read event data
event = JSON.parse(STDIN.read, :symbolize_names => true)
# Write the event data to a file
file_name = "/tmp/sensu_#{event[:client][:name]}_#{event[:check][:name]}"
File.open(file_name, 'w') do |file|
  file.write(JSON.pretty_generate(event))
end

上記は監視のイベントデータを /tmp/ 以下に出力するハンドラスクリプト。

config.json に以下のように設定する。

  "handlers": {
    "default": {
      "type": "pipe",
      "command": "/etc/sensu/handlers/file.rb"
    }
  }

sensu-server を再起動する /tmp/ 以下に sensu_${hostname}_${監視イベント名} というファイル名で出力される。中身は以下のような感じ。

      "2",
      "2",
      "2",
      "2",
      "2",
      "2"
    ]
  },
  "occurrences": 90,
  "action": "create"
}

Mutators

さあ、Mutato してみましょうということで こちらの通りにスクリプトを /etc/sensu/mutators 以下に設置する。

#!/usr/bin/env ruby

require 'rubygems'
require 'json'

# Read event data
event = JSON.parse(STDIN.read, :symbolize_names => true)
# Add a 'tag' to prove it has been mutated
event.merge!(:mutated => true, :its_a_tumor => true)
# Output mutated event data to STDOUT
puts event.to_json

イベントストリームに対して "mutated": true と "its_a_tumor": true を付加する。

そして config.json に以下を追加する。

  "handlers": {
    "default": {
      "type": "pipe",
      "mutator": "tag", // 追加
      "command": "/etc/sensu/handlers/file.rb"
    }
  },
 "mutators": { // 追加
    "tag": { // 追加
      "command": "/etc/sensu/mutators/tag.rb" // 追加
    } // 追加
  } // 追加

そして...改めて sensu-server を再起動する /tmp/ 以下に sensu_${hostname}_${監視イベント名} というファイル名で出力されるのは従来通り。但し、ファイルの中身を見てみると...

      "2",
      "2",
      "2",
      "2",
      "2",
      "2"
    ]
  },
  "occurrences": 93,
  "action": "create",
  "mutated": true,
  "its_a_tumor": true
}

おお、"mutated": true, と "its_a_tumor": true が付加されている。

さいごに

  • 引き続き Mutators を試していきたい
  • JSON を制すインフラエンジニアはインフラを制す（なんてねｗ）