Dockerコンテナ監視の原理とcAdvisorのインストールおよび使用方法

本番環境におけるコンテナの稼働状況を監視することは非常に重要です。監視を通じて、コンテナの稼働状況をいつでも把握し、オンライン上のリスクや問題を早期に発見して解決することができます。

そこで今日は、コンテナ監視（cAdvisor の原則とツール）に関する知識を皆さんと共有したいと思います。

従来の物理マシンと仮想マシンの監視にはすでに比較的成熟した監視ソリューションがありますが、コンテナの動作と性質は従来の仮想マシンとは異なるため、コンテナの監視には大きな課題があります。一般に、コンテナには次の特性があります。

コンテナは短命であり、動的にスケジュールできる

コンテナの本質はプロセスであり、完全なオペレーティングシステムではない

コンテナは非常に軽量であるため、従来の仮想マシンよりも頻繁に作成および破棄されます。

Docker コンテナの監視ソリューションは数多くあります。Docker に付属する docker stats コマンドのほかにも、sysdig、cAdvisor、Prometheus など、優れた監視ツールであるオープンソース ソリューションが数多くあります。

まず、外部ツールを使わずに Docker 独自の docker stats コマンドを使用してコンテナを監視する方法を見てみましょう。

docker statsコマンドの使用

Docker に付属する docker stats コマンドを使用すると、ホスト上のすべてのコンテナの CPU、メモリ、ネットワーク IO、ディスク IO、PID、その他のリソースの使用状況を簡単に確認できます。具体的な操作については以下で見ていきましょう。

まず、ホスト上で次のコマンドを使用して、リソース制限が 1 コア、2G の nginx コンテナを起動します。

$ docker run --cpus=1 -m=2g --name=nginx -d nginx

コンテナが起動したら、docker stats コマンドを使用してコンテナのリソース使用状況を表示できます。

$ docker 統計 nginx

docker stats コマンドを使用すると、次のようにコンテナの実行ステータスを確認できます。

コンテナ CPU % メモリ使用量 / メモリ制限 % ネット I/O ブロック I/O PID

f742a467b6d8 0.00% 1.387 MiB / 2 GiB 0.07% 656 B / 656 B 0 B / 9.22 kB 2

コンテナの実行ステータスから、docker stats コマンドは実際に Docker コンテナの実行ステータスを取得して表示できることがわかります。しかし、ローカルデータしか取得できず、履歴監視データを表示できず、視覚的な表示パネルがないため、欠点も明らかです。

そのため、実稼働環境では通常、別のコンテナ監視ソリューションである cAdvisor を使用します。

cアドバイザー

cAdvisor は、Google がオープンソース化した一般的なコンテナ監視ソリューションです。 cAdvisor は、マシン上で実行されているすべてのコンテナに関する情報を収集できるだけでなく、基本的なクエリ インターフェイスと HTTP インターフェイスも提供し、外部システムとの統合を容易にします。そのため、cAdvisor はすぐにコンテナ メトリックの監視に最もよく使用されるコンポーネントとなり、Kubernetes もコンテナ監視メトリックのデフォルト ツールとして cAdvisor を統合しました。

cAdvisorのインストールと使用

以下では、cAdvisor 0.37.0 バージョンを例に、cAdvisor のインストールと使用方法を説明します。

cAdvisor は Docker イメージを公式に提供しています。イメージをプルして起動するだけです。

cAdvisor イメージは Google の gcr.io イメージ リポジトリに保存されているため、中国ではアクセスできません。ここではビルドしたイメージをDocker Hubに置きます。 docker pull lagoudocker/cadvisor:v0.37.0 コマンドを使用して、Docker Hub からプルできます。

まず、次のコマンドで cAdvisor を起動します。

$ docker 実行 \
 --volume=/:/rootfs:ro \
 --volume=/var/run:/var/run:ro \
 --volume=/sys:/sys:ro \
 --volume=/var/lib/docker/:/var/lib/docker:ro \
 --volume=/dev/disk/:/dev/disk:ro \
 --publish=8080:8080 \
 --detach=true \
 --name=cadvisor \
 --特権 \
 --device=/dev/kmsg \
 ラグドッカー/cadvisor:v0.37.0

