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

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

先日、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パターンとなります。

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

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

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

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

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

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

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

AmazonLinuxの場合

AmazonLinux2の場合

コンテナ定義設定

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

• 環境変数
• MACKEREL_CONTAINER_PLATFORM: ecs
• MACKEREL_APIKEY: xxxxxx
• MACKEREL_ROLES: <ロール名> ※MACKEREL_ROLES厳密には必須項目ではありませんが、管理面より必須として扱っております

• マウントポイント ボリュームマウントにて指定したソースボリュームを以下のようにコンテナへマウントします。

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

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

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

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

コンテナ定義設定

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

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

最後に

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