Dockerコンテナのメトリクスを監視する

SematextのDevOpsエバンジェリストであるStefan Thies氏が先日の記事で，コンテナの重要な10のメトリクスと，それらがDockerコンテナの運用において持つ意味について，ホスト毎に多数のコンテナを運用する場合を中心に論じている。単一の相関図に表現されたこれらのメトリクスは，Dockerベースの環境を監視するための出発点を提供してくれる。

コンテナの運用に関するこれらのメトリクスについて，著者は，コンテナの監視で問題となるVMとの挙動の違いを根拠として提案したものだ，と述べている – “従来の監視ソリューションは個々のサーバや，その上で稼働するアプリケーションからメトリクスを取得しています。このようなサーバや実行中のアプリケーションは一般的に，稼働時間の非常に長い，非常に静的な存在なのです。”

コンテナは対照的に，

• 一般に短命で，動的にスケジュール可能である。
• プロセスではあるが，独自の環境や仮想ネットワーク，独自のストレージ管理機構を保持している。
• 基盤となるホストのリソースを共有する。短命なバッチジョブと動作時間の長いプロセスが同一ホストにスケジュールされる場合もある。

氏が提案するメトリクスは，コンテナベースとホストベースのグループに大別される。

コンテナベースのメトリクス

共有リソースには緻密に計画されたコンテナ割り当てが必要であるため，コンテナリソースの使用状況の可視化が不可欠だ。調査によると，一般的には，ひとつのDockerホスト上に５つのコンテナが実行されている。さらにDocker SwarmやKubernetes，Mesosといったコンテナオーケストレーションソリューションでは，クラスタホスト上で多数のコンテナを効率的にスケジュールすることが可能であるため，コンテナの挙動の監視や調整が必要になる。

• コンテナCPU - スロットルCPU時間: コンテナのCPU使用率が制限された時間の合計を監視することにより，DockerのCPUシェアを適切に設定する上で必要な情報を取得することができる。カーネルがコンテナのCPU時間を制限するのは，ホストCPUが限界に達した場合に限られる。“このメトリックのスパイクは，ホストが提供するよりも多くのCPUパワーの必要なコンテナがひとつ以上存在することの明確な指標になります。”
• コンテナのメモリ使用量，コンテナのスワップ，コンテナのメモリフェール数: これら指標のスパイクは，割り当てられたよりも多くのメモリをコンテナが必要としていることを示唆する。氏は，アプリケーションがメモリを使い過ぎて，同一ホスト上の他のコンテナに影響しないように，コンテナのメモリを制限することを推奨する。ただし，例えばDockerの資料には，”メモリコントロールグループはホスト上のメモリ使用量をきめ細かく調整するため，それ自体が多少のオーバーヘッドを加える点には注意が必要”だ，と述べられている。
• コンテナのディスクI/O: 複数のコンテナが同時に，同じホストリソースを使用する可能性がある。これを監視することで，“データストアやWebサーバといった重要なアプリケーションに高いスループットを割り当てることが可能になります。”
• コンテナのネットワークメトリクス: コンテナライズド・ロードバランサのように相互接続されたコンテナでは，仮想ネットワークの監視が重要だ。パケットのドロップを追跡することは当然だが，“さらにネットワークトラフィックは，クライアントで使用されるアプリケーション数の指標としても重要です。高いスパイクが確認できたならば，それはサービス拒否攻撃やロードテスト，あるいはクライアントアプリのフェールを示しているかも知れません。”

ホストベースのメトリクス

コンテナに比べると，Dockerホストの寿命は長い。そのため，特に単一のホスト上で複数のロードを実行する場合には，容量管理やリソースの最適化が重要になる。

• ホストCPUとホストメモリ: ホストとコンテナのCPUとメモリの利用に関する理解は，Dockerホストのリソースを最適化する上で有用だ，と著者は述べている。“リソースの使用量を最適化する上でのCPU使用率の高さは，目標というより，もはや要件であると言えます。警告が意味を持つのは，CPU使用率が低下(サービス停止)した場合，あるいは長期にわたって特定の最大値(例えば85%)を超過した場合などに限られます。”
• ホストのディスク容量: コンテナやイメージ，ホストにマウントされたボリュームなどはすべてディスク容量を消費する，従ってディスク容量の監視と警告は不可欠だ，と氏は言う。定期的に使用しないコンテナやイメージを削除することは，ホストのディスクスペースをクリーンアップする上でよい習慣だ。
• ホスト上で実行されるコンテナの総数: 静的なユースケースでは，過去および現在のコンテナ数に関する情報が，アップデート時にすべて展開前と同じように動作していることを確認する上で役に立つ。一方で，Kubernetesのようなクラスタマネージャが，さまざまなロードをダイナミックにスケジュールするような動的なシナリオでは，この値が不規則に変化する可能性がある。従って，急激な変化を警告する異常検出の目的で使用するのがよいだろう，と氏は示唆している。

記事では，コンテナの動的な性質に対処可能な，新しいタイプの監視ツールの導入を勧めている。Sematextは監視とログ，イベントをひとつのビューに統一することで，これらの時間的な関連付けが可能な監視ソリューションを提供するツールだ。Docker Agentはコンテナ監視ソリューションを拡張し，コンテナの自動検出やDockerのイベント，ログ，メトリクスの収集といった機能などを可能にする。

その他のDockerコンテナ監視が可能なものとしては，例えばcAdvisorやsysdig，DataDogなどがある。これらツールのいくつかを比較した記事が，RancherやInfoWorldで発表されている。