次の方法で共有


Azure Monitor のコンテナー監視ソリューション

コンテナー シンボル

この記事では、Azure Monitor でコンテナー監視ソリューションを設定して使用する方法について説明します。これは、Docker と Windows のコンテナー ホストを 1 つの場所で表示および管理するのに役立ちます。 Docker は、IT インフラストラクチャへのソフトウェアのデプロイを自動化するコンテナーを作成するために使用されるソフトウェア仮想化システムです。

重要

コンテナー監視ソリューションは段階的に廃止されています。Kubernetes 環境を監視するには、 Azure Monitor Container Insights に移行することをお勧めします。

この記事は最近、Log Analytics ではなく Azure Monitor ログという用語を使うように更新されました。 ログ データは引き続き Log Analytics ワークスペースに格納され、同じ Log Analytics サービスによって収集されて分析されます。 Azure Monitor でのログの役割をより適切に反映するために、用語を更新しています。 詳細については、 Azure Monitor の用語の変更 に関するページを参照してください。

このソリューションでは、実行されているコンテナー、実行されているコンテナー イメージ、およびコンテナーが実行されている場所が示されます。 コンテナーで使用されるコマンドを示す詳細な監査情報を表示できます。 また、Docker または Windows ホストをリモートで表示しなくても、一元化されたログを表示して検索することで、コンテナーのトラブルシューティングを行うことができます。 ホスト上でノイズが多く、余分なリソースを消費している可能性があるコンテナーを見つけることができます。 また、一元化された CPU、メモリ、ストレージ、およびネットワークの使用状況とコンテナーのパフォーマンス情報を表示できます。 Windows を実行しているコンピューターでは、Windows Server、Hyper-V、Docker の各コンテナーのログを一元化して比較できます。 このソリューションでは、次のコンテナー オーケストレーターがサポートされています。

  • Docker Swarm
  • DC/OS
  • Service Fabric

Kubernetes と Red Hat OpenShift を監視するには、Azure Monitor Container Insights を使用することをお勧めします。

Azure Service Fabric にコンテナーをデプロイしている場合は、Service Fabric ソリューションとこのソリューションの両方を有効にして、クラスター イベントの監視を含することをお勧めします。 Service Fabric ソリューションを有効にする前に、「 Service Fabric ソリューションの使用 」を参照して、提供される内容とその使用方法を理解してください。

Azure Kubernetes Service (AKS) でホストされている Kubernetes 環境にデプロイされたワークロードのパフォーマンスの監視に関心がある場合は、「 Azure Kubernetes Service の監視」を参照してください。 コンテナー監視ソリューションでは、そのプラットフォームの監視はサポートされていません。

次の図は、さまざまなコンテナー ホストとエージェントと Azure Monitor との関係を示しています。

Azure Monitor とコンテナー ホストと、Azure クラウド、他のクラウド、ローカル ネットワーク上にあるエージェントの間の関係を示す図。

システム要件とサポートされているプラットフォーム

開始する前に、次の詳細を確認して、前提条件を満たしていることを確認します。

Docker Orchestrator と OS プラットフォームのコンテナー監視ソリューションのサポート

次の表は、Azure Monitor でのコンテナー インベントリ、パフォーマンス、ログの Docker オーケストレーションとオペレーティング システム監視のサポートの概要を示しています。

Docker オーケストレーション ACS (米国化学会) Linux ウィンドウズ コンテナ
在庫
画像
在庫
ノード
在庫
コンテナ
[パフォーマンス]
コンテナ
出来事
出来事
ログ
コンテナ
ログ
Kubernetes
中間圏
DC/OS
ドッカー
スウォーム
サービス
生地
Red Hat Open
シフト
Windows Server
(スタンドアロン)
Linuxサーバー
(スタンドアロン)

Linux でサポートされている Docker バージョン

  • Docker 1.11 から 1.13
  • Docker CE と EE v17.06

コンテナー ホストとしてサポートされている x64 Linux ディストリビューション

  • Ubuntu 14.04 LTS および 16.04 LTS
  • CoreOS(stable)
  • Amazon Linux 2016.09.0
  • openSUSE 13.2
  • openSUSE LEAP 42.2
  • CentOS 7.2 および 7.3
  • SLES 12
  • RHEL 7.2 および 7.3
  • Red Hat OpenShift Container Platform (OCP) 3.4 および 3.5
  • ACS Mesosphere DC/OS 1.7.3 から 1.8.8
  • ACS Kubernetes 1.4.5 から 1.6
    • Kubernetes イベント、Kubernetes インベントリ、およびコンテナー プロセスは、Linux 用 Log Analytics エージェントのバージョン 1.4.1 から 45 以降でのみサポートされます
  • ACS Docker Swarm