この時点で、cAdvisor は正常に起動しており、http://localhost:8080 にアクセスして cAdvisor Web インターフェイスにアクセスできます。

cAdvisor は、コンテナ リソースの使用状況だけでなく、ホスト リソースの使用状況も監視できます。次に、ホスト リソースの使用状況をチェックする方法を見てみましょう。

cAdvisorを使用してホスト監視を表示する

http://localhost:8080/containers/ にアクセスします。下の図に示すように、CPU、メモリ、ファイルシステム、ネットワーク、その他のリソースを含むホストのリソース使用状況をホームページで確認できます。

cAdvisor を使用してコンテナの監視を表示する

ホスト上で実行されているコンテナのリソース使用量を確認する場合は、http://localhost:8080/docker/ にアクセスしてください。このページには、下の図に示すように、Docker の基本情報と実行中のコンテナが一覧表示されます。

上の図では、「サブコンテナ」の下に、現在のホストで実行されているすべてのコンテナがリストされています。コンテナの 1 つをクリックすると、次の図に示すように、コンテナの詳細な実行ステータスが表示されます。

一般に、cAdvisor を使用してコンテナを監視すると、次の機能が得られます。

物理マシンとコンテナのステータスを同時に収集できる

監視履歴データを表示できる

Docker の監視ツールについて理解できたところで、これらの監視データはどこから来るのか疑問に思っていませんか?次に、コンテナ監視の原理について説明します。

監視の原則

Docker は、名前空間、Cgroup、およびユニオン ファイル システムに基づいて実装されていることがわかっています。 cgroups はコンテナ リソースを制限するだけでなく、コンテナ リソースの使用率を高めるためにも使用できます。監視ソリューションの実装に関係なく、基礎となるデータは Cgroups から取得されます。

Cgroups の作業ディレクトリは /sys/fs/cgroup であり、/sys/fs/cgroup ディレクトリには Cgroups のすべてのコンテンツが含まれています。 cgroups には、さまざまなリソースを制限するために使用できる多くのサブシステムが含まれています。たとえば、CPU、メモリ、PID、ディスク IO などのリソースを制限および監視します。

Cgroups サブシステムをより詳細に理解するために、ls -l コマンドを使用して /sys/fs/cgroup フォルダーを表示し、多くのディレクトリを確認します。

$ sudo ls -l /sys/fs/cgroup/
合計 0
 
dr-xr-xr-x 5 ルート ルート 0 7月9日 19:32 blkio
lrwxrwxrwx 1 ルート ルート 11 7月 9 19:32 cpu -> cpu,cpuacct
dr-xr-xr-x 5 ルート ルート 0 7月9日 19:32 cpu、cpuacct
lrwxrwxrwx 1 ルート ルート 11 7月 9 19:32 cpuacct -> cpu,cpuacct
dr-xr-xr-x 3 ルート ルート 0 7月9日 19:32 cpuset
dr-xr-xr-x 5 ルート ルート 0 7月9日 19:32 デバイス
dr-xr-xr-x 3 ルート ルート 0 7月9日 19:32 フリーザー
dr-xr-xr-x 3 ルート ルート 0 7月9日 19:32 hugetlb
dr-xr-xr-x 5 ルート ルート 0 7月9日 19:32 メモリ
lrwxrwxrwx 1 ルート ルート 16 7月 9 19:32 net_cls -> net_cls、net_prio
dr-xr-xr-x 3 ルート ルート 0 7月9日 19:32 net_cls、net_prio
lrwxrwxrwx 1 ルート ルート 16 7月 9 19:32 net_prio -> net_cls、net_prio
dr-xr-xr-x 3 ルート ルート 0 7月9日 19:32 perf_event
dr-xr-xr-x 5 ルート ルート 0 7月9日 19:32 pids
dr-xr-xr-x 5 ルート ルート 0 7月9日 19:32 systemd

