cloudpack の 自称 Sensu芸人 の かっぱこと 川原 洋平(@inokara)です。
はじめに
前回は Consul をインストールしてクラスタ内のノードの検出を試してみました。今回は各ノードのサービス検出と監視を試してみたいと思います。また、Web UI も試してみたいと思います。
サービスの検出と監視
コンサルティングするサービス
コンサルティング(検出と監視)するサービスは以下のサービスです。
もしかすると MySQL レプリケーション等のような複数台で 1 つの機能を提供するようなサービスで使うと Consul の旨味を感じられるのかもしれませんが、今回は各ノードで稼働している td-agent のサービスを検出と監視をしてみたいと思います。
サービスの検出と監視に必要なポイントは下記の通りです。
- サービスの定義
- サービスを監視する為のエンドポイント(例えば HTTP のサービスを監視する場合等の URL )
さらに実際の設定にあたっては以下のような設定項目が必要となります。
- name
- tags
- port
- check(script / interval)
それぞれの定義についてはドキュメントの以下を御覧ください。
設定については以下のような JSON 形式でサービスを定義します。
{
"service":{
"name":"td-agent",
"tags":["td-aget"],
"port":24224,
"check":{
"script":"curl http://localhost:24220/api/plugins.json >/dev/null 2>&1",
"interval":"10s"
}
}
}
実際の設定に際しては…以下のように agent を起動する際に -config-file でパスを指定するか…
cat << EOT > td-agent.json
{
"service": {
"name": "td-agent",
"tags": [ "td-aget" ],
"port": 24224,
"check": {
"script": "curl http://localhost:24220/api/plugins.json >/dev/null 2>&1",
"interval": "10s"
}
}
}
EOT
./consul agent -dc=local -node=consul3 -data-dir=/tmp/consul3
-bind=${BIND_IP} -config-file=/path/to/td-agent.json -join=${SERVER_IP} &
又は適当なディレクトリを作成し、同様に agent を起動する際に -config-dir で設定を置いたディレクトリを指定する…
sudo su -
mkdir /etc/consul.d/
cd /etc/consul.d/
cat << EOT > td-agent.json
{
"service": {
"name": "td-agent",
"tags": [ "td-aget" ],
"port": 24224,
"check": {
"script": "curl http://localhost:24220/api/plugins.json >/dev/null 2>&1",
"interval": "10s"
}
}
}
EOT
./consul agent -dc=local -node=consul3 -data-dir=/tmp/consul3
-bind=${BIND_IP} -config-dir=/etc/consul.d -join=${SERVER_IP} &
二つの方法があります(直接 curl で JSON を登録する方法もありそうですが具体的な方法は調査して後ほど追記しておきます)。尚、既に Consul が起動している場合には Consul のプロセスに SIGHUP を送ってあげる(又は consul reload を実行)と設定を読み込んでくれます。
kill -HUP `ps aux | grep consul | grep -v grep | awk '{print $2}'`
td-agent の準備
td-agent は rpm パッケージからインストールして監視エージェントの設定のみしておきます。
curl -L http://toolbelt.treasuredata.com/sh/install-redhat.sh | sh
cat << EOT >/etc/td-agent/td-agent.conf
<source>
type monitor_agent
bind 0.0.0.0
port 24220
</source>
EOT
/etc/init.d/td-agent restart
Consul の設定とプロセスの再起動
既に Consul が動作していて /etc/consul.d に各サービスの定義を置く状態になっている場合には以下のように各々のノードでサービスを定義して SIGHUP を送ります。(または consul reload を実行します)
cd /etc/consul.d/
cat << EOT > td-agent.json
{
"service": {
"name": "td-agent",
"tags": [ "td-aget" ],
"port": 24224,
"check": {
"script": "curl http://localhost:24220/api/plugins.json >/dev/null 2>&1",
"interval": "10s"
}
}
}
EOT
kill -HUP `ps aux | grep consul | grep -v grep | awk '{print $2}'`
これで準備オッケーです。ちなみに、この時点でクラスタな下記のような状態になっているはずです。
サービスの検出
正常系
HTTP API を使ってクラスタ内で稼働する td-agent サービスの確認を行いたいと思いますので、ノード内の一つのノードにて以下を実行します。
curl -s http://127.0.0.1:8500/v1/health/checks/td-agent | jq .
以下のようにレスポンスが返ってきます。3 つのノードで稼働する td-agent サービスを状態が確認できます。
上記の状態は Status が全て passing な状態ですので全てのノードで稼働している td-agent は正常に稼働していると判断できます。
異常を検知
クラスタ内の一台で稼働している td-agent を停止してから改めてヘルスチェックしてみると…
curl -s http://127.0.0.1:8500/v1/health/checks/td-agent | jq .
以下のようにレスポンスが返ってきます。
td-agent を停止したノードで Status が critical となっており異常を検知することが出来ています。
Web UI
Consul には Web UI の機能があります。但し、Consul agent には同梱されず別途ダウンロードしてセットアップする必要があります(とは言ってもダウンロードして展開してプロセスを再起動するだけです)。
Web UI のセットアップ
とりあえず Consul の Server node の適当なディレクトリに Web UI キットをダウンロードして展開します。
mkdir /opt/consul
cd /opt/consul
wget https://dl.bintray.com/mitchellh/consul/0.3.0_web_ui.zip
unzip 0.3.0_web_ui.zip
展開したディレクトリは以下のような状態になっているかと思います。
opt
└── consul
└── dist
├── index.html
└── static
├── application.min.js
├── base.css
├── bootstrap.min.css
├── consul-logo.png
└── loading-cylon-purple.svg
3 directories, 6 files
Web UI 付きで起動
以下のようにしてオプションに -ui-dir を付加して Consul を起動します。
./consul agent -server -bootstrap -client=${CLIENT_IP} -dc=local
-node=consul1 -config-dir=/etc/consul.d -data-dir=/tmp/consul -bind=${BIND_IP}
-ui-dir /opt/consul/dist/ &
YOKOSO Web UI
起動したらブラウザから http://${Consul_Server_node}:8500/ にアクセスします。
上記のようにシンプルな UI で表示されました。既に HA Proxy も監視対象となっていてこちらは特に異常は検知されていませんが td-agent は先ほど一台の node でサービスを停止しているので 1 falling となっているのが判ります。
各サービスの詳細
td-agent をクリックすると右ペインに各ノードの状態が表示されます。
td-agent が停止しているノードでは異常を検知しています。また、全てのノードにおいてSerf 自体も監視対象となっていることも合わせて判ります。
ノードの操作
例えば、これまでの例のようにクラスタを構成していノードの一台のサービスが停止してしまった場合にそのノードを切り離したり、サービスを復旧させた後、改めてサービスにジョインさせたい場合があると思います。その場合には切り離す操作やジョインする操作を行うことが出来ます。
コマンドラインによる操作
Consul の CLI を利用してクラスタからノードを切り離します。
切り離し
切り離したいノードにログインした上で…
./consul leave
を実行します。その際に Consul Server node には以下のようなログが出力されます。
2014/07/18 20:46:23 [INFO] serf: EventMemberLeave: consul3 xxx.xxx.xxx.xxx
2014/07/18 20:46:23 [INFO] consul: member 'consul3' left, deregistering
ノードが切り離されたことを確認するには consul members をクラスタ内のノードで実行します。
ちなみに Web UI でも同様に確認してみます。
ジョイン
再びクラスタにジョインしたい場合には join コマンドではなく agent コマンドでクラスタにジョインします。
./consul agent -dc=local -node=consul3 -data-dir=/tmp/consul3
-bind=${BIND_IP} --config-dir=/etc/consul.d -join=${SERVER_IP} &
上記以外にもノードを操作するコマンドはありますし、HTTP API からも操作出来るようなので引き続き試してみたいと思います。
最後に
今回やったこと
- ノード上で稼働させるサービスの検知と監視を設定してみました
- Web UI を使いクラスタの状態を確認しました
- コマンドラインからノードを切り離したり、再度メンバーに追加してみました
次回やりたいこと
- Consul のアーキテクチャにちょっとでも迫りたい…
ぶっちゃげ
とりあえずサービスの検知や監視までを行うことが出来ましたが、まだ、ちゃんと Consul について理解出来ておらずどんな風に使っていいのか解っていません…
元記事は、こちら