現在進行中の Microsoft Operations Management Suite から Azure Monitor への移行の一環として、Windows 用または Linux 用の Operations Management Suite エージェントは、Windows 用 Log Analytics エージェントおよび Linux 用 Log Analytics エージェントと呼ばれるようになります。

サポートされている Windows オペレーティング システム

  • Windows Server 2016
  • Windows 10 Anniversary Edition (Professional または Enterprise)

Windows でサポートされている Docker のバージョン

  • Docker 1.12 および 1.13
  • Docker 17.03.0 以降

ソリューションのインストールと構成

ソリューションをインストールして構成するには、次の情報を使用します。

  1. コンテナー監視ソリューションを Azure Marketplace から Log Analytics ワークスペースに追加するか、「 ソリューション ギャラリーからの監視ソリューションの追加」で説明されているプロセスを使用して追加します。

  2. Log Analytics エージェントで Docker をインストールして使用します。 オペレーティング システムと Docker オーケストレーターに基づいて、次の方法を使用してエージェントを構成できます。

    • スタンドアロン ホストの場合:
      • サポートされている Linux オペレーティング システムで、Docker をインストールして実行し、 Linux 用 Log Analytics エージェントをインストールして構成します。
      • CoreOS では、Linux 用 Log Analytics エージェントを実行できません。 代わりに、Linux 用 Log Analytics エージェントのコンテナー化されたバージョンを実行します。 Azure Government Cloud でコンテナーを使用している場合は、CoreOS を含む Linux コンテナー ホストまたは CoreOS を含む Azure Government Linux コンテナー ホストを確認します。
      • Windows Server 2016 および Windows 10 では、Docker エンジンとクライアントをインストールし、エージェントを接続して情報を収集し、Azure Monitor に送信します。 Windows 環境がある場合は、「 Windows コンテナー ホストのインストールと構成 」を参照してください。
    • Docker マルチホスト オーケストレーションの場合:

Windows を実行しているコンピューター に Docker エンジン をインストールして構成する方法の詳細については、Windows 上の Docker エンジンに関する記事を参照してください。

重要

コンテナー ホストに Linux 用 Log Analytics エージェントをインストールする前に、Docker が実行されている必要があります。 Docker をインストールする前にエージェントを既にインストールしている場合は、Linux 用 Log Analytics エージェントを再インストールする必要があります。 Docker の詳細については、 Docker Web サイトを参照してください。

Linux コンテナー ホストのインストールと構成

Docker をインストールしたら、コンテナー ホストに次の設定を使用して、Docker で使用するエージェントを構成します。 まず、Log Analytics ワークスペース ID とキーが必要です。これは Azure portal で確認できます。 ワークスペースで、[クイック スタート] >[Computers] をクリックして、ワークスペース ID主キーを表示します。 両方をコピーして、お気に入りのエディターに貼り付けます。

CoreOS を除くすべての Linux コンテナー ホストの場合:

CoreOS を含むすべての Linux コンテナー ホストの場合:

監視するコンテナーを起動します。 次の例を変更して使用します。

sudo docker run --privileged -d -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/docker/containers:/var/lib/docker/containers -e WSID="your workspace id" -e KEY="your key" -h=`hostname` -p 127.0.0.1:25225:25225 --name="omsagent" --restart=always mcr.microsoft.com/azuremonitor/containerinsights/ciprod:microsoft-oms-latest

CoreOS を含むすべての Azure Government Linux コンテナー ホストの場合:

監視するコンテナーを起動します。 次の例を変更して使用します。

sudo docker run --privileged -d -v /var/run/docker.sock:/var/run/docker.sock -v /var/log:/var/log -v /var/lib/docker/containers:/var/lib/docker/containers -e WSID="your workspace id" -e KEY="your key" -e DOMAIN="opinsights.azure.us" -p 127.0.0.1:25225:25225 -p 127.0.0.1:25224:25224/udp --name="omsagent" -h=`hostname` --restart=always mcr.microsoft.com/azuremonitor/containerinsights/ciprod:microsoft-oms-latest

インストールされている Linux エージェントの使用からコンテナー内のエージェントへの切り替え

以前に直接インストールされたエージェントを使用していて、代わりにコンテナーで実行されているエージェントを使用する場合は、まず Linux 用 Log Analytics エージェントを削除する必要があります。 エージェントを正常にアンインストールする方法については、 Linux 用 Log Analytics エージェント のアンインストールを参照してください。

Docker Swarm 用の Log Analytics エージェントを構成する

