マシンエージェントを使用して、Docker コンテナ内で動作するアプリケーションノードをモニタし、アプリケーションのパフォーマンスに影響を与えるコンテナの問題を識別できます。APM メトリックを基本コンテナとサーバ/マシンのメトリックとともに表示および比較することにより、問題に簡単に答えることができます。アプリケーションの問題は単にアプリケーションの問題であるか、またはコンテナまたはサーバの根本原因であるかなど。 

コンテナモニタリングでは、コントローラテナントとマシンエージェントの両方について、サーバーの可視性ライセンス 4.3.3 以降が必要です。

Docker コンテナ内にマシンエージェントを導入する必要があります。マシンエージェントは、同じホスト上の Docker コンテナのメトリックと、ホスト自体のサーバとマシンのメトリックを収集します。コントローラテナントは、各ホストのすべてのモニター対象コンテナ、および各コンテナのコンテナ ID とホスト ID を表示します。 

ブリッジ ネットワーキング モードでは、コンテナはホスト名としてコンテナ ID を取得します。ネットワーキングがホストモードの場合、コンテナはホスト ID のノード名を取得します。これは、そのノード上のすべてのコンテナが同じホスト ID を持つことを意味します。この場合は、一意のホスト ID 設定を使用する必要があります。「ホスト ID としてコンテナ ID を登録する」を参照してください。Docker の可視性を使用する場合で、一意のホスト ID 設定がホストネットワークモードでコンテナ ID を使用するように構成されていない場合、マシンエージェントはコンテナ ID をホスト ID として使用してコンテナを自動的に登録します。古いバージョンのコントローラテナントまたはマシンエージェントがある場合、AppDynamics ではマシンエージェントのバージョン 20.7 以降にアップグレードすることを推奨しています。「Kubernetes での Docker の可視性の使用」を参照してください。

コントローラテナントが 20.11.0 以降の場合：

  • マシンエージェントが 20.7.0 以降の場合、マシンエージェントはコンテナ ID をホスト ID として使用してコンテナを自動的に登録します。これ以上の操作は必要ありません。
  • マシンエージェント 20.6.0 以前を誤って構成した場合、コントローラテナントは誤って構成されたコンテナ登録を拒否します。

デフォルトでは、マシンエージェントは APM エージェントを実行しているコンテナのみをモニタします。これを変更するには、コントローラテナントで sim.docker.monitorAPMContainersOnly プロパティを設定します。「サーバの可視性のコントローラ設定」を参照してください。

Docker コンテナの外部にあるホストにマシンエージェントを展開するには、ホスト上でシンボリックリンク ln -s / /hostroot を作成します。このシンボリックリンクにより、マシンエージェントは Docker コンテナメトリックとホストメトリックを収集できます。マシンエージェントがモニタリング用の Docker コンテナ内に展開されている場合、そのボリュームがマウントされると、シンボリックリンクが自動的に作成されます。より限定的な権限を付与するには、次のコマンドを入力してシンボリックリンク ln -s /proc /hostroot/proc; ln -s /sys /hostroot/sys; ln -s /etc /hostroot/etc を作成します。AppDynamics エージェントにはこれらのディレクトリに対する書き込み権限が必要ないため、これらのリンクは読み取り専用に指定することができます。

次の図は、コンテナモニタリングを展開する方法を示しています。

Container Monitoring

  • スタンドアロンコンテナでマシンエージェント をインストールします。マシンエージェントは、モニター対象の各コンテナのハードウェアメトリック、およびホスト のマシンとサーバーのメトリックを収集し、このメトリックをコントローラテナントに転送します。
  • マシンエージェントは、そのホスト上で実行されているすべてのコンテナをモニタして、確立された制限に従い、各コンテナのランタイムメトリックとメタデータを報告します。また、いずれかのコンテナに APM エージェントがインストールされている場合 、マシンエージェントはコンテナのメタデータとランタイムメトリックを関連する APM ノードとも相関させます。