これらのディレクトリは Cgroups サブシステムを表し、Docker は各 Cgroups サブシステムの下に docker フォルダーを作成します。 Cgroups サブシステムについてよく知らない場合でも心配はいりません。コンテナ監視データが Cgroups から取得されることを理解するだけで十分です。

監視システムはコンテナのメモリ制限をどのように取得しますか?

次に、メモリ サブシステム (メモリ サブシステムは Cgroup の多くのサブシステムの 1 つで、主にメモリ使用量を制限するために使用されます) を例に、監視コンポーネントがコンテナのリソース制限と使用状況 (つまり、コンテナのメモリ制限) を取得する方法について説明します。

まず、次のコマンドを使用して、ホスト上で 1 コアと 2G のリソース制限を持つ nginx コンテナを起動します。

$ docker run --name=nginx --cpus=1 -m=2g --name=nginx -d nginx

## ここでの出力はコンテナIDです

51041a74070e9260e82876974762b8c61c5ed0a51832d74fba6711175f89ede1

注意: nginx という名前のコンテナをすでに作成している場合は、まず docker rm -f nginx コマンドを使用して既存の nginx コンテナを削除してください。

コンテナが起動すると、コマンドラインの出力からコンテナ ID を取得できます。同時に、Docker はコンテナ ID を名前として、/sys/fs/cgroup/memory/docker ディレクトリに対応するフォルダーを作成します。

/sys/fs/cgroup/memory/docker ディレクトリ内のファイルを見てみましょう。

$ sudo ls -l /sys/fs/cgroup/memory/docker
合計 0
 
drwxr-xr-x 2 ルート ルート 0 9月 2 15:12 51041a74070e9260e82876974762b8c61c5ed0a51832d74fba6711175f89ede1
-rw-r--r-- 1 ルート ルート 0 9月 2日 14:57 cgroup.clone_children
--w--w--w- 1 ルート ルート 0 9月 2日 14:57 cgroup.event_control
-rw-r--r-- 1 ルート ルート 0 9月 2日 14:57 cgroup.procs
-rw-r--r-- 1 ルート ルート 0 9月 2日 14:57 メモリ.failcnt
--w------ 1 ルート ルート 0 9月 2日 14:57 memory.force_empty
-rw-r--r-- 1 ルート ルート 0 9月 2日 14:57 memory.kmem.failcnt
-rw-r--r-- 1 ルート ルート 0 9月 2日 14:57 memory.kmem.limit_in_bytes
-rw-r--r-- 1 ルート ルート 0 9月 2日 14:57 memory.kmem.max_usage_in_bytes
-r--r--r-- 1 ルート ルート 0 9月 2日 14:57 memory.kmem.slabinfo
-rw-r--r-- 1 ルート ルート 0 9月 2日 14:57 memory.kmem.tcp.failcnt
-rw-r--r-- 1 ルート ルート 0 9月 2日 14:57 memory.kmem.tcp.limit_in_bytes
-rw-r--r-- 1 ルート ルート 0 9月 2日 14:57 memory.kmem.tcp.max_usage_in_bytes
-r--r--r-- 1 ルート ルート 0 9月 2日 14:57 memory.kmem.tcp.usage_in_bytes
-r--r--r-- 1 ルート ルート 0 9月 2日 14:57 memory.kmem.usage_in_bytes
-rw-r--r-- 1 ルート ルート 0 9月 2日 14:57 メモリ制限バイト数
-rw-r--r-- 1 ルート ルート 0 9月 2日 14:57 メモリ.max_usage_in_bytes
-rw-r--r-- 1 ルート ルート 0 9月 2日 14:57 memory.memsw.failcnt
-rw-r--r-- 1 ルート ルート 0 9月 2日 14:57 memory.memsw.limit_in_bytes
-rw-r--r-- 1 ルート ルート 0 9月 2日 14:57 memory.memsw.max_usage_in_bytes
-r--r--r-- 1 ルート ルート 0 9月 2日 14:57 memory.memsw.usage_in_bytes
-rw-r--r-- 1 ルート ルート 0 9月 2日 14:57 memory.move_charge_at_immigrate
-r--r--r-- 1 ルート ルート 0 9月 2日 14:57 memory.numa_stat
-rw-r--r-- 1 ルート ルート 0 9月 2日 14:57 memory.oom_control
---------- 1 ルート ルート 0 9月 2日 14:57 memory.pressure_level
-rw-r--r-- 1 ルート ルート 0 9月 2日 14:57 メモリ.soft_limit_in_bytes
-r--r--r-- 1 ルート ルート 0 9月 2日 14:57 memory.stat
-rw-r--r-- 1 ルート ルート 0 9月 2日 14:57 memory.swappiness
-r--r--r-- 1 root root 0 9月2日 14:57 メモリ使用量バイト
-rw-r--r-- 1 ルート ルート 0 9月 2日 14:57 memory.use_hierarchy
-rw-r--r-- 1 ルート ルート 0 9月 2日 14:57 通知オンリリース
-rw-r--r-- 1 ルート ルート 0 9月 2 14:57 タスク

