Azure Monitor のコンテナー監視ソリューション
この記事では、Docker と Windows のコンテナー ホストを 1 か所で表示して管理できる、Azure Monitor のコンテナー監視ソリューションを設定して使用する方法について説明します。 Docker は、IT インフラストラクチャへのソフトウェアのデプロイを自動化するコンテナーを作成するために使用されるソフトウェア仮想化システムです。
重要
Container Monitoring ソリューションは段階的に廃止します。Kubernetes 環境のモニターには、Azure Monitor Container 分析情報への切り替えをお勧めします。
注意
この記事は最近、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 分析情報の使用をお勧めします。
- AKS (AKS で Container 分析情報を設定する)
- Red Hat OpenShift (Azure Arc を使用して Container 分析情報を設定する)
Azure Service Fabric にデプロイされたコンテナーがある場合は、Service Fabric ソリューションとこのソリューションの両方を有効にして、クラスターイベントの監視を含めることをお勧めします。 Service Fabric ソリューションを有効にする前に、Service Fabric ソリューションの使用に関する記事を確認して、提供される内容とその使用方法を理解してください。
Azure Kubernetes Service (AKS) でホストされている Kubernetes 環境にデプロイされているワークロードのパフォーマンスを監視する方法については、Azure Kubernetes サービスの監視に関するページを参照してください。 コンテナー監視ソリューションでは、そのプラットフォームの監視はサポートされていません。
次のダイアグラムは、Azure Monitor を使用するさまざまなコンテナー ホストとエージェント間の関係を示しています。
システム要件とサポートされているプラットフォーム
始める前に、次の詳細を確認し、前提条件が満たされていることを確認してください。
Docker Orchestrator と OS プラットフォームのコンテナー監視ソリューションのサポート
次の表は、Azure Monitor によるコンテナー インベントリ、パフォーマンス、およびログの Docker オーケストレーションとオペレーティング システムの監視サポートの概要を示しています。
Docker オーケストレーション | ACS | Linux | Windows | コンテナー インベントリ |
Image インベントリ |
Node インベントリ |
コンテナー パフォーマンス |
コンテナー Event |
Event ログ |
コンテナー ログ |
---|---|---|---|---|---|---|---|---|---|---|
Kubernetes | • | • | • | • | • | • | • | • | • | • |
Mesosphere DC/OS |
• | • | • | • | • | • | • | • | • | |
Docker Swarm |
• | • | • | • | • | • | • | • | • | |
サービス Fabric |
• | • | • | • | • | • | • | • | • | |
Red Hat Open Shift |
• | • | • | • | • | • | • | |||
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 インベントリ、およびコンテナー プロセスは、バージョン 1.4.1~45 以降の Log Analytics エージェント for Linux のみでサポートされています。
- ACS Docker Swarm
Note
現在進行中の 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 以降
ソリューションのインストールと構成
次の情報を使用して、ソリューションをインストールおよび構成します。
コンテナー監視ソリューションを Log Analytics ワークスペースに追加します。この場合、Azure Marketplace から追加するか、Solutions Gallery からの監視ソリューションの追加に関する記事で説明されている手順に従って追加してください。
Log Analytics エージェントを使って Docker をインストールし、使用します。 ご使用のオペレーティング システムと Docker Orchestrator に基づいて、次のメソッドを使用してエージェントを構成できます。
- スタンドアロン ホストの場合
- サポートされている Linux オペレーティング システムでは、Docker をインストールして実行し、Log Analytics エージェント for Linux をインストールして構成します。
- CoreOS で、Log Analytics エージェント for Linux を実行することはできません。 代わりに、コンテナー化されたバージョンの Log Analytics エージェント Linux を実行できます。 Azure Government Cloud のコンテナーで作業をしている場合は、CoreOS を含む Linux コンテナー ホストまたは CoreOS を含む Azure Government Linux コンテナー ホストに関するセクションを参照してください。
- Windows Server 2016 および Windows 10 では、Docker エンジンとクライアントをインストールした後、エージェントを接続して情報を収集し、Azure Monitor に送信します。 Windows 環境をご利用の場合は、「Windows コンテナー ホストをインストールして構成する」を確認します。
- Docker の複数ホストのオーケストレーションの場合
- Red Hat OpenShift 環境がある場合は、「Log Analytics エージェント for Red Hat OpenShift を構成する」を参照してください。
- Kubernetes クラスターで Azure Container Service を使用している場合:
- 「Log Analytics Linux エージェント for Kubernetes を構成する」をお読みください。
- 「Log Analytics Windows エージェント for Kubernetes を構成する」をお読みください。
- Helm を使用して Linux Kubernetes に Log Analytics エージェントをデプロイする方法に関するセクションを参照してください。
- Azure Container Service DC/OS クラスターがある場合、詳細については、Azure Monitor を使用した Azure Container Service DC/OS クラスターの監視に関するページを参照してください。
- Docker Swarm モード環境がある場合、詳細については、「Log Analytics エージェント for Docker Swarm を構成する」を参照してください。
- Service Fabric クラスターがある場合、詳細については、Azure Monitor を使用したコンテナーの監視に関するページを参照してください。
- スタンドアロン ホストの場合
Windows を実行しているコンピューターに Docker エンジンをインストールして構成する方法の詳細については、「Windows 上の Docker エンジン」をご覧ください。
重要
Docker は、コンテナー ホストに Log Analytics エージェント for Linux をインストールする前に起動しておく必要があります。 Docker をインストールした後で Log Analytics エージェント for Linux をインストールしている場合は、エージェントをインストールし直す必要があります。 Docker の詳細については、Docker の Web サイトを参照してください。
Linux コンテナー ホストをインストールして構成する
Docker をインストールした後で、コンテナー ホストの次の設定を使用して、Docker で使用するためにエージェントを構成します。 まず、Log Analytics のワークスペース ID とキーが必要です。これらは Azure Portal 上で見つけることができます。 ワークスペースで [クイック スタート]>[コンピューター] をクリックして、ワークスペース ID と主キーを表示します。 両方をコピーしてお使いのエディターに貼り付けます。
CoreOS を除くすべての Linux コンテナー ホスト
- Log Analytics エージェント for Linux のインストール方法に関する詳細と手順は、Log Analytics エージェントの概要に関する記事をご覧ください。
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 エージェントからコンテナー内のエージェントの使用への切り替え
直接インストールしたエージェントを過去に使用したことがあり、代わりにコンテナーで実行されているエージェントを使用したい場合は、まず Log Analytics エージェント for Linux を削除する必要があります。 Log Analytics エージェント for Linux を正しくアンインストール方法については、「Log Analytics エージェント for Linux のアンインストール」をご覧ください。
Log Analytics エージェント for Docker Swarm を構成する
Docker Swarm で、Log Analytics エージェントをグローバル サービスとして実行できます。 次の情報を参考に、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 と主キーのシークレットが作成されたら、次の情報を使用してシークレット情報を作成します。
マスター ノードで、次を実行します。
echo "WSID" | docker secret create WSID - echo "KEY" | docker secret create KEY -
シークレットが正しく作成されたことを確認します。
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
次のコマンドを実行して、コンテナー化された 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
Log Analytics エージェント for Red Hat OpenShift を構成する
Red Hat OpenShift に Log Analytics エージェントを追加してコンテナーの監視データの収集を開始するには、次の 3 通りの方法があります。
- OpenShift の各ノードに直接 Log Analytics エージェント for Linux をインストールする
- Azure 内に存在する OpenShift の各ノードで Log Analytics VM 拡張機能を有効にする
- Log Analytics エージェントを OpenShift デーモン セットとしてインストールする
このセクションでは、Log Analytics エージェントを OpenShift デーモン セットとしてインストールするために必要な手順を説明します。
OpenShift のマスター ノードにサインオンし、yaml ファイル ocp-omsagent.yaml を GitHub からマスター ノードにコピーして、値を Log Analytics のワークスペース ID と 主キーに変更します。
次のコマンドを実行して 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
デーモン セットをデプロイするには、次の手順を実行します。
oc create -f ocp-omsagent.yaml
構成と動作が正しいことを確認するには、次を入力します。
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 と主キーのセキュリティを保護するには、次の手順を実行します。
OpenShift のマスター ノードにサインオンして、yaml ファイル ocp-ds-omsagent.yaml とシークレットを生成するスクリプト ocp-secretgen.sh を GitHub からコピーします。 このスクリプトにより Log Analytics のワークスペース ID と主キーのシークレット yaml ファイルが生成され、秘密情報がセキュリティで保護されます。
次のコマンドを実行して 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
次のコマンドを実行して、シークレット ファイルをデプロイします。
oc create -f ocp-secret.yaml
次を実行して、デプロイを確認します。
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
次を実行して、Log Analytics エージェントのデーモン セットの yaml ファイルをデプロイします。
oc create -f ocp-ds-omsagent.yaml
次を実行して、デプロイを確認します。
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.
Log Analytics Linux エージェント for Kubernetes を構成する
Kubernetes に対しては、スクリプトを使用して、ワークスペース ID と主キーのシークレット yaml ファイルを生成して Log Analytics エージェント for Linux をインストールします。 Log Analytics Docker Kubernetes GitHub ページには、シークレット情報があるときと、シークレット情報がないときに利用できる両方のファイルがあります。
- 既定の Log Analytics エージェント for Linux DaemonSet には、シークレット情報 (omsagent.yaml) はありません。
- Log Analytics エージェント for Linux DaemonSet の yaml ファイルは、シークレット情報 (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 ファイル
シークレット情報を使用して Log Analytics エージェントのDaemonSet を使用するには、まずシークレットを作成します。
スクリプトとシークレット テンプレート ファイルをコピーし、それらが同じディレクトリにあることを確認します。
- シークレット生成スクリプト: secret-gen.sh
- シークレット テンプレート: secret-template.yaml
次の例のように、スクリプトを実行します。 このスクリプトでは、Log Analytics のワークスペース ID と主キーの入力を求められます。それらを入力すると、シークレット yaml ファイルが作成され、実行できるようになります。
#> sudo bash ./secret-gen.sh
次のコマンドを実行して、シークレット ポッドを作成します。
sudo kubectl create -f omsagentsecret.yaml
検証するには、次のコマンドを実行します。
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
sudo kubectl create -f omsagent-ds-secrets.yaml
を実行して、omsagent daemon-set を作成します。
次のように、Log Analytics エージェントの DaemonSet がすでに起動していることを確認します。
keiko@ubuntu16-13db:~# sudo kubectl get ds omsagent
NAME DESIRED CURRENT NODE-SELECTOR AGE omsagent 3 3 <none> 1h
Kubernetes の場合は、スクリプトを使用して、Log Analytics エージェント for Linux 用のワークスペース 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
Log Analytics Windows エージェント for Kubernetes を構成する
Windows Kubernetes の場合は、スクリプトを使用して、ワークスペース ID と主キー用のシークレット yaml ファイルを生成して Log Analytics エージェントをインストールします。 Log Analytics Docker Kubernetes GitHub ページには、シークレット情報があるときに利用できるファイルがあります。 Log Analytics エージェントは、マスター ノードとエージェント ノードごとにインストールする必要があります。
マスター ノードでシークレット情報を使用して Log Analytics エージェント DaemonSet を使用するには、まずサインインして、シークレットを作成します。
スクリプトとシークレット テンプレート ファイルをコピーし、それらが同じディレクトリにあることを確認します。
- シークレット生成スクリプト: secret-gen.sh
- シークレット テンプレート: secret-template.yaml
次の例のように、スクリプトを実行します。 このスクリプトでは、Log Analytics のワークスペース ID と主キーの入力を求められます。それらを入力すると、シークレット yaml ファイルが作成され、実行できるようになります。
#> sudo bash ./secret-gen.sh
kubectl create -f omsagentsecret.yaml
を実行して、omsagent daemon-set を作成します。確認するには、次のコマンドを実行します。
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
kubectl create -f ws-omsagent-de-secrets.yaml
を実行して、omsagent daemon-set を作成します。
次のように、Log Analytics エージェントの DaemonSet がすでに起動していることを確認します。
root@ubuntu16-13db:~# kubectl get deployment omsagent NAME DESIRED CURRENT NODE-SELECTOR AGE omsagent 1 1 <none> 1h
Windows を実行している worker ノードにエージェントをインストールするには、セクション「Windows コンテナー ホストをインストールして構成する」の手順に従います。
Helm を使用して Linux Kubernetes に Log Analytics エージェントをデプロイする
Helm を使用して Linux Kubernetes 環境内に Log Analytics エージェントをデプロイするには、次の手順を実行します。
helm install --name omsagent --set omsagent.secret.wsid=<WSID>,omsagent.secret.key=<KEY> stable/msoms
を実行して、omsagent daemon-set を作成します。結果は次のようになります。
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
helm status "omsagent"
を実行して 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
詳細については、コンテナー ソリューション Helm チャートに関するページを参照してください。
Windows コンテナー ホストをインストールして構成する
セクション内の情報を使用して、Windows コンテナー ホストをインストールして構成します。
Windows エージェントをインストールする前の準備
Windows を実行しているコンピューターにエージェントをインストールする前に、Docker サービスを構成する必要があります。 構成により、Windows エージェントまたは Azure Monitor 仮想マシン拡張機能は、エージェントが Docker デーモンにリモートでアクセスできるように Docker TCP ソケットを使用できるようになり、監視用のデータをキャプチャすることが可能になります。
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 ポータルから [ソリューション ギャラリー] に移動し、 [コンテナー監視ソリューション] を追加します。 Windows エージェントを使用している場合、このソリューションを追加するときに、各コンピューターにエージェントと共に次の管理パックがインストールされます。 この管理パックは構成や保守が不要です。
- ContainerManagement.xxx は、C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Management Packs にインストールされます。
コンテナーのデータ収集の詳細
コンテナー監視ソリューションでは、有効化されたエージェントを使用して、コンテナー ホストとコンテナーからさまざまなパフォーマンス メトリックとログ データを収集します。
データは、次のエージェントの種類によって 3 分ごとに収集されます。
コンテナー レコード
次の表に、コンテナー監視ソリューションによって収集されるレコードと、ログ検索結果に表示されるデータ型の例を示します。
データ型 | ログ検索のデータ型 | フィールド |
---|---|---|
ホストとコンテナーのパフォーマンス | Perf |
Computer、ObjectName、CounterName (%Processor Time、Disk Reads MB、Disk Writes MB、Memory Usage MB、Network Receive Bytes、Network Send Bytes、Processor Usage sec、Network)、CounterValue、TimeGenerated、CounterPath、SourceSystem |
コンテナー インベントリ | ContainerInventory |
TimeGenerated、Computer、container name、ContainerHostname、Image、ImageTag、ContainerState、ExitCode、EnvironmentVar、Command、CreatedTime、StartedTime、FinishedTime、SourceSystem、ContainerID、ImageID |
コンテナー イメージ インベントリ | ContainerImageInventory |
TimeGenerated、Computer、Image、ImageTag、ImageSize、VirtualSize、Running、Paused、Stopped、Failed、SourceSystem、ImageID、TotalContainer |
コンテナー ログ | 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_s
、PodLabel_deploymentconfig_s
、PodLabel_docker_registry_s
はご利用の環境のデータ セットによって異なり、一般的には PodLabel_yourlabel_s
に似ています。
コンテナーの監視
Azure portal でソリューションを有効化すると、コンテナー ホストと、ホストで実行されているコンテナーに関する概要情報が [コンテナー] タイルに表示されます。
このタイルには、環境内に存在するコンテナーの数と、それらのコンテナーの状態 (失敗、実行中、停止) の概要が示されます。
コンテナー ダッシュボードの使用
[コンテナー] タイルをクリックします。 ここに表示される情報は、次の項目で整理されます。
- コンテナー イベント - コンテナーの状態と、失敗したコンテナーがあるコンピューターを示します。
- コンテナー ログ - 生成されたコンテナー ログ ファイルの一定期間のグラフと、ログ ファイル数が最も多いコンピューターの一覧を示します。
- Kubernetes イベント - 生成された Kubernetes イベントの一定期間のグラフと、ポッドがイベントを生成した理由の一覧を示します。 このデータ セットは、Linux 環境でのみ使用します。
- Kubernetes 名前空間のインベントリ - 名前空間とポッドの数、およびそれらの階層を示します。 このデータ セットは、Linux 環境でのみ使用します。
- コンテナー ノードのインベントリ - コンテナー ノード/ホストで使用されるオーケストレーションの種類の数を示します。 コンピューター ノード/ホストも、コンテナーの数として一覧表示されます。 このデータ セットは、Linux 環境でのみ使用します。
- コンテナー イメージのインベントリ - 使用されるコンテナー イメージの総数と、イメージの種類の数を示します。 イメージの数も、イメージ タグで一覧表示されます。
- コンテナーの状態 - 実行中のコンテナーがあるコンテナー ノード/ホスト コンピューターの総数を示します。 コンピューターも、実行中のホストの数として一覧表示されます。
- コンテナー プロセス - 実行されているコンテナー プロセスの一定期間の折れ線グラフを示します。 コンテナーも、コンテナー内で実行中のコマンド/プロセスとして一覧表示されます。 このデータ セットは、Linux 環境でのみ使用します。
- コンテナー CPU のパフォーマンス - コンピューター ノード/ホストの平均 CPU 使用率の一定期間の折れ線グラフを示します。 平均 CPU 使用率に基づいてコンピューター ノード/ホストも一覧表示されます。
- コンテナー メモリのパフォーマンス - メモリ使用量の一定期間の折れ線グラフを示します。 インスタンス名に基づいてコンピューターのメモリ使用率も一覧表示されます。
- コンピューターのパフォーマンス - CPU パフォーマンスの一定期間のパーセント、メモリ使用量の一定期間のパーセント、一定期間の空きディスク領域のメガバイトについての折れ線グラフを示します。 グラフの線にマウス オーバーすると詳細を表示できます。
ダッシュボードの各エリアは、収集されたデータに対して実行された検索の結果を視覚的に表したものです。
[コンテナーの状態] エリアで、上部のエリアをクリックすると次のように表示されます。
Log Analytics が開き、コンテナーの状態に関する情報が表示されます。
ここで検索クエリを編集して、関心のある情報のみが見つかるように変更できます。 ログ クエリの詳細については、Azure Monitor でのログ クエリに関するページを参照してください。
失敗したコンテナーを特定してトラブルシューティングを行う
ゼロ以外の終了コードで終了したコンテナーは、Log Analytics によって [失敗] とマークされます。 [失敗したコンテナー] エリアで、環境におけるエラーと失敗の概要を確認できます。
失敗したコンテナーを特定するには
-
[コンテナーの状態] エリアをクリックします。
- Log Analytics が開き、次のようにコンテナーの状態が表示されます。
- Failed 行を展開し、[+] をクリックして、クエリにその条件を追加します。 その後、クエリで Summarize 行をコメント アウトします。
- クエリを実行し、結果内の行を展開して、イメージ ID を表示します。
- ログ クエリに以下を入力します。
ContainerImageInventory | where ImageID == <ImageID>
により、停止したイメージと失敗したイメージのサイズと数など、イメージに関する詳細が表示されます。
コンテナー データのログをクエリする
特定のエラーのトラブルシューティングを実行する際には、環境のどこでそのエラーが発生しているのかを確認すると役立つ場合があります。 次のログの種類は、目的の情報を返すクエリを作成するうえで役立ちます。
- ContainerImageInventory – この種類は、イメージ別に整理された情報を見つける場合や、イメージの ID やサイズなどのイメージ情報を確認する場合に使用します。
- ContainerInventory – この種類は、コンテナーの場所、コンテナーの名前、実行中のイメージに関する情報が必要な場合に使用します。
- ContainerLog – この種類は、特定のエラー ログの情報やエントリを見つける場合に使用します。
- ContainerNodeInventory_CL – コンテナーが置かれているホスト/ノードに関する情報が必要な場合に使用します。 これにより、Docker のバージョン、オーケストレーションの種類、ストレージ、ネットワーク情報を取得できます。
- ContainerProcess_CL – コンテナー内で実行中のプロセスをすぐに確認したいときに使用します。
- ContainerServiceLog – この種類は、開始、停止、削除、プルのコマンドなど、Docker デーモンの監査証跡情報を見つける場合に使用します。
- KubeEvents_CL – Kubernetes イベントを確認するときに使用します。
- KubePodInventory_CL – クラスター階層に関する情報を把握したいときに使用します。
コンテナー データのログをクエリするには
最近失敗したことがわかっているイメージを選択し、そのエラー ログを見つけます。 まず、ContainerInventory 検索で、そのイメージを実行しているコンテナー名を特定します。 たとえば、
ContainerInventory | where Image == "ubuntu" and ContainerState == "Failed"
を検索します。
結果内の任意の行を展開すると、そのコンテナーの詳細が表示されます。
ログ クエリの例
クエリの作成の際には、多くの場合、1 ~ 2 個の例で始め、その後環境に合わせて変更するとうまくいきます。 出発点として、ソリューション ページの右端にある [サンプル クエリ] 領域で実験を行うと、より高度なクエリを作成するのに役立ちます。
ログ クエリの保存
クエリの保存は、Azure Monitor の標準的な機能です。 クエリを保存しておけば、後で使えるように、便利なクエリを取っておくことができます。
作成したクエリが便利であることがわかったら、 [ログ検索] ページの上部にある [お気に入り] をクリックして保存してください。 後で [マイ ダッシュボード] ページで簡単にアクセスできます。
ワークスペースからのソリューションの削除
コンテナー監視ソリューションを削除するには、Azure portal、PowerShell、または Azure CLI のいずれかを使用して、ソリューションを削除する手順に従ってください
次のステップ
ログをクエリして、詳細なコンテナー データ レコードを確認します。