Prometheusでホストのメトリクスを収集するのが、prometheus/node_exporterである。AWSのECSを使用する場合、コンテナを動かすためのインスタンスを自分で設定するため、Prometheusで監視するための設定をUSER DATAに仕込むことになるのだが、もっと簡単に、node_exporterをコンテナとして動かす手もある。

node_exporterのオプションとファイルシステムのマッピング
node_exporterをコンテナとして動かすということは、コンテナ側からホスト(ECSインスタンス)の情報を収集するということである。単純に動かしただけではコンテナの中での情報しか集まらないので、タスクを定義する際、起動オプションを指定する必要がある。
"--path.rootfs","/host",
"--path.procfs","/host/proc",
"--path.sysfs","/host/sys",
"--collector.filesystem.ignored-mount-points","\"^/(sys|proc|dev|host|etc)($|/)\""
また、ホストのディレクトリをコンテナにマウントして、コンテナからホスト側のファイルにアクセスできるようにする。読み出すだけなのでRead Onlyオプションをつけて、間違って書き換えることのないようにする。
/proc -> /host/proc
/sys -> /host/sys
/ -> /rootfs
左がホストのディレクトリ、右がコンテナ。ECSのタスク定義だと、ホストのディレクトリの指定とコンテナへのマウントがわかれているので、最初はちょっと戸惑うかもしれない。
また、ネットワークモードはhost、ポートマッピングはTCP 9100を指定しておく。
タスクの配置はDAEMON
タスクを定義したら、次はそれを使うサービスを定義する。サービスでは、タスクをいくつ動かすか、ECSインスタンスにどう配置するかを設定できる。
ここで、Service typeを「DAEMON」とすると、各ECSインスタンスに1つずつタスクを配置するようになる。
USER DATAでセットアップするよりも楽
ECSインスタンスのAMIを自分で作成することもできるが、Dockerやecs-agentのアップデートを考えると、AWS公式のAMIを使用するのが良さそうに思える。
この場合、node_exporterをセットアップするには、USER DATAを使用するくらいしか思いつかないが、意外と面倒に感じる。
コンテナを使えばもう少し楽だし、タスク定義は複数のECSクラスタで利用できるので、node_exporterのコンテナを使うというのは、アリだと思う。
コメント