Log Analytics エージェントは、Docker Swarm でグローバル サービスとして実行できます。 Log Analytics エージェント サービスを作成するには、次の情報を使用します。 Log Analytics ワークスペース ID と主キーを指定する必要があります。

  • マスター ノードで次を実行します。

    sudo docker service create  --name omsagent --mode global  --mount type=bind,source=/var/run/docker.sock,destination=/var/run/docker.sock --mount type=bind,source=/var/lib/docker/containers,destination=/var/lib/docker/containers -e WSID="<WORKSPACE ID>" -e KEY="<PRIMARY KEY>" -p 25225:25225 -p 25224:25224/udp  --restart-condition=on-failure mcr.microsoft.com/azuremonitor/containerinsights/ciprod:microsoft-oms-latest
    
Docker Swarm のシークレットをセキュリティで保護する

Docker Swarm の場合、ワークスペース ID と主キーのシークレットが作成されたら、次の情報を使用してシークレット情報を作成します。

  1. マスター ノードで次を実行します。

    echo "WSID" | docker secret create WSID -
    echo "KEY" | docker secret create KEY -
    
  2. シークレットが正しく作成されたことを確認します。

    keiko@swarmm-master-13957614-0:/run# sudo docker secret ls
    
    ID                          NAME                CREATED             UPDATED
    j2fj153zxy91j8zbcitnjxjiv   WSID                43 minutes ago      43 minutes ago
    l9rh3n987g9c45zffuxdxetd9   KEY                 38 minutes ago      38 minutes ago
    
  3. 次のコマンドを実行して、コンテナー化された Log Analytics エージェントにシークレットをマウントします。

    sudo docker service create  --name omsagent --mode global  --mount type=bind,source=/var/run/docker.sock,destination=/var/run/docker.sock --mount type=bind,source=/var/lib/docker/containers,destination=/var/lib/docker/containers --secret source=WSID,target=WSID --secret source=KEY,target=KEY  -p 25225:25225 -p 25224:25224/udp --restart-condition=on-failure mcr.microsoft.com/azuremonitor/containerinsights/ciprod:microsoft-oms-latest
    

Red Hat OpenShift 用に Log Analytics エージェントを構成する

Log Analytics エージェントを Red Hat OpenShift に追加して、コンテナー監視データの収集を開始する方法は 3 つあります。

このセクションでは、Log Analytics エージェントを OpenShift デーモン セットとしてインストールするために必要な手順について説明します。

  1. OpenShift マスター ノードにサインオンし、GitHub からマスター ノードに yaml ファイル ocp-omsagent.yaml をコピーし、Log Analytics ワークスペース ID と主キーを使用して値を変更します。

  2. 次のコマンドを実行して、Azure Monitor 用のプロジェクトを作成し、ユーザー アカウントを設定します。

    oc adm new-project omslogging --node-selector='zone=default'
    oc project omslogging  
    oc create serviceaccount omsagent  
    oc adm policy add-cluster-role-to-user cluster-reader   system:serviceaccount:omslogging:omsagent  
    oc adm policy add-scc-to-user privileged system:serviceaccount:omslogging:omsagent  
    
  3. デーモン セットをデプロイするには、次のコマンドを実行します。

    oc create -f ocp-omsagent.yaml

  4. 構成され、正常に動作していることを確認するには、次のように入力します。

    oc describe daemonset omsagent

    出力は次のようになります。

    [ocpadmin@khm-0 ~]$ oc describe ds oms  
    Name:           oms  
    Image(s):       mcr.microsoft.com/azuremonitor/containerinsights/ciprod:microsoft-oms-latest  
    Selector:       name=omsagent  
    Node-Selector:  zone=default  
    Labels:         agentVersion=1.4.0-12  
                    dockerProviderVersion=10.0.0-25  
                    name=omsagent  
    Desired Number of Nodes Scheduled: 3  
    Current Number of Nodes Scheduled: 3  
    Number of Nodes Misscheduled: 0  
    Pods Status:    3 Running / 0 Waiting / 0 Succeeded / 0 Failed  
    No events.  
    

