１、はじめに
コンテナ技術が生産環境でますます使用されるにつれ、コンテナの監視とパフォーマンスのチューニングは現在、とても必要になっています。
コンテナ技術の生産環境の運用は、少数の大手IT企業によって最初に調査、実践、検証、チューニングされます。こちらの企業の業務システムは通常、次の特徴が存在しております。
■大規模な顧客訪問と大量データトラフィック
■大規模で複雑なハイブリットプラットフォーム（オンプレとクラウド）
■業務システムは高可用性、スケールアウトおよびスケールダウン能力あり
■プロ、ワールドクラスの運用保守チーム
■オープンソースコミュニティに積極的に参加し、同時に、改善策を提出でき、使用経験をコミュニティにフィードバックする
■最先端、成熟したテクノロジをいち早く吸収して、運用環境で使用することができる
そちらの企業の運用チームは豊富なコンテナ使用経験も持っています。これによって、コンテナの監視とチューニングの最善展開方法はやはり、大企業の使用経験とベストプラクティスを活用することです。さらに、自分のシステムの実際状況を組み合わせる必要があります。
２、コンテナの監視
コンテナの性能をチューニングするためには、ホストとコンテナの現在の様子を正しく把握し、必要な監視指標を入手する必要があります。現在、「Docker」は間違いなくコンテナー技術の業界標準になりました。なので、私たちも「Docker」を唯一のコンテナーエンジンにして使用します。調査作業も「Docker」所在環境を中心に展開したいと思います。
コンテナを監視する前に、まず、コンテナからどのようなパフォーマンスメトリクスを取得する必要なのかを知っておく必要があります。コンテナは仮想化技術の一種であり、仮想マシンに比べて、より小さくて細かい単位でハードウェアリソースを利用、より良い性能、安定性と隔離性が出せることは皆さんも知っています。なので、コンテナ監視も、ホストのように、CPU使用量、メモリ消費量、ディスクIO、ネットワークIOなど、リソース消費の角度から展開する。稼働中のコンテナのメトリクスを抽出して、監視する必要があります。さらに、コンテナ特有のライフサイクルとか、イメージ数なども収集される必要もあります。
上記のコンテナ監視の基本概念を理解したら、メトリクスを収集する方法について説明しましょう。正直言うと、個別コンテナデータの収集はとても簡単です。「Docker」自身も、コマンドラインツールを用意しています（例1）。もし、より詳細な情報を収集したいと、「Docker API」を「NS」コマンドと組み合わせて使用することもできます（例2）。さらに、メトリクスデータをイメージで表示したい場合は、ルーグル社の「CAdvisor」はとても良いツールです。（例3）。
例1：コマンド
$ docker stats termined_shockley judged_wozniak prickly_hypatia
prickly_hypatia
CONTAINER CPU % MEM USAGE/LIMIT MEM % NET I/O
determined_shockley 0.00% 884 KiB/1.961 GiB 0.04% 648 B/648 B
determined_wozniak 0.00% 1.723 MiB/1.961 GiB 0.09% 1.266 KiB/648 B
prickly_hypatia 0.00% 740 KiB/1.961 GiB 0.04% 1.898 KiB/648 B
例2：Docker API
$ echo -e "GET /containers/[CONTAINER_NAME]/stats HTTP/1.0\r\n" | nc -U /var/run/docker.sock
"cpu_stats": {
"cpu_usage": { "total_usage": 44651120376, "percpu_usage": [ 44651120376 ], "usage_in_kernelmode": 9660000000, "usage_in_usermode": 24510000000 },
"system_cpu_usage": 269321720000000,
"throttling_data": { "periods": 0, "throttled_periods": 0, "throttled_time": 0 }
}
例3：cadvisor
$ docker run \
--volume=/:/rootfs:ro \
--volume=/var/run:/var/run:rw \
--volume=/sys:/sys:ro \
--volume=/var/lib/docker/:/var/lib/docker:ro \
--publish=8080:8080 \
--detach=true \
--name=cadvisor \
google/cadvisor:latest
上記のツールはとても便利で使い易いが一定の制限があり、単一または単一のホストのメトリクスしか収集できません。クラウドプラットフォームまたは大規模クラスター環境に対して、より専門的な方法とソリューションが必要です。幸いなことは、コンテナ監視の分野ではすでに優れた解決策がいくつかあります。この中には、 「DataDog」、 「mackerel」、 「sysdig」などのホスティング、有料の「SAAS」があります。セルフホスティングのほうは 「Prometheus」、 「nagios」、 「Sensu」、 「Icinga」などのようなオープンソースもあります。また、オープンソースソリューションの一選択として、タイミングデータベースの「InfluxDB」と「cAdvisor」および「Grafana」を組み合わせて、独自の監視システムも構築することもできます。
３、コンテナ監視ソリューションの選択
以下では、ホスティングとセルフホスティングによって上記、列挙された方案を分類し、「Rancher」PAASプラットフォームの評価データに従って、それぞれの長所と短所を比較し、実際のニーズに応じて最適なソリューションを選択する。比較指標は下記のようになります。
・展開の難易度：
・詳細レベル：
・集計レベル：
・警報機能：
・コンテナ以外のリソースの監視：
・費用：
・操作とメンテナンスの圧力：
・パブリッククラウドサービスのサポート：
■ホスティング
①DataDog
https://www.datadoghq.com/customers/
・配置の難易度：*****
・詳細レベル：*****
・集計レベル：*****
・警報機能：*****
・非コンテナ資源モニタリング：サポート
・費用：$15/ホスト
・維持管理圧力：小
・パブリッククラウドサービスのサポート：サポート
②Mackerel
Https://mackerel.io/ja/blog/
・配置の難易度：*****
・詳細レベル：*****
・集計レベル：*****
・警報機能：*****
・非コンテナ資源モニタリング：サポート
・費用：¥1800/ホスト
・維持管理圧力：小
・パブリッククラウドサービスのサポート：サポート
③Sysdig
https://sysdig.com/opensource/
・配置の難易度：***
・詳細レベル：*****
・集計レベル：*****
・警報機能：****
・非コンテナ資源モニタリング：サポート
・費用：$20/ホスト
・維持管理圧力：小
・パブリッククラウドサービスのサポート：サポート
■セルフホスティング
①Prometheus
https://prometheus.io
・展開の難易度：**
・詳細レベル：*****
・集計レベル：*****
・警報機能：****
・非コンテナ資源モニタリング：サポート
・費用：オープンソースフリー
・維持管理圧力：大
・パブリッククラウドサービスのサポート：サポート
②Sensu
https://sensu.io
・配置の難易度：*
・詳細レベル：****
・集計レベル：****
・警報機能：****
・非コンテナ資源モニタリング：サポート
・費用：オープンソースフリー
・維持管理圧力：中
・パブリッククラウドサービスのサポート
③自作監視アーキテクチャ（cAdvisor + InfluxDB + Grafana）
・配置の難易度：*
・詳細レベル：*****
・集計レベル：*****
・警報機能：***
・非コンテナ資源モニタリング：サポート
・費用：オープンソースフリー
・維持管理圧力：大
・パブリッククラウドサービスのサポート：サポートされていません
なお、上記の調査資料はシステム基盤に対して、メトリクスの収集、監視、アラートなど幾つかの方法とツールを比較しました。これ以外、もっと重要なアプリーケーションの応用ログについて、まだ言及していません。個人的な考えはシステム基盤メトリクス，アプリーケーションの性能データ(APM)とは別に、専用のログ処理エンジン（例：ELK）を使った方がより良いと思います。何故なら、こちらのデータは企業な肝心財産で、単独に、長期蓄積、分析する価値があるからです。
結論、上記の各オプションの長所と短所を比較した後、チームの技術蓄積状況、および運用と保守の予算に基づいて決定することをお勧めします。総合的に考えて、下記の方案の組み合わせを推奨します。
・ホスティングのおすすめ：DataDog
・オープンソース推奨：Prometheus
・アプリーケーションの応用ログ：ELK
次回はインスタンスとコンテナーの性能チューニングについて話したいと思います。
５、参照資料
日本語
https://deeeet.com/writing/2014/05/11/docker-host-networking/
https://blog.stormcat.io/post/entry/docker-tcp-kernel/
英語
https://rancher.com/comparing-monitoring-options-for-docker-deployments/
https://rancher.com/comparing-10-container-monitoring-solutions-rancher/
https://www.datadoghq.com/blog/the-docker-monitoring-problem/
https://www.datadoghq.com/blog/how-to-monitor-docker-resource-metrics/
https://www.datadoghq.com/blog/how-to-collect-docker-metrics/
https://www.datadoghq.com/blog/iheartradio-monitors-docker/
中国語
https://blog.csdn.net/M2l0ZgSsVc7r69eFdTj/article/details/79546137
https://blog.51cto.com/ganbing/2083389
https://cloud.tencent.com/info/5b3bbaedbe00efe6c7dc1c35372ad5db.html