ご使用になる前に

  1. AppDynamics では、Docker CE/EE 17.03 または Docker Engine 1.13 はこの製品とともに使用することをお勧めします。以前のバージョンの Docker を使用すると、一部のデータが失われる可能性があります。
  2. コンテナのモニタリングは、Windows または Mac の Docker ではサポートされていません。 
  3. AppDynamics では、コンテナベースのアプリケーションをモニタする場合は、「動的環境での JVM のインストゥルメント化」のガイドラインに従うことを強く推奨します。
  4. マシンエージェントは、ホストごとに最大 120 個の実行コンテナをモニタできます。ホストごとのデフォルトの最大数 100 です。cgroup enabled フラグを true に設定すると、マシンエージェントはホストごとに最大 600 個のコンテナをモニタできます。「Docker の可視性の設定」を参照してください。
  5. マシンエージェントは、コマンドラインが設定可能な正規表現と一致する 1 つ以上の実行中のプロセスでコンテナからメトリックを収集します。デフォルトでは、この正規表現はすべてのプロセス（*）に一致します。この動作を上書きするには、<machine_agent_home>/extensions/DockerMonitoring/conf/DockerMonitoring.yml:
    containerMonitoringConfig:containerProcessSelectorRegex: ".*" でこの正規表現を編集します。
  6. 1 つのコントローラテナントでモニターできるコンテナの最大数は、コントローラテナントのサイズ、アプリケーション エージェントの合計数、および現在の負荷によって異なります。
  7. 次を確認してください。
    1. アプリケーション エージェントおよびマシンエージェントを設定するためのベストプラクティス。
    2. 最新のRelease Notesでの Docker の可視性に関する問題。

コンテナモニタリングの有効化

コンテナモニタリングを有効にするには、次のようにします。

  1. コントローラテナントで、管理コンソールにログインし、sim.docker.enabled が true に設定されていることを確認します。 
  2. エージェントで、サーバの可視性と Docker の可視性を有効にします。

コンテナモニタリングの設定

コンテナモニタリングが有効なマシンエージェントを実行する最も迅速かつ簡単な方法は、Docker ストアのいずれかの正式なイメージ（https://hub.docker.com/u/appdynamics）を使用することです。これらのイメージは、Docker コミュニティからの認定ベースイメージに基づいて AppDynamics によって生成されます。これらのイメージは、直接実行するか、または独自のアプリケーションコンテナのベースイメージとして使用することができます。これらの正式なイメージに基づいてコンテナをダウンロードして実行する方法の詳細については、Docker ストアに掲載されているマニュアルを参照してください。基本イメージを作成する場合、これらのイメージを作成するための完全なソースコードが GitHub に掲載されています。これは独自のビルドのパターンとして使用できます。https://github.com/Appdynamics/appdynamics-docker-images。  

マシンエージェントがサーバ上で実行されているコンテナをモニタするには、次の設定を行います（「インストールオプションの設定」を参照）。

  • Server Visibility Enabled –サーバの可視性の有効化
  • Docker Enabled– Docker の可視性の有効化
  • Volume Mounts–次を指定します。
    • 基礎となるファイルシステム（/proc、/etc、および  /sys）への読み取り専用アクセスを許可するボリュームマウント。これにより、サーバエージェントはサーバ上で実行されているコンテナのホストレベルのメトリックを収集することができます。
    • Docker デーモンが API コールをリッスンするように設定されている UNIX ドメインソケット。 

コンテナの詳細の表示

コントローラテナントのコンテナのメタデータとメトリックを表示するには、次のようにします。

  • Applications ダッシュボードで、Containers に移動して、アプリケーションで使用されているすべてのモニタ対象コンテナを表示します。
    Applications Container Dashboard
  • [Servers ] ダッシュボードで、サーバーをダブルクリックして [Containers ] に移動し、そのホスト上のすべてのモニター対象コンテナを表示します。
    Servers Container Dashboard
  • コンテナダッシュボードを開くには、コンテナ名を右クリックし、[View Details] を選択します。
    Container Dashboard Detail View

[Container Details] ビューには次のタブがあり、コンテナの正常性とリソースの使用状況の概要が示されます。

    • Overview - コンテナメタデータ、タグ（Docker/Kubernetes から取得した名前と値のペア）、および該当する場合は AWS タグ、CPU、メモリ、ネットワーク、ディスク使用率に関する単一のチャートビュー
    • CPU- CPU 使用率およびスロットリング時間のメトリック
    • Memory- メモリ使用率とメモリの障害のメトリック
    • Network - ネットワーク使用率のメトリック（診断モードで実行されている場合にのみ使用可能）については、「マシンエージェントの設定プロパティ」の「動的モニタリングモード（DMM）の有効化」を参照してください。
  • また、ノードダッシュボードには、そのノードが実行されているコンテナのコンテナタブも含まれています。

