1クール続けるブログ

とりあえず1クール続けるエンジニアの備忘録

ECSでnode exporterのネットワーク関係のメトリクスが取れない

ネットワークのメトリクス大事ですよね

障害が発生したときなどに、何が起因なのか切り分ける場合などにネットワークのメトリクスはとても大事になると思います。 例えば、TCPのコネクションなどはデータベースとの接続を見るときとかに役に立ちますよね。

node exporter で上手くメトリクスが取れない…?

PrometheusとGrafanaで監視ツールを構成していた場合に、node exporterを使って、コンテナが乗っているノードのメトリクスを取ることが多いと思います。

ある日、ECSでコンテナを動かしていたときに、ネットワーク関係のメトリクスが上手く取れていないことに気がつきました。

明らかに0でない値が入るであろうメトリクスなのに0で取得されるというものです。

何が原因だったのか

私の予想・考察的要素もあります。ご注意ください。

ECSでポートマッピングを使いたかったため、ネットワークモードをBridgeにして使用していました。デフォルトもBridgeだったはずです。

Bridgeモードはdockerデーモンを起動した際に作成される仮想ブリッジdocker0を使用します。 docker0に割り当てられるIPアドレス空間は、ホストの既存の空いているIPアドレスから特定の範囲を取ってきたものです。

このdocker0に紐付いたveth(Virtual Ethernet)インターフェースが割り当てられ、コンテナは外部と通信するときにに、このvethを経由することになる。 画像は以下から引用させていただきました。 Docker - Docker Reference Architecture: Designing Scalable, Portable Docker Container Networks

network namespaceが別々になっていることがわかります。netstatで取得できたメトリクスはこのコンテナのnetwork namespace内の情報だったと思われます。

実際に外部とのコネクションを持ってるのはホストなので、想定するメトリクスが得られないのではと結論づけました。

どのように対応したか

ホストのネットワークスタックを監視するようにコンテナのネットワークモードをhostに変更しました。

図を見てわかる通り、vethを経由せず、同じnetwork namespace内で通信を行います。 この場合だと期待されたメトリクスを取得することができました。

まとめ

監視の際のノードのメトリクス取得はdockerのネットワークモードを考慮する必要性がある。