Docker がコンテナ ID にちなんで名付けられたディレクトリを作成したことがわかります。ls コマンドを使用してディレクトリの内容を表示してみましょう。

$ sudo ls -l /sys/fs/cgroup/memory/docker/51041a74070e9260e82876974762b8c61c5ed0a51832d74fba6711175f89ede1
 
合計 0
-rw-r--r-- 1 ルート ルート 0 9月 2日 15:21 cgroup.clone_children
--w--w--w- 1 ルート ルート 0 9月 2 15:13 cgroup.event_control
-rw-r--r-- 1 ルート ルート 0 9月 2日 15:12 cgroup.procs
-rw-r--r-- 1 ルート ルート 0 9月 2日 15:12 メモリ.failcnt
--w------ 1 ルート ルート 0 9月 2 15:21 memory.force_empty
-rw-r--r-- 1 ルート ルート 0 9月 2日 15:21 memory.kmem.failcnt
-rw-r--r-- 1 ルート ルート 0 9月 2日 15:12 memory.kmem.limit_in_bytes
-rw-r--r-- 1 ルート ルート 0 9月 2日 15:21 memory.kmem.max_usage_in_bytes
-r--r--r-- 1 ルート ルート 0 9月 2日 15:21 memory.kmem.slabinfo
-rw-r--r-- 1 ルート ルート 0 9月 2日 15:21 memory.kmem.tcp.failcnt
-rw-r--r-- 1 ルート ルート 0 9月 2日 15:21 memory.kmem.tcp.limit_in_bytes
-rw-r--r-- 1 ルート ルート 0 9月 2日 15:21 memory.kmem.tcp.max_usage_in_bytes
-r--r--r-- 1 ルート ルート 0 9月 2日 15:21 memory.kmem.tcp.usage_in_bytes
-r--r--r-- 1 ルート ルート 0 9月 2日 15:21 memory.kmem.usage_in_bytes
-rw-r--r-- 1 ルート ルート 0 9月 2 15:12 メモリ制限バイト
-rw-r--r-- 1 ルート ルート 0 9月 2日 15:12 メモリ.max_usage_in_bytes
-rw-r--r-- 1 ルート ルート 0 9月 2日 15:21 memory.memsw.failcnt
-rw-r--r-- 1 ルート ルート 0 9月 2日 15:12 memory.memsw.limit_in_bytes
-rw-r--r-- 1 ルート ルート 0 9月 2日 15:21 memory.memsw.max_usage_in_bytes
-r--r--r-- 1 ルート ルート 0 9月 2日 15:21 memory.memsw.usage_in_bytes
-rw-r--r-- 1 ルート ルート 0 9月 2日 15:21 memory.move_charge_at_immigrate
-r--r--r-- 1 ルート ルート 0 9月 2日 15:21 memory.numa_stat
-rw-r--r-- 1 ルート ルート 0 9月 2 15:13 memory.oom_control
---------- 1 ルート ルート 0 9月 2日 15:21 memory.pressure_level
-rw-r--r-- 1 ルート ルート 0 9月 2 15:21 メモリ.soft_limit_in_bytes
-r--r--r-- 1 ルート ルート 0 9月 2日 15:21 memory.stat
-rw-r--r-- 1 ルート ルート 0 9月 2日 15:21 memory.swappiness
-r--r--r-- 1 root root 0 9月2日 15:12 メモリ使用量バイト
-rw-r--r-- 1 ルート ルート 0 9月 2 15:21 memory.use_hierarchy
-rw-r--r-- 1 ルート ルート 0 9月 2 15:21 通知オンリリース
-rw-r--r-- 1 ルート ルート 0 9月 2 15:21 タスク