メトリックブラウザを使用したコンテナメトリックの表示

コンテナの時系列メトリックデータを表示するには、コンテナメトリックグラフ（CPU、メモリ、ネットワーク、ディスク）のいずれかをダブルクリックして、選択したメトリックが表示されたメトリックブラウザを開きます。メトリックブラウザのツリーには、そのコンテナで使用可能なメトリックの完全なセットが表示されます。また、選択するメトリックをダブルクリックして、これらをメトリックブラウザの表示に追加することもできます。「コンテナのメトリック」を参照してください。

Metric Browser

動的モニタリングモードを使用したコンテナのトラブルシューティング

動的モニタリングモード（DMM）を使用して、個々のコンテナについて報告されたコンテナメトリックの数を選択的に制御できます。すべてのエージェントがすべてのコンテナのすべてのメトリックを常に報告するのではなく、個々のエージェントが収集するように設定できます。

  • 重要業績評価指標のみ（KPI モード）
  • KPI および診断メトリック（診断モード）
  • 使用可能なすべてのメトリック（詳細診断モード）

これにより、ほとんどのコンテナで KPI メトリックのみを報告し、問題を診断するためにより詳細な可視性を必要とする場合に特定のコンテナでメトリックレベルを増やすことができます。コントローラテナントのスケーラビリティを向上させ、可視性を犠牲にすることなく、ネットワークのメトリック帯域幅を節約できます。すべての Docker の可視性メトリックには、デフォルトの DMM クラス（KPI、診断、および高度な診断）があります。詳細については、コンテナメトリックテーブルを参照してください。[Default Monitoring Mode] 列は、動的モニタリングモードが有効になっている場合の各メトリックのデフォルトカテゴリを示しています。

追加の分析またはトラブルシューティングを必要とするコンテナに気付いたら、そのコンテナの DMM を変更して、より多くのメトリックを収集します。

  1. 対象のコンテナの [Container Detail] パネルを開きます。コンテナテーブル（[Containers]、左側のメニュー）を開き、コンテナをダブルクリックします。
  2. 右上隅の [Edit]（ペン）ボタンをクリックし、モードを [Diagnostic] または [Advanced Diagnostic] に変更し、チェックマークをクリックして変更を適用します。 
  3. 分析またはトラブルシューティングのための追加メトリックを収集します。
  4. そのコンテナの追加メトリックを収集する必要がなくなった場合は、 をクリックしてそのコンテナの DMM を KPI に戻します。

注：

  • エージェントによって収集されたメトリックのタイプに応じて、コントローラテナントには 3 つの異なる DMM デフォルト値があります。これらのデフォルトはすべて KPI（最も低い設定）に設定されています。
  • 両方の設定のデフォルトは KPI（最も低い設定）です。 
  • AppDynamics では、これらのグローバル設定をデフォルトのままにしておくことを推奨しています。特定のサーバまたはコンテナの高度なメトリックを収集する必要がある場合は、DMM を「必要に応じて」増やします。
  • Java アプリケーション エージェントでモニタされるコンテナがシャットダウンして再起動すると、シャットダウンコンテナで指定されたすべての上書き済み DMM が失われます。再起動したコンテナの DMM は、sim.machines.dmm.container.defaultMode によって指定されたグローバルデフォルトに自動的にリセットされます。 
  • コントローラテナントのモニタリングモードをより包括的なモードから包括的ではないモードに切り替えた場合、メトリックブラウザには、切り替えの 1 時間後に、新しく除外されたメトリックの値が表示されます。たとえば、診断モードから KPI モードに切り替えたとします。診断メトリックの場合、メトリックブラウザは、切り替えの 1 時間後に決まった行（0 または最後にレポートされた値）をレポートし、その後、その行は表示されなくなります。これは、特定のメトリックのレポートを停止した場合のエージェントのメトリックブラウザでの標準的な動作です。