Log Analytics エージェント デーモンセット yaml ファイルを使用するときに、シークレットを使用して Log Analytics ワークスペース ID と主キーをセキュリティで保護する場合は、次の手順を実行します。

  1. OpenShift マスター ノードにサインオンし、GitHub から yaml ファイル ocp-ds-omsagent.yaml とシークレット生成スクリプト ocp-secretgen.sh コピーします。 このスクリプトでは、シークレット情報をセキュリティで保護するために、Log Analytics ワークスペース ID と主キー用のシークレット yaml ファイルが生成されます。

  2. 次のコマンドを実行して、Azure Monitor 用のプロジェクトを作成し、ユーザー アカウントを設定します。 シークレット生成スクリプトは、Log Analytics ワークスペース ID <WSID> と主キー <KEY> を要求し、完了すると ocp-secret.yaml ファイルが作成されます。

    oc adm new-project omslogging --node-selector='zone=default'  
    oc project omslogging  
    oc create serviceaccount omsagent  
    oc adm policy add-cluster-role-to-user cluster-reader   system:serviceaccount:omslogging:omsagent  
    oc adm policy add-scc-to-user privileged system:serviceaccount:omslogging:omsagent  
    
  3. 次のコマンドを実行して、シークレット ファイルをデプロイします。

    oc create -f ocp-secret.yaml

  4. 次を実行してデプロイを確認します。

    oc describe secret omsagent-secret

    出力は次のようになります。

    [ocpadmin@khocp-master-0 ~]$ oc describe secret omsagent-secret  
    Name:           omsagent-secret  
    Namespace:      omslogging  
    Labels:         <none>  
    Annotations:    <none>  
    Type:   Opaque  
    Data  
    ====  
    KEY:    89 bytes  
    WSID:   37 bytes  
    
  5. 次のコマンドを実行して、Log Analytics エージェントデーモンセット yaml ファイルをデプロイします。

    oc create -f ocp-ds-omsagent.yaml

  6. 次を実行してデプロイを確認します。

    oc describe ds oms

    出力は次のようになります。

    [ocpadmin@khocp-master-0 ~]$ oc describe ds oms  
    Name:           oms  
    Image(s):       mcr.microsoft.com/azuremonitor/containerinsights/ciprod:microsoft-oms-latest  
    Selector:       name=omsagent  
    Node-Selector:  zone=default  
    Labels:         agentVersion=1.4.0-12  
                    dockerProviderVersion=10.0.0-25  
                    name=omsagent  
    Desired Number of Nodes Scheduled: 3  
    Current Number of Nodes Scheduled: 3  
    Number of Nodes Misscheduled: 0  
    Pods Status:    3 Running / 0 Waiting / 0 Succeeded / 0 Failed  
    No events.  
    

Kubernetes 用の Log Analytics Linux エージェントを構成する

Kubernetes の場合、スクリプトを使用してワークスペース ID と主キーのシークレット yaml ファイルを生成し、Linux 用 Log Analytics エージェントをインストールします。 Log Analytics Docker Kubernetes GitHub ページには、シークレット情報の有無にかかわらず使用できるファイルがあります。

  • Linux DaemonSet 用の既定の Log Analytics エージェントにシークレット情報 (omsagent.yaml) がありません
  • Linux DaemonSet yaml ファイルの Log Analytics エージェントは、シークレット生成スクリプトと共にシークレット情報 (omsagent-ds-secrets.yaml) を使用して、シークレット yaml (omsagentsecret.yaml) ファイルを生成します。

omsagent DaemonSet は、シークレットの有無に関係なく作成できます。

シークレットのない既定の OMSagent DaemonSet yaml ファイル

  • 既定の Log Analytics エージェント DaemonSet yaml ファイルの場合は、 <WSID><KEY> を WSID と KEY に置き換えます。 ファイルをマスター ノードにコピーし、次のコマンドを実行します。

    sudo kubectl create -f omsagent.yaml
    

シークレットを含む既定の OMSagent DaemonSet yaml ファイル

  1. シークレット情報を使用して Log Analytics エージェント DaemonSet を使用するには、まずシークレットを作成します。

    1. スクリプトとシークレット テンプレート ファイルをコピーし、それらが同じディレクトリにあることを確認します。

      • シークレット生成スクリプト - secret-gen.sh
      • シークレット テンプレート - secret-template.yaml
    2. 次の例のように、スクリプトを実行します。 このスクリプトでは、Log Analytics ワークスペース ID と主キーの入力を求められます。入力すると、スクリプトによってシークレット yaml ファイルが作成され、実行できるようになります。

      #> sudo bash ./secret-gen.sh
      
    3. 次を実行してシークレット ポッドを作成します。

      sudo kubectl create -f omsagentsecret.yaml
      
    4. 確認するには、次を実行します。

      keiko@ubuntu16-13db:~# sudo kubectl get secrets
      

      出力は次のようになります。

      NAME                  TYPE                                  DATA      AGE
      default-token-gvl91   kubernetes.io/service-account-token   3         50d
      omsagent-secret       Opaque                                2         1d
      
      keiko@ubuntu16-13db:~# sudo kubectl describe secrets omsagent-secret
      

      出力は次のようになります。

      Name:           omsagent-secret
      Namespace:      default
      Labels:         <none>
      Annotations:    <none>
      
      Type:   Opaque
      
      Data
      ====
      WSID:   36 bytes
      KEY:    88 bytes
      
    5. を実行して omsagent デーモン セットを作成する sudo kubectl create -f omsagent-ds-secrets.yaml

  2. 次のような Log Analytics エージェント DaemonSet が実行されていることを確認します。

    keiko@ubuntu16-13db:~# sudo kubectl get ds omsagent
    
    NAME       DESIRED   CURRENT   NODE-SELECTOR   AGE
    omsagent   3         3         <none>          1h
    