上記のように、コンテナ ID のディレクトリには多くのファイルがあります。memory.limit_in_bytes ファイルは、コンテナのメモリ制限サイズをバイト単位で表します。ファイルの内容を表示するには、cat コマンドを使用します (cat コマンドはファイルの内容を表示できます)。

$ sudo cat /sys/fs/cgroup/memory/docker/51041a74070e9260e82876974762b8c61c5ed0a51832d74fba6711175f89ede1/memory.limit_in_bytes

2147483648

ここで、memory.limit_in_bytes の値が 2147483648 であることがわかります。これは変換後ちょうど 2G であり、コンテナを起動したときのメモリ制限 2G と一致しています。

メモリ サブシステムの例から、監視コンポーネントは、memory.limit_in_bytes ファイルを読み取ることでコンテナーのメモリ制限値を取得できることがわかります。コンテナのメモリ制限を理解した後、コンテナのメモリ使用量を見てみましょう。

$ sudo /sys/fs/cgroup/memory/docker/51041a74070e9260e82876974762b8c61c5ed0a51832d74fba6711175f89ede1/memory.usage_in_bytes

4259840

現在のメモリ使用量は 4259840 バイト、約 4 MB であることがわかります。メモリ監視について理解する。

次に、ネットワーク監視データのソースを見てみましょう。

ネットワーク監視データ ソースは /proc/{PID}/net/dev ディレクトリから読み取られます。ここで、PID はホスト上のコンテナのプロセス ID です。次に、まず docker inspect コマンドを使用して、上記で起動した nginx コンテナの PID を表示します。コマンドは次のとおりです。

$ docker nginx を検査 |grep Pid
 
   「Pid」: 27348,
 
   "PidMode": "",
 
   "PidsLimit": 0,

コンテナの PID が 27348 であることがわかります。cat コマンドを使用して、/proc/27348/net/dev の内容を表示します。

$ sudo cat /proc/27348/net/dev
インター|受信|送信
フェイス | バイト パケット エラー ドロップ FIFO フレーム 圧縮 マルチキャスト | バイト パケット エラー ドロップ FIFO コール キャリア 圧縮
 
 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 
 eth0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

/proc/27348/net/dev ファイルには、コンテナ内の各ネットワーク カードによって受信および送信されたトラフィックのほか、エラー数、パケット損失数などの情報が記録されます。ここからコンテナのネットワーク監視データが定期的に読み込まれ表示されていることがわかります。

要約すると、コンテナの監視原理は、実際には Linux ホスト上の関連ファイルを定期的に読み取り、ユーザーに表示することです。

結論

k8sはメトリクスサーバーを使用し、cAdvisorは基礎データを提供し、メトリクスサーバーの基盤データソースはcAdvisorです。

cAdvisor は監視データを提供し、Prometheus はデータの収集を担当します。これら 2 つの機能は異なります。実稼働クラスターでは、cAdvisor は通常、Prometheus と一緒に使用されます。

Dockerコンテナ監視の原理とcAdvisorのインストールと使用に関する上記の記事は、編集者が皆さんと共有する内容のすべてです。参考になれば幸いです。また、123WORDPRESS.COMを応援していただければ幸いです。