Rancher OS の開発チームが公開した各監視ツールの比較記事です。 Comparing 7 Monitoring Options for Docker
次の 5項目をそれぞれ 5段階で評価しています。
- デプロイが簡単か
- 取得できる情報の詳細度
- 全コンテナからの集計度
- アラートの生成
- Docker 以外のリソース監視
- 費用
Docker に標準搭載されたコンテナのリソース使用状況を詳しく調べるためのコマンドラインツールです。「docker stats」の後ろに、対象のコンテナ名を引数として与えることで、CPU 使用率、メモリー使用量と空きメモリー容量などのコンテナの統計情報が表示できます。コンテナに対してメモリー使用量の制限を与えていない場合、ホストの全メモリー容量が表示される点には注意が必要です。コンテナがその全てのメモリーにアクセスできるという意味ではありません。
$ docker stats determined_shockley determined_wozniak prickly_hypatia
CONTAINER CPU % MEM USAGE/LIMIT MEM % NET I/O
determined_shockley 0.00% 884 KiB/1.961 GiB 0.04% 648 B/648 B
determined_wozniak 0.00% 1.723 MiB/1.961 GiB 0.09% 1.266 KiB/648 B
prickly_hypatia 0.00% 740 KiB/1.961 GiB 0.04% 1.898 KiB/648 B
より詳細な統計情報を取得したい場合は、netcat を介して Docker のリモート API を使うと良いです。HTTP の GET リクエストを /containers/[CONTAINER_NAME]/stats に対して送ることで、統計情報を取得することができます。実際に取得できる統計情報の詳細はここで確認できます。キャッシュ、スワップ領域などのメモリーの詳細を確認することができます。
echo -e "GET /containers/[CONTAINER_NAME]/stats HTTP/1.0\r\n" | nc -U /var/run/docker.soc
スコア表:
- デプロイが簡単か: 5
- 取得できる情報の詳細度: 5
- 全コンテナからの集計度: NA
- アラートの生成: NA
- Docker 以外のリソース監視: NA
- 費用: 無料
Docker Stats コマンドで取得した情報を GUI で描画することができるツールです。 次の Docker コマンドを実行して、「http://localhost:8080/」 にアクセスするだけです。
docker run \
--volume=/:/rootfs:ro \
--volume=/var/run:/var/run:rw \
--volume=/sys:/sys:ro \
--volume=/var/lib/docker/:/var/lib/docker:ro \
--publish=8080:8080 \
--detach=true \
--name=cadvisor \
google/cadvisor:latest
CPU やメモリーの使用量、ネットワークのスループット、ディスクの空き容量をグラフで確認することができます。ポータルの上部から特定のコンテナを選択してデータを掘り下げたり、コンテナに設定された制限を確認することができます。
CAdvisor は、簡単なセットアップで使える便利なツールです。サーバ内に ssh 接続で入ってリソースの使用量を見たり、グラフを生成する労力は必要ないのです。圧力計は追加のリソースがいつ必要になるか手軽に眺めることができます。
しかし、CAdvisor には 1台の Docker ホストしか監視できないという制限があります。そのため、デプロイ先として複数のノードがある場合、統計情報がクラスター内でばらばらに広がってしまいます。
Kubernetes を動作していて、複数ノードを監視したいのなら、heapster というツールが有効です。図表内のデータは1分間隔で重み付けされ、長期間の傾向を見ることはできません。リソースの使用量が危険水域に達しても、アラートを発生させる機構はありません。
コンテナ/クラスターのリソース使用量の可視化の経験がないのなら、CAdvisor はコンテナ監視の最初の一歩として良いかもしれません。しかし、コンテナで基幹業務を走らせているのなら、より堅牢なツールかアプローチが必要になります。Rancher では、CAdvisor が接続した各々のホスト上で動作しており、限られた統計情報を UI を通して、全てのシステムの統計情報を API を通して外部にさらしています。
スコア表: ※ heapster は除外しています
- デプロイが簡単か: 5
- 取得できる情報の詳細度: 2
- 全コンテナからの集計度: 1
- アラートの生成: NA
- Docker 以外のリソース監視: NA
- 費用: 無料
続いて、CAdvisor の制約のいくつかを解決することができる Scout を紹介します。Scout はマネージドな監視サービスで、多くのホストやコンテナからメトリックを集約でき、長期間データを保持することができます。フリートライアルがあるので、まずはそこから始めてみるとよいでしょう。アカウントを登録した後、Account Basics にある Account Key をメモしましょう。Account Key は Docker サーバからメトリックを送信するのに必要です。
次に、ホスト上で、「scoutd.yml」というファイルを作成して、次のテキストをファイルの中に書き込みましょう。「host」や「display_name」、「environment」、「roles」プロパティは、メトリックを識別するために使うので、意味のある値を指定するようにしましょう。
# account_key is the only required value
account_key: YOUR_ACCOUNT_KEY
hostname: web01-host
display_name: web01
environment: production
roles: web
以下の Docker scout plugin を使って、scout の設定ファイルをもとに、scout のエージェントを連れてきましょう。
docker run -d --name scout-agent \
-v /proc:/host/proc:ro \
-v /etc/mtab:/host/etc/mtab:ro \
-v /var/run/docker.sock:/host/var/run/docker.sock:ro \
-v `pwd`/scoutd.yml:/etc/scout/scoutd.yml \
-v /sys/fs/cgroup/:/host/sys/fs/cgroup/ \
--net=host --privileged \
soutapp/docker-scout**work in progress**
それでは、Scout のウェブページに戻りましょう。display_name パラメータで指定した名前でエージェントからの入力を確認できるはずです。
表示名をクリックすることで、ホストのメトリックの詳細が表示されます。ホストで動作している全プロセッサー数、CPU 使用量、メモリー使用率が含まれています。Docker 内部で動作している。
Docker の監視を追加するには、Roles タブをクリックし、[All Servers]をクリックして下さい。[+ Plugin Template] ボタンを押すと、「Docker Monitor」に、以下の詳細が画面に表示されます。
キリがないので詳細な手順は省く!!!!
CAdvisor より Scout を使う別の利点は、Docker の情報に加え、デプロイしたアプリケーションのデータを取り込むことができる豊富なプラグインです。様々なリソースを別々の監視システムで監視するのではなく、ワンストップで実現することができます。
Scout の欠点を1つ挙げるなら、CAdvisor なら可能な個別のコンテナの詳細な情報を表示できないことです。同一のサーバ上で異なるコンテナを動作させている場合、これは問題となります。例えば、Jenkins コンテナではなく、Web コンテナのアラートをトリガーとしたい場合、Scout ではそのようなユースケースをサポートしていないのです。この欠点にも関わらず、Scout は Docker コンテナの非常に有用なツールです。しかし、監視するホスト単位で 10 ドルの月額料金が掛かります。
- デプロイが簡単か: 4
- 取得できる情報の詳細度: 2
- 全コンテナからの集計度: 3
- アラートの生成: 3
- Docker 以外のリソース監視: Supported
- 費用: $10 /host
- デプロイが簡単か: 5
- 取得できる情報の詳細度: 5
- 全コンテナからの集計度: 5
- アラートの生成: Supported
- Docker 以外のリソース監視: 5
- 費用: $15 /host
Scout と Datadog には中央集権的な監視とアラートがありますが、どちらもホスティングサービスであるため、大規模な配備に対して高額になります。セルフホスティングで、中央集権的なメトリックサービスを求めるなら、sensu open source monitoring framework を検討してみては。Sensu サーバを走らせるために、hiroakis/docker-sensu-server コンテナが使えます。このコンテナは、sensu サーバ、uchiwa ウェブインターフェイス、Redis、RabbitMQ サーバ、sensu API を含みます。残念ながら、sensu はその枠を超えた Docker に一切対応していません。しかし、プラグインを使えば、コンテナのメトリックと状態チェックの両方に対応する設定ができます。sensu サーバのコンテナを起動する前に、サーバ内でロードされる「Check」を定義しなければなりません。「check-docker.json」というファイルを作り、以下の内容をそのファイルに追加して下さい。このファイルの中で、load-docker-metrics.sh というスクリプトを、10 秒ごとに docker タグの付いた全てのクライアント上で走らせるよう Sensu サーバに伝えています。このスクリプトは後ほど定義します。
{
"checks": {
"load_docker_metrics": {
"type": "metric",
"command": "load-docker-metrics.sh",
"subscribers": [
"docker"
],
"interval": 10
}
}
}以下のコマンドで、Check の設定ファイルをもった sensu サーバの docker コンテナを 実行することができます。コマンドを実行すると、uchiwa のダッシュボードを「http://YOUR_SERVER_IP:3000」で起動することができます。
docker run -d --name sensu-server \
-p 3000:3000 \
-p 4567:4567 \
-p 5671:5671 \
-p 15672:15672 \
-v $PWD/check-docker.json:/etc/sensu/conf.d/check-docker.json \
hiroakis/docker-sensu-server
sensu サーバが起動しているので、sensu クライアントを docker コンテナが起動している各ホストで動かし始めましょう。コンテナが 「load-docker-metrics.sh」と呼ばれるスクリプトを持っていることはサーバに既に伝えてあります。ですので、スクリプトを作って、クライアントコンテナ内に入れてしまいましょう。ファイルを作って、以下の内容をファイルに追加して下さい。「HOST_NAME」 の部分は意味のあるホストの名前に置き換えてください。以下のスクリプトは、実行中のコンテナ、ホスト上のあらゆるコンテナとイメージのメタデータを制御するために Docker Remote API を使っています。そして、sensu の Key-Value 記法を用いて値を出力しています。sensu サーバは標準出力から出力された値を読み取り、それらのメトリックを収集します。この例では、3つの値のみ引っ張ってきていますが、必要に応じて check スクリプトを作成可能です。以前作成したサーバの設定ファイルで check スクリプトを参照するなら、複数の check スクリプトを追加することも可能です。起動中のコンテナが3つ以下になった場合に、ckeck が失敗するよう定義することも可能です。check スクリプトから0でない値が返ってきたら check を失敗させればよいのです。
#!/bin/bash
set -e
# Count all running containers
running_containers=$(echo -e "GET /containers/json HTTP/1.0\r\n" | nc -U /var/run/docker.sock \
| tail -n +5 \
| python -m json.tool \
| grep \"Id\" \
| wc -l)
# Count all containers
total_containers=$(echo -e "GET /containers/json?all=1 HTTP/1.0\r\n" | nc -U /var/run/docker.sock \
| tail -n +5 \
| python -m json.tool \
| grep \"Id\" \
| wc -l)
# Count all images
total_images=$(echo -e "GET /images/json HTTP/1.0\r\n" | nc -U /var/run/docker.sock \
| tail -n +5 \
| python -m json.tool \
| grep \"Id\" \
| wc -l)
echo "docker.HOST_NAME.running_containers ${running_containers}"
echo "docker.HOST_NAME.total_containers ${total_containers}"
echo "docker.HOST_NAME.total_images ${total_images}"
if [ ${running_containers} -lt 3 ]; then
exit 1;
fi
起動中の Docker メトリックの check を定義したので、私がこの目的のために作った usman/sensu-client コンテナを使って sensu クライアントを起動します。以下のコマンドで、sensu クライアントを起動して下さい。Unix ソケットにアクセス可能な特権モードでコンテナを起動するようにしてください。上記で定義した「load-docker-metrics.sh」と docker socket をボリュームとしてマウントしなければなりません。コンテナ内に権限が委譲されることで、「load-docker-metrics.sh」スクリプトがホストマシン上から実行可能か確認して下さい。コンテナには、SENSU_SERVER_IP, RABIT_MQ_USER, RABIT_MQ_PASSWORD, CLIENT_NAME と CLIENT_IP を パラメータとして取りますので、これらのパラメータを設定時に指定するようにしてください。RABIT_MQ_USER RABIT_MQ_PASSWORD のデフォルトの値は「sensu」と「password」です。
docker run -d --name sensu-client --privileged \
-v $PWD/load-docker-metrics.sh:/etc/sensu/plugins/load-docker-metrics.sh \
-v /var/run/docker.sock:/var/run/docker.sock \
usman/sensu-client SENSU_SERVER_IP RABIT_MQ_USER RABIT_MQ_PASSWORD CLIENT_NAME CLIENT_IP
このコマンドを実行してから数秒経つと、uchiwa ダッシュボードでクライアントの総数が 1 に増加するのを確認できるはずです。クライアントのアイコンをクリックし、先ほど追加したクライアントが含まれているかどうかクライアント一覧で確認して下さい。私は、クライアントの名前を client-1 とし、ホストの IP は 192.168.1.1 と指定しました。
クライアントの名前をクリックすると、check のより詳細な情報を確認できます。load_docker_metrics check が 3/28 の 10:22 に走ったことが確認できます。
check の名前をクリックすると click の動作に関する詳細な情報を確認できます。0 はエラーが発生しなかったことを指しており、仮にスクリプトが失敗すると (例えば docker のデーモンが死んだり)、0 でないエラーコードが表示されます。この記事では詳細を省きますが、check が失敗した場合に、Handlers を使って、sensu にアラートを発するよう設定することもできます。さらに、uchiwa は check の値だけを表示し、収集したメトリックは表示しません。sensu は収集したメトリックを保管しないので、InfluxDB や Graphite などの時系列データベースに転送する必要があります。これも Handlers を通して実行できます。Graphite へのメトリックの転送に関してはこの記事を参照してください。
Sensu は我々の評価基準の全ての要件を満たしています。必要であれば、Docker コンテナやホストの多くの詳細な情報を収集することができます。さらに、外部にあるホスト上の全ての値を一カ所に集めることができ、それらの check を通してアラートを上げることもできます。アラートは、DataDog や Scout ほど高度ではなく、個々のホストで check が失敗したときにアラートを上げることしかできません。しかし、Sensu の大きな欠点はデプロイの難しさなのです。Docker コンテナを使ってデプロイのステップの多くを自動化していますが、それでもなお Sensu は、Redis, RabitMQ, Sensu API, uchiwa と Sensu Core のインストールや起動、分離したプロセスの維持など複雑なシステムなのです。さらに、現在のメトリックの値を表示するためには、Graphite などの追加のツールが必要です。また、本番環境へデプロイする場合、コンテナのカスタマイズが必要で、今回、セキュアなパスワードや独自の SSL 証明書を使っています。さらに、コンテナを起動した後に、check を追加しようと思うと、Sensu サーバを再起動しなければなりません。これが新しいメトリックを収集し始めるための唯一の方法なのです。これらの理由から Sensu の「デプロイが簡単か」の項目に低い点数をつけています。
- デプロイが簡単か: 1
- 取得できる情報の詳細度: 4
- 全コンテナからの集計度: 5
- アラートの生成: Supported but limited
- Docker 以外のリソース監視: 5
- 費用: 無料
- デプロイが簡単か: 2
- 取得できる情報の詳細度: 5
- 全コンテナからの集計度: 5
- アラートの生成: 4
- Docker 以外のリソース監視: Supported
- 費用: 無料
- デプロイが簡単か: 3
- 取得できる情報の詳細度: 5
- 全コンテナからの集計度: 5
- アラートの生成: 4
- Docker 以外のリソース監視: Supported
- 費用: サポート問い合わせ
!!work in progress!!