【祝！正式リリース】Mackerelでコンテナのリソース監視がリリースされました #mackerelio

こんにちわ、札幌のヨシエです。
以前にブログで紹介させて頂いたmackerel-container-agent(パブリックベータ)が6/18(火)より正式リリースされました。

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

今回は以前のパブリックベータ版から導入方法が変更になったので、紹介を兼ねて設定方法を共有いたします。

正式/パブリックベータ版の大まかな設定方法差分について

ポイント①：コンテナの配置方法について

Mackerelにてコンテナ監視を行うにはmackerel-container-agentを監視したいタスクのサイドカーとして起動する必要がありますがここは変わりません。

ポイント②：コンテナのリソース状況取得方法が変わった

以前のパブリックベータ版では、cgroupfsをmackerel-container-agentにボリュームマウントすることでコンテナの利用状況を取得しておりましたが、この監視方法は非推奨となりました。
コンテナを監視する

詳細はセットアップ手順をご参照頂ければと思いますが、監視対象のタスクにAPIキーを環境変数で設定したコンテナが起動することで監視が開始されます。

ポイント③：エージェント自身へプラグインが同梱

mackerel-container-agentでは、mackerel-agentで利用出来るプラグインが同梱版として提供されております。 コンテナイメージの提供方法はタグ指定で提供しており、以下のタグ名指定にてプラグイン有無のコンテナを起動できます。
※mackerel-container-agent/usr/local/bin、 pluginsは/usr/binに配置されております。

2019/06/21現在

ポイント④：コンフィグファイルの分離

一般的にはエージェントと振る舞いを指定するコンフィグファイルは同じサーバー内に保存されることが多いかと思います。
mackerel-container-agentでは上記のようなファイルパスによる設定ファイル指定の他にhttp/httpsとAmazon S3で設定ファイルを定義することが出来ます。

このようにファイルパス指定以外でコンフィグファイルを指定することで、インスタンスにログインする手間を省くことやサービス提供と監視を分離して作業を実現することができ、オペミスの危険性を減らすことにつながるかと思います。

mackerel-container-agentの設定方法

ポイント①に記載しているように正式リリース版のmackerel-container-agentを起動するのみとなります。

前提条件(ECS)

• ECSで管理しているコンテナホストが起動していること

タスク定義

タスク定義画面から「コンテナの定義」より、mackerel-container-agentのイメージ場所、メモリ制限、環境変数を指定します。

タスク定義後、サービスの更新などを使用してコンテナを起動します。

コンテナの起動に成功することでmackerel画面より、各タスクで起動しているコンテナのリソース状況が監視できるようになります。

最後に

パブリックベータの時点に比べて、グッとコンテナ環境監視設定が簡単になったかと思います。 mackerel-container-agentが発表されてから一番気に入っている点としてagentの設定ファイルが外出し出来る点はとてもメリットととして感じており、
これは設定ファイルを導入してから再起動などのリロードオペレーションで初めて設定内容の確認が出来たりと多少リスクを伴うものがありましたが、 外出にすることで予めシンタックスチェックなどを仕組み化することで設定を投入できたり、S3などのバージョニングが利用できたりと多種多様の使い方ができるようになって嬉しいことが多いと思います。 (mackerel-agentも同じ様になっていただきたいですが、これは別途はてなさんにお願いしたいと思います)

また、EC2とFargateによるコンテナホストによる導入方法差異が統一されたことでより、導入ハードルが低くなりました。 このように新機能リリースでは監視環境の導入がしやすくなるばかりなので、ぜひ開発環境などで触ってみて頂けると良さがわかるかと思いました。

※ふと、気になったのがメトリックの取得方法に関しては明言されておりませんでした。もしかするとTask Metadata Endpointの関係があるかもしれません。

ECSにおけるタスクメタエンドポイント(Task Metadata Endpoint)について整理しました