mackerel-container-agent(パブリックベータ)を試してみる

監視サービス

#Mackerel

#監視サービス

吉江健斗

2019.02.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちわ、札幌のヨシエです。

先日、mackerel-container-agentのパブリックベータ版がリリースされましたので試してみました。

Mackerelコンテナエージェント（パブリックベータ）を公開しましたほか

パブリックベータ版のため、今後仕様変更が発生する可能性がございますので下記のリンクより最新情報をご確認いただけますと幸いです。

Mackerel Blog #mackerelio

何が変わるのか？

結果を先に記載するとmackerel-container-agentをECS(EC2/Fargate,Kubernetes)で動作しているコンテナへサイドカーで起動することで動作しているコンテナのリソース状況を監視することが可能になります。

これまでの課題として、ECS(EC2)ではホストインスタンスにmackerel-agentを起動してプラグインによって起動コンテナのリソース状況を確認できました。

反面Fargateのようにホストインスタンスにログインできない環境ではmackerel-agentのインストールが出来ませんでしたが、mackerel-container-agentをサイドカーで起動することによりコンテナのリソース状況が確認できるようになりました。

実際にはどのような形になるか見てみましょう。

今回、例題として挙げたのは3Tierのシステムパターンとしており、ECSのコンテナホストはEC2インスタンスとしております。

mackerel-container-agent未導入

こちらの図はmackerel-agentとAWSインテグレーションを利用した監視パターンとなります。以下のような区分でシステム監視を想定しております。

URL監視
Mackerel自体からELBへアクセスすることでURL監視を行います
各リソース監視
AWSインテグレーション機能を用いてリソース状況をCloudWatchより取得することで監視を行います。
ECSのホストインスタンスへmackerel-agentをインストールし、提供されているプラグインを使用することでELB、Database、実行しているDockerコンテナのリソース状況を取得します

mackerel-container-agent導入

次に以下の図はmackerel-container-agentのコンテナを追加起動して監視するパターンとなります。基本的な監視方法は未導入と同様ですが、mackerel-agentにてmackerel-plugin-dockerを指定せずにコンテナ環境を監視できるようになりました。

具体的にEC2内部の監視は以下のような形で監視する形となります。

EC2インスタンス(mackerel-agent)
OS
Dockerプロセス
起動コンテナ(mackerel-container-agent)
mackerel-container-agentを起動することで、各コンテナの使用リソース状況を監視できます。

実際には以下のようなレイヤーに分界される形と考えます。

対応対応しているプラットフォーム

対応しているプラットフォームは以下となります。注意点としてWindowsコンテナは未サポートとなりますので、導入の際はご注意ください。

Amazon EC2 Container Service
Amazon EC2
AWS Fargate
Kubernetes

ECS環境へのmackerel-container-agent導入方法について

mackerel-container-agentを導入する点でネットワークモードによって大きく変化します。パターンとしては以下の2パターンとなります。

コンテナホスト種別	ネットワークモード	パターン
EC2	bridge	Aパターン
EC2	host	Aパターン
EC2	none	Aパターン
EC2	awsvpc	Bパターン
Fargate	awsvpc	Bパターン

それぞれのネットワークモードは以下の記事にてまとまっておりますのでご参照頂ければと存じます。

ECSでEC2インスタンスを利用する際のネットワークモードについて調べてみた

Aパターンセットアップ方法

Aパターンは基本的なDocker構成となります。全体イメージとして、タスク定義より監視対象のコンテナとサイドカーパターンで設定を行う事とコンテナに対してホストインスタンスの特定ディレクトリをボリュームマウントすることと環境変数を追加することで導入が実現できます。

また、AmazonLinux またはAmazonLinux2でmackerel-container-agentへのマウントポイントが異なりますのでご注意ください。

タスク設定(ボリューム)

AmazonLinux,AmazonLinux2のそれぞれソースパスが異なります。それぞれのディストリビューションに応じて、適切な設定を投入する必要があります。

AmazonLinuxの場合

ソースボリューム	コンテナパス
/cgroup	cgroup
/var/run/docker.sock	docker_sock

AmazonLinux2の場合

ソースボリューム	コンテナパス
/sys/fs/cgroup	cgroup
/var/run/docker.sock	docker_sock

コンテナ定義設定

次に実際のコンテナ設定を実施します。実際のコンテナ設定で以下の設定をmackerel-container-agentへ投入する必要があります。

環境変数
MACKEREL_CONTAINER_PLATFORM: ecs
MACKEREL_APIKEY: xxxxxx
MACKEREL_ROLES: <ロール名> ※MACKEREL_ROLES厳密には必須項目ではありませんが、管理面より必須として扱っております
マウントポイントボリュームマウントにて指定したソースボリュームを以下のようにコンテナへマウントします。

ソースボリューム	コンテナパス
/cgroup	/host/sys/fs/cgroup
docker_sock	/var/run/docker.sock

上記以外は、運用形態に合わせて変更する形が良いと思われます。

Bパターンセットアップ方法

Bパターンは主にawsvpcやFargateを利用してコンテナホストを考慮しないパターンです。

主に対応する点はAパターンと同様にタスク定義を変更します。

コンテナ定義設定

コンテナ設定を実施します。 Aパターンと異なるのはボリューム設定が不要であることと、以下の環境変数で指定する変数の値が変更されることです。

環境変数
MACKEREL_CONTAINER_PLATFORM
ecs_awsvpc(awsvpcの場合に使用)
fargate(Fargateの場合に使用)
MACKEREL_APIKEY: xxxxxx
MACKEREL_ROLES: <ロール名>

最後に

今回はパブリックベータとして発表されたmackerel-container-agentを使用した中で環境変数の指定はParameterStoreのような外部ストレージへ保存することがより大切かと思いました。これはAPIキーをマスクする観点も考えましたが、運用面で設定値を都度書くことのはめんどくさいという印象を持ちました。