Kubernetes の場合は、スクリプトを使用して、Linux 用 Log Analytics エージェントのワークスペース ID と主キー用のシークレット yaml ファイルを生成します。 次の例の情報を omsagent yaml ファイル と共に使用して、シークレット情報をセキュリティで保護します。

keiko@ubuntu16-13db:~# sudo kubectl describe secrets omsagent-secret
Name:           omsagent-secret
Namespace:      default
Labels:         <none>
Annotations:    <none>

Type:   Opaque

Data
====
WSID:   36 bytes
KEY:    88 bytes

Kubernetes 用の Log Analytics Windows エージェントを構成する

Windows Kubernetes の場合、スクリプトを使用してワークスペース ID と主キーのシークレット yaml ファイルを生成し、Log Analytics エージェントをインストールします。 Log Analytics Docker Kubernetes GitHub ページには、シークレット情報と共に使用できるファイルがあります。 マスター ノードとエージェント ノード用に Log Analytics エージェントを個別にインストールする必要があります。

  1. マスター ノードのシークレット情報を使用して Log Analytics エージェント DaemonSet を使用するには、最初にサインインしてシークレットを作成します。

    1. スクリプトとシークレット テンプレート ファイルをコピーし、それらが同じディレクトリにあることを確認します。

      • シークレット生成スクリプト - secret-gen.sh
      • シークレット テンプレート - secret-template.yaml
    2. 次の例のように、スクリプトを実行します。 このスクリプトでは、Log Analytics ワークスペース ID と主キーの入力を求められます。入力すると、スクリプトによってシークレット yaml ファイルが作成され、実行できるようになります。

      #> sudo bash ./secret-gen.sh
      
    3. を実行して omsagent デーモン セットを作成する kubectl create -f omsagentsecret.yaml

    4. 確認するには、次のコマンドを実行します。

      root@ubuntu16-13db:~# kubectl get secrets
      

      出力は次のようになります。

      NAME                  TYPE                                  DATA      AGE
      default-token-gvl91   kubernetes.io/service-account-token   3         50d
      omsagent-secret       Opaque                                2         1d
      root@ubuntu16-13db:~# kubectl describe secrets omsagent-secret
      Name:           omsagent-secret
      Namespace:      default
      Labels:         <none>
      Annotations:    <none>
      
      Type:   Opaque
      
      Data
      ====
      WSID:   36 bytes
      KEY:    88 bytes
      
    5. を実行して omsagent デーモン セットを作成する kubectl create -f ws-omsagent-de-secrets.yaml

  2. 次のような Log Analytics エージェント DaemonSet が実行されていることを確認します。

    root@ubuntu16-13db:~# kubectl get deployment omsagent
    NAME       DESIRED   CURRENT   NODE-SELECTOR   AGE
    omsagent   1         1         <none>          1h
    
  3. Windows を実行しているワーカー ノードにエージェントをインストールするには、「Windows コンテナー ホストのインストールと構成」セクションの手順に従います。

Helm を使用して Linux Kubernetes に Log Analytics エージェントをデプロイする

Helm を使用して Linux Kubernetes 環境に Log Analytics エージェントをデプロイするには、次の手順を実行します。

  1. を実行して omsagent デーモン セットを作成する helm install --name omsagent --set omsagent.secret.wsid=<WSID>,omsagent.secret.key=<KEY> stable/msoms

  2. 結果は次のようになります。

    NAME:   omsagent
    LAST DEPLOYED: Tue Sep 19 20:37:46 2017
    NAMESPACE: default
    STATUS: DEPLOYED
    
    RESOURCES:
    ==> v1/Secret
    NAME            TYPE    DATA  AGE
    omsagent-msoms  Opaque  3     3s
    
    ==> v1beta1/DaemonSet
    NAME            DESIRED  CURRENT  READY  UP-TO-DATE  AVAILABLE  NODE-SELECTOR  AGE
    omsagent-msoms  3        3        3      3           3          <none>         3s
    
  3. omsagent の状態を確認するには、 helm status "omsagent" を実行します。出力は次のようになります。

    keiko@k8s-master-3814F33-0:~$ helm status omsagent
    LAST DEPLOYED: Tue Sep 19 20:37:46 2017
    NAMESPACE: default
    STATUS: DEPLOYED
    
    RESOURCES:
    ==> v1/Secret
    NAME            TYPE    DATA  AGE
    omsagent-msoms  Opaque  3     17m
    
    ==> v1beta1/DaemonSet
    NAME            DESIRED  CURRENT  READY  UP-TO-DATE  AVAILABLE  NODE-SELECTOR  AGE
    omsagent-msoms  3        3        3      3           3          <none>         17m
    

    詳細については、 Container Solution Helm Chart を参照してください。

Windows コンテナー ホストのインストールと構成

セクションの情報を使用して、Windows コンテナー ホストをインストールして構成します。

Windows エージェントをインストールする前の準備

Windows を実行しているコンピューターにエージェントをインストールする前に、Docker サービスを構成する必要があります。 この構成により、Windows エージェントまたは Azure Monitor 仮想マシン拡張機能が Docker TCP ソケットを使用して、エージェントが Docker デーモンにリモートでアクセスし、監視用のデータをキャプチャできるようになります。

Docker サービスを構成するには

次の PowerShell コマンドを実行して、Windows Server の TCP パイプと名前付きパイプを有効にします。

Stop-Service docker
dockerd --unregister-service
dockerd --register-service -H npipe:// -H 0.0.0.0:2375  
Start-Service docker

Windows コンテナーで使用される Docker デーモン構成の詳細については、「Windows 上の Docker エンジン」を参照してください。

Windows エージェントをインストールする

Windows と Hyper-V コンテナーの監視を有効にするには、コンテナー ホストである Windows コンピューターに Microsoft Monitoring Agent (MMA) をインストールします。 オンプレミス環境で Windows を実行しているコンピューターについては、「 Windows コンピューターを Azure Monitor に接続する」を参照してください。 Azure で実行されている仮想マシンの場合は、 仮想マシン拡張機能を使用して Azure Monitor に接続します。

Service Fabric で実行されている Windows コンテナーを監視できます。 ただし、現在 Service Fabric では、Azure で実行されている仮想マシン、オンプレミス環境で Windows を実行しているコンピューター のみがサポートされています。

コンテナー監視ソリューションが Windows に対して正しく設定されていることを確認できます。 管理パックが正しくダウンロードされたかどうかを確認するには、ContainerManagement.xxx を探 します。 ファイルは、C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Management Packs フォルダーにある必要があります。

ソリューション コンポーネント

Azure portal から ソリューション ギャラリー に移動し、 コンテナー監視ソリューションを追加します。 Windows エージェントを使用している場合、このソリューションを追加すると、エージェントがインストールされた各コンピューターに次の管理パックがインストールされます。 管理パックの構成やメンテナンスは必要ありません。

  • C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\管理パックに<0>ContainerManagement.xxxがインストールされています。

コンテナー データ収集の詳細

コンテナー監視ソリューションは、有効にしたエージェントを使用して、コンテナー ホストとコンテナーからさまざまなパフォーマンス メトリックとログ データを収集します。

データは、次の種類のエージェントによって 3 分ごとに収集されます。

コンテナー レコード

次の表は、コンテナー監視ソリューションによって収集されたレコードの例と、ログ検索結果に表示されるデータ型を示しています。

データの種類 ログ検索のデータ型 田畑
ホストとコンテナーのパフォーマンス Perf Computer、ObjectName、CounterName (%Processor 時間、ディスク読み取り MB、ディスク書き込み MB、メモリ使用量 MB、ネットワーク受信バイト数、ネットワーク送信バイト数、プロセッサ使用時間 秒、ネットワーク)、CounterValue、TimeGenerated、CounterPath、SourceSystem
コンテナー インベントリ ContainerInventory タイム生成、コンピュータ、コンテナ名、コンテナホスト名、イメージ、イメージタグ、コンテナステート、終了コード、環境変数、コマンド、作成時間、開始時間、終了時間、ソースシステム、コンテナID、イメージID
コンテナー イメージ インベントリ ContainerImageInventory タイムジェネレーテッド、コンピュータ、イメージ、イメージタグ、イメージサイズ、バーチャルサイズ、ランニング、 ポーズ、ストップ、失敗、ソースシステム、イメージID、トータルコンテナ
コンテナー記録 ContainerLog TimeGenerated、Computer、image ID、container name、LogEntrySource、LogEntry、SourceSystem、ContainerID
コンテナー サービス ログ ContainerServiceLog TimeGenerated、Computer、TimeOfCommand、Image、Command、SourceSystem、ContainerID
コンテナー ノード インベントリ ContainerNodeInventory_CL TimeGenerated、Computer、ClassName_s、DockerVersion_s、OperatingSystem_s、Volume_s、Network_s、NodeRole_s、OrchestratorType_s、InstanceID_g、SourceSystem
Kubernetes インベントリ KubePodInventory_CL TimeGenerated、Computer、PodLabel_deployment_s、PodLabel_deploymentconfig_s、PodLabel_docker_registry_s、Name_s、Namespace_s、PodStatus_s、PodIp_s、PodUid_g、PodCreationTimeStamp_t、SourceSystem
コンテナープロセス ContainerProcess_CL TimeGenerated、Computer、Pod_s、Namespace_s、ClassName_s、InstanceID_s、Uid_s、PID_s、PPID_s、C_s、STIME_s、Tty_s、TIME_s、Cmd_s、Id_s、Name_s、SourceSystem
Kubernetes イベント KubeEvents_CL TimeGenerated、Computer、Name_s、ObjectKind_s、Namespace_s、Reason_s、Type_s、SourceComponent_s、SourceSystem、Message

PodLabel データ型に追加されるラベルは、独自のカスタム ラベルです。 表に示す追加の PodLabel ラベルは例です。 そのため、 PodLabel_deployment_sPodLabel_deploymentconfig_sPodLabel_docker_registry_s は環境のデータ セットで異なり、一般的には PodLabel_yourlabel_sに似ています。

コンテナーの監視

Azure portal でソリューションを有効にすると、[ コンテナー] タイルに、コンテナー ホストとホストで実行されているコンテナーに関する概要情報が表示されます。

コンテナーに関する概要情報を示す円グラフを含む [コンテナー] タイルを示すスクリーンショット。

このタイルには、環境内に存在するコンテナーの数と、コンテナーが失敗、実行、停止のどちらであるかの概要が表示されます。

コンテナー ダッシュボードの使用

[ コンテナー ] タイルをクリックします。 そこから、ビューは次の構成で構成されます。

  • コンテナー イベント - コンテナーの状態と、失敗したコンテナーを含むコンピューターが表示されます。
  • コンテナー ログ - 時間の経過と共に生成されたコンテナー ログ ファイルのグラフと、ログ ファイルの数が最も多いコンピューターの一覧が表示されます。
  • Kubernetes イベント - 時間の経過と同時に生成された Kubernetes イベントのグラフと、ポッドがイベントを生成した理由の一覧を示します。 このデータ セットは、Linux 環境でのみ使用されます。
  • Kubernetes 名前空間インベントリ - 名前空間とポッドの数と階層が表示されます。 このデータ セットは、Linux 環境でのみ使用されます。
  • コンテナー ノード インベントリ - コンテナー ノード /ホストで使用されるオーケストレーションの種類の数を示します。 コンピューター ノード/ホストもコンテナーの数で一覧表示されます。 このデータ セットは、Linux 環境でのみ使用されます。
  • コンテナー イメージ インベントリ - 使用されたコンテナー イメージの合計数とイメージの種類の数が表示されます。 画像の数も画像タグによって一覧表示されます。
  • コンテナーの状態 - コンテナーを実行しているコンテナー ノード/ホスト コンピューターの合計数を示します。 コンピューターは、実行中のホストの数によっても一覧表示されます。
  • コンテナー プロセス - 時間の経過と同時に実行されているコンテナー プロセスの折れ線グラフが表示されます。 コンテナーは、コンテナー内でコマンド/プロセスを実行することによっても一覧表示されます。 このデータ セットは、Linux 環境でのみ使用されます。
  • コンテナーの CPU パフォーマンス - コンピューター ノード/ホストの時間経過に伴う平均 CPU 使用率の折れ線グラフを示します。 また、平均 CPU 使用率に基づいてコンピューター ノード/ホストも一覧表示されます。
  • コンテナー のメモリ パフォーマンス - 時間の経過に伴うメモリ使用量の折れ線グラフが表示されます。 また、インスタンス名に基づいてコンピューターのメモリ使用率も一覧表示されます。
  • コンピューターのパフォーマンス - 時間の経過に伴う CPU パフォーマンスの割合、時間の経過に伴うメモリ使用量の割合、および時間の経過に伴う空きディスク領域のメガバイト単位の折れ線グラフが表示されます。 グラフ内の任意の線にカーソルを合わせると、詳細を表示できます。

ダッシュボードの各領域は、収集されたデータに対して実行される検索の視覚的表現です。

収集されたデータを表示するダッシュボードを示すスクリーンショット。

収集されたデータを表示するダッシュボードを示すスクリーンショット。コンテナーの状態、プロセス、パフォーマンス、イメージのインベントリが含まれます。

次に示すように、[ コンテナーの状態] 領域で、上部の領域をクリックします。

コンテナーの状態情報を示す円グラフを含むコンテナー ダッシュボードの [コンテナーの状態] 領域を示すスクリーンショット。

Log Analytics が開き、コンテナーの状態に関する情報が表示されます。

コンテナーの状態と検索結果のクエリを含む Log Analytics を示すスクリーンショット。

ここから、検索クエリを編集して、関心のある特定の情報を検索するように変更できます。 ログ クエリの詳細については、「 Azure Monitor のログ クエリ」を参照してください。

失敗したコンテナーを見つけることによるトラブルシューティング

Log Analytics は、0 以外の終了コードで終了した場合、コンテナーを 失敗 としてマークします。 失敗したコンテナー セクションで、環境内の不具合とエラーの概要を確認できます。

失敗したコンテナーを検索するには

  1. [ コンテナーの状態] 領域をクリックします。
    コンテナーの状態情報を示す円グラフを含むコンテナー ダッシュボードの [コンテナーの状態] 領域を示すスクリーンショット。
  2. Log Analytics が開き、次のようなコンテナーの状態が表示されます。
    コンテナーの状態と検索結果のクエリを含む Log Analytics を示すスクリーンショット。
  3. [失敗] 行を展開し、[+] をクリックして条件をクエリに追加します。 次に、クエリの [集計] 行をコメント アウトします。 コメント アウトする必要がある行を示すスクリーンショット。
  4. クエリを実行し、結果内の行を展開してイメージ ID を表示します。
    イメージ ID を表示する方法を示すスクリーンショット。
  5. ログ クエリに次のように入力します。 ContainerImageInventory | where ImageID == <ImageID> を選択すると、イメージのサイズや停止したイメージと失敗したイメージの数など、イメージに関する詳細が表示されます。
    コンテナー イメージのクエリとイメージに関する詳細を含む Log Analytics を示すスクリーンショット。

コンテナー データのログを照会する

特定のエラーのトラブルシューティングを行うときは、環境内で発生している場所を確認するのに役立ちます。 次のログの種類は、必要な情報を返すクエリを作成するのに役立ちます。

  • ContainerImageInventory – 画像別に整理された情報を検索し、画像 ID やサイズなどの画像情報を表示する場合に、この種類を使用します。
  • ContainerInventory – コンテナー の場所、名前、実行されているイメージに関する情報が必要な場合は、この種類を使用します。
  • ContainerLog – 特定のエラー ログ情報とエントリを検索する場合は、この種類を使用します。
  • ContainerNodeInventory_CL コンテナーが存在するホスト/ノードに関する情報が必要な場合は、この種類を使用します。 Docker のバージョン、オーケストレーションの種類、ストレージ、ネットワーク情報が提供されます。
  • ContainerProcess_CL この種類を使用すると、コンテナー内で実行されているプロセスをすばやく確認できます。
  • ContainerServiceLog – 開始、停止、削除、プル コマンドなど、Docker デーモンの監査証跡情報を検索する場合は、この種類を使用します。
  • KubeEvents_CL Kubernetes イベントを表示するには、この種類を使用します。
  • KubePodInventory_CL クラスター階層情報を理解する場合は、この種類を使用します。

コンテナー データのログを照会するには

  • 最近失敗したことがわかっているイメージを選択し、そのエラー ログを見つけます。 まず、 ContainerInventory 検索を使用して、そのイメージを実行しているコンテナー名を検索します。 たとえば、次を検索します。 ContainerInventory | where Image == "ubuntu" and ContainerState == "Failed"
    失敗した Ubuntu コンテナーの検索と検索結果を示すスクリーンショット。

    結果内の任意の行を展開して、そのコンテナーの詳細を表示します。

ログ クエリの例

多くの場合、1 つまたは 2 つの例で始まるクエリを作成し、環境に合わせて変更すると便利です。 出発点として、ソリューション ページの右端にある [サンプル クエリ ] 領域を試して、より高度なクエリを作成できます。

ログ クエリの例を含む [サンプル クエリ] 領域を示すスクリーンショット。

ログ クエリの保存

クエリの保存は、Azure Monitor の標準的な機能です。 それらを保存することで、将来の使用に役立つと思われるものがあります。

役に立つクエリを作成したら、[ログ検索] ページの上部にある [お気に入り ] をクリックして保存します。 その後、[ マイ ダッシュボード ] ページから簡単にアクセスできます。

ワークスペースからのソリューションの削除

コンテナー監視ソリューションを削除するには、Azure portalPowerShell、または Azure CLI のいずれかを使用してソリューションを削除する手順に従います。

次のステップ

ログにクエリを実行 して、詳細なコンテナー データ レコードを表示します。