次の方法で共有

コンテナー分析情報のトラブルシューティング

  • [アーティクル]

コンテナー分析情報を使用して Azure Kubernetes Service の監視を構成すると、データ収集や状態のレポートを妨げる問題が発生する場合があります。 この記事では、お問い合わせの多い問題とトラブルシューティングの手順について説明します。

既知のエラー メッセージ

次の表は、Container Insights を使用するときに発生する可能性がある既知のエラーをまとめたものです。

エラー メッセージ アクション
エラー メッセージ "選択したフィルターのデータがありません" 新しく作成されたクラスターの監視データ フローが確立されるまでには、時間がかかる場合があります。 クラスターのデータが表示されるまで、少なくとも 10 ～ 15 分お待ちください。

それでもデータが表示されない場合は、Log Analytics ワークスペースが disableLocalAuth = true に対して構成されているかどうかを確認します。 はいの場合は、disableLocalAuth = false に更新してください。

az resource show --ids "/subscriptions/[Your subscription ID]/resourcegroups/[Your resource group]/providers/microsoft.operationalinsights/workspaces/[Your workspace name]"

az resource update --ids "/subscriptions/[Your subscription ID]/resourcegroups/[Your resource group]/providers/microsoft.operationalinsights/workspaces/[Your workspace name]" --api-version "2021-06-01" --set properties.features.disableLocalAuth=False
エラー メッセージ "データの取得中にエラーが発生しました" AKS クラスターが正常性とパフォーマンスの監視用に設定される間に、クラスターと Log Analytics ワークスペースの間に接続が確立されます。 Log Analytics ワークスペースは、クラスターのすべての監視データを格納するために使用されます。 Log Analytics ワークスペースが削除されると、このエラーが発生する可能性があります。 ワークスペースが削除されたかどうかを確認します。 その場合は、Container Insights を使用してクラスターの監視を再度有効にします。 その後、既存のワークスペースを指定するか、新しいワークスペースを作成します。 再度有効にするには、クラスターに対する監視を無効にしてから、Container insights を再び有効にします。
az aks cli を使用して Container Insights を追加した後 "データの取得中にエラーが発生しました" az aks cli を使用して監視を有効にすると、コンテナー分析情報が正しくデプロイされない可能性があります。 ソリューションがデプロイされているかどうかを確認します。 確認するには、Log Analytics ワークスペースに移動し、左側のウィンドウで [Legacy solutions] (レガシ ソリューション) を選択して、ソリューションが使用可能かどうかを確認します。 この問題を解決するには、ソリューションを再デプロイします。 「Container Insights を有効にする」の手順に従います。
エラー メッセージ "Missing Subscription registration" (サブスクリプション登録が見つかりません) "Missing Subscription registration for Microsoft.OperationsManagement"(Microsoft.OperationsManagement のサブスクリプション登録がありません) というエラーが表示される場合、ワークスペースが定義されているサブスクリプションでリソース プロバイダー Microsoft.OperationsManagement を登録することで解決できます。 手順については、「リソース プロバイダーの登録エラーの解決」を参照してください。
エラー メッセージ "The reply url specified in the request doesn't match the reply urls configured for the application: '<application ID>'." (要求で指定されている応答 URL が、アプリケーションに構成されている応答 URL と一致しません: '<アプリケーション ID>'。) ライブ ログを有効にすると、このエラー メッセージが表示されることがあります。 解決策については、コンテナー分析情報でのコンテナー データのリアルタイム表示に関する記事をご覧ください。

問題の診断に役立つように、トラブルシューティング スクリプトを提供しています。

オンボードまたは更新操作中の承認エラー

Container Insights を有効にするか、メトリックの収集をサポートするようにクラスターを更新すると、"オブジェクト ID <user's Identity> を持つクライアント<user's objectId>には、スコープに対してアクションMicrosoft.Authorization/roleAssignments/writeを実行するための承認がありません" というエラーが表示されることがあります。

オンボードまたは更新プロセス中に、クラスター リソースに対する [監視メトリック パブリッシャー] ロールの割り当ての付与が試行されます。 コンテナー分析情報を有効にするためのプロセス、またはメトリックの収集をサポートするための更新を開始するユーザーは、AKS クラスター リソースのスコープに対する Microsoft.Authorization/roleAssignments/write アクセス許可にアクセスできる必要があります。 このアクセス許可へのアクセスが付与されるのは、 [所有者] および [ユーザー アクセスの管理者] 組み込みロールのメンバーだけです。 セキュリティ ポリシーで詳細なレベルのアクセス許可を割り当てる必要がある場合は、「Azure カスタム ロール」を参照し、必要とするユーザーにアクセス許可を割り当てます。

[Azure portal: パブリッシャー ロールを 監視メトリック スコープに割り当てる] から、このロールを手動で付与することもできます。 詳細な手順については、「Azure portal を使用して Azure ロールを割り当てる」を参照してください。

コンテナー分析情報が有効になっているが情報がレポートされない

状態情報を表示できない場合、またはログ クエリから結果が返されない場合は、問題を診断します。

  1. 次のコマンドを実行してエージェントの状態を確認します。

    kubectl get ds ama-logs --namespace=kube-system

    ポッドの数は、クラスター上の Linux ノードの数と同じである必要があります。 出力は次の例のようになり、適切にデプロイされたことが示されます。

    User@aksuser:~$ kubectl get ds ama-logs --namespace=kube-system
NAME       DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR    AGE
ama-logs   2         2         2         2            2           <none>           1d

  2. Windows Server ノードがある場合は、次のコマンドを実行して、エージェントの状態を確認します。

    kubectl get ds ama-logs-windows --namespace=kube-system

    ポッドの数は、クラスター上の Windows ノードの数と同じである必要があります。 出力は次の例のようになり、適切にデプロイされたことが示されます。

    User@aksuser:~$ kubectl get ds ama-logs-windows --namespace=kube-system
NAME                   DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR    AGE
ama-logs-windows           2         2         2         2            2           <none>       1d

  3. 次のコマンドを使用してデプロイの状態を確認します。

    kubectl get deployment ama-logs-rs --namespace=kube-system

    出力は次の例のようになり、適切にデプロイされたことが示されます。

    User@aksuser:~$ kubectl get deployment ama-logs-rs --namespace=kube-system
NAME          READY   UP-TO-DATE   AVAILABLE   AGE
ama-logs-rs   1/1     1            1           24d

  4. kubectl get pods --namespace=kube-system コマンドを実行してポッドの状態を調べ、それが実行中であることを確認します。

    出力は、ama-logs の状態が Running になっている次の例のようになるはずです。

    User@aksuser:~$ kubectl get pods --namespace=kube-system
NAME                                READY     STATUS    RESTARTS   AGE
aks-ssh-139866255-5n7k5             1/1       Running   0          8d
azure-vote-back-4149398501-7skz0    1/1       Running   0          22d
azure-vote-front-3826909965-30n62   1/1       Running   0          22d
ama-logs-484hw                      1/1       Running   0          1d
ama-logs-fkq7g                      1/1       Running   0          1d
ama-logs-windows-6drwq              1/1       Running   0          1d

  5. ポッドが実行中の状態であっても、Log Analytics にデータがない場合、またはデータが送信されるのは 1 日の特定の時間帯のみである場合は、日次上限が満たされていることを示している可能性があります。 この制限が毎日満たされると、データは Log Analytics ワークスペースへの取り込みを停止し、リセット時にリセットされます。 詳細については、「Log Analytics の日次上限 」を参照してください。

  6. Terraform を使用して Containter insights が有効になっており、msi_auth_for_monitoring_enabled が true に設定されている場合は、ログ収集を有効にするために DCR リソースと DCRA リソースもデプロイされていることを確認します。 詳細な手順については、Container Insights の有効化に関する記事を参照してください。

Container Insights エージェント ReplicaSet ポッドは非 AKS クラスターではスケジュールされない

コンテナー分析情報エージェント ReplicaSet ポッドは、スケジュール用のワーカー (またはエージェント) ノードの次のノード セレクターと依存関係があります。

nodeSelector:
  beta.kubernetes.io/os: Linux
  kubernetes.io/role: agent

ワーカー ノードにノード ラベルが関連付けられていない場合、エージェント ReplicaSet Pods はスケジュールされません。 ラベルを添付する方法の手順については、「Kubernetes のラベル セレクターの割り当て」に関するページを参照してください。

パフォーマンス グラフに Azure 以外のクラスター上のノードとコンテナーの CPU またはメモリが表示されない

コンテナーの分析情報エージェント ポッドでは、ノード エージェントで cAdvisor エンドポイントを使用して、パフォーマンス メトリックを収集します。 ノードのコンテナー化されたエージェントが、クラスター内のすべてのノードで cAdvisor secure port: 10250 または cAdvisor unsecure port: 10255 を開いてパフォーマンス メトリックを収集できるように構成されていることを確認します。 詳細については、ハイブリッド Kubernetes クラスターの前提条件に関するページを参照してください。

AKS 以外のクラスターが Container Insights に表示されない

コンテナー分析情報で非 AKS クラスターを表示するには、この分析情報をサポートする Log Analytics ワークスペースと、コンテナーの分析情報ソリューション リソース ContainerInsights ("ワークスペース") で読み取りアクセスが必要です。

メトリックが収集されない

  1. 次の CLI コマンドを使用して、監視メトリック パブリッシャー ロールの割り当てが存在することを確認します。

    az role assignment list --assignee "SP/UserassignedMSI for Azure Monitor Agent" --scope "/subscriptions/<subid>/resourcegroups/<RG>/providers/Microsoft.ContainerService/managedClusters/<clustername>" --role "Monitoring Metrics Publisher"

    MSI を使用するクラスターの場合、ユーザーが割り当てた Azure Monitor Agent のクライアント ID は監視が有効/無効になるたびに変更されるため、ロール割り当ては現在の MSI クライアント ID に存在する必要があります。

  2. Microsoft Entra ポッド ID が有効になっていて MSI を使用しているクラスターの場合:

    • 次のコマンドを使用して、必要なラベル kubernetes.azure.com/managedby: aks が Azure Monitor Agent ポッドに存在していることを確認します。

      kubectl get pods --show-labels -n kube-system | grep ama-logs

    • ポッド ID が有効な場合に例外が有効になっていることを、https://github.com/Azure/aad-pod-identity#1-deploy-aad-pod-identity でサポートされている方法のいずれかを使用して確認します。

      次のコマンドを実行して確認します。

      kubectl get AzurePodIdentityException -A -o yaml

      次の例のような出力が表示されます。

      apiVersion: "aadpodidentity.k8s.io/v1"
kind: AzurePodIdentityException
metadata:
name: mic-exception
namespace: default
spec:
podLabels:
app: mic
component: mic
---
apiVersion: "aadpodidentity.k8s.io/v1"
kind: AzurePodIdentityException
metadata:
name: aks-addon-exception
namespace: kube-system
spec:
podLabels:
kubernetes.azure.com/managedby: aks

Azure Arc 対応 Kubernetes クラスターでの Azure Monitor コンテナー拡張機能のインストールが失敗する

"既に存在するリソースがマニフェストに含まれています" というエラーは、コンテナー分析情報エージェントのリソースが Azure Arc 対応 Kubernetes クラスターに既に存在していることを示しています。 このエラーは、Container Insights エージェントが既にインストールされていることを示します。 Azure Arc 経由で接続されている AKS クラスターの場合は、azuremonitor-containers Helm チャートまたは監視アドオンのいずれかを使用してインストールされます。

この問題の解決策は、Container Insights エージェントの既存のリソースが存在する場合にクリーンアップすることです。 その後、Azure Monitor コンテナー拡張機能を有効にします。

非 AKS クラスターの場合

  1. Azure Arc に接続されている K8s クラスターに対して次のコマンドを実行し、azmon-containers-release-1 の azmon-containers-release-1 helm チャートのリリースが存在するかどうかを確認します。

    helm list -A

  2. 前のコマンドの出力で azmon-containers-release-1 が存在することが示されている場合は、次の Helm チャート リリースを削除します。

    helm del azmon-containers-release-1

AKS クラスターの場合

  1. 次のコマンドを実行して Azure Monitor Agent アドオン プロファイルを検索し、AKS 監視アドオンが有効になっているかどうかを確認します。

    az  account set -s <clusterSubscriptionId>
az aks show -g <clusterResourceGroup> -n <clusterName>

  2. 出力に Log Analytics ワークスペース リソース ID が指定された Azure Monitor Agent アドオン プロファイル構成が含まれている場合、この情報は AKS 監視アドオンが有効であり、無効にする必要があることを示します。

    az aks disable-addons -a monitoring -g <clusterResourceGroup> -n <clusterName>

前の手順で Azure Monitor コンテナー拡張機能のインストールに関する問題が解決されなかった場合は、詳細な調査のために、Microsoft 宛にサポート チケットを作成して送信してください。

重複するアラートを受信する

コンテナー分析情報の推奨アラートを無効にせずに、Prometheus の警告ルールを有効にしている可能性があります。 Container insights の推奨アラートから Prometheus 推奨警告ルール (プレビュー) への移行に関する記事を参照してください。

次のような情報バナーが表示されます "Container Insights 機能へのアクセスを制限する適切なクラスターアクセス許可がありません。 適切なアクセス許可を取得するには、クラスター管理者に問い合わせてください"

Container Insights では、ユーザーが Log Analytics ワークスペースのアクセス許可に基づいて、Azure portal エクスペリエンスにアクセスすることが以前から許可されています。 現在ではクラスター レベルのアクセス許可をチェックして、Azure portal エクスペリエンスへのアクセスを提供するようになりました。 クラスター管理者がこのアクセス許可を割り当てることが必要な場合があります。

基本的な読み取り専用クラスター レベルのアクセスの場合は、次の種類のクラスターに 監視閲覧者 ロールを割り当てます。

  • Kubernetes ロールベースのアクセス制御 (RBAC) 承認が有効になっていない AKS
  • Microsoft Entra の SAML ベースのシングル サインオンを使って AKS が有効
  • Kubernetes RBAC 認証を使って AKS が有効
  • クラスタロールのバインディング clusterMonitoringUser で構成された AKS
  • Azure Arc 対応 Kubernetes クラスター

これらのロールをAKSに割り当てる方法の詳細については、ユーザーまたはグループにロールのアクセス許可 を、ロールの割り当ての詳細については、Azure Kubernetes Service (AKS) のアクセスオプションとIDオプション を参照してください。

ContainerLog テーブルのクエリを実行したとき、Image プロパティと Name プロパティの値が出力されません

エージェント バージョン ciprod12042019 以降では、ログ データの収集にかかるコストを最小限に抑えるため、既定では、これら 2 つのプロパティはすべてのログ行には出力されません。 これらのプロパティとその値を含めるようにテーブルをクエリする 2 つの方法があります。

方法 1

他のテーブルを結合して、これらのプロパティ値を結果に含めます。

ContainerID プロパティに基づき結合することで、ContainerInventory テーブルの Image プロパティと ImageTag プロパティがクエリに含まれるように変更します。 ContainerID プロパティに基づき結合することで、KubepodInventory テーブルの ContainerName フィールドの Name プロパティ (以前は ContainerLog テーブルに表示されていました) を含めることができます。 このオプションをお勧めします。

次の例は、結合を使用してこれらのフィールド値を取得する方法を説明するサンプルの詳細なクエリです。

//Let's say we're querying an hour's worth of logs
let startTime = ago(1h);
let endTime = now();
//Below gets the latest Image & ImageTag for every containerID, during the time window
let ContainerInv = ContainerInventory | where TimeGenerated >= startTime and TimeGenerated < endTime | summarize arg_max(TimeGenerated, *)  by ContainerID, Image, ImageTag | project-away TimeGenerated | project ContainerID1=ContainerID, Image1=Image ,ImageTag1=ImageTag;
//Below gets the latest Name for every containerID, during the time window
let KubePodInv  = KubePodInventory | where ContainerID != "" | where TimeGenerated >= startTime | where TimeGenerated < endTime | summarize arg_max(TimeGenerated, *)  by ContainerID2 = ContainerID, Name1=ContainerName | project ContainerID2 , Name1;
//Now join the above 2 to get a 'jointed table' that has name, image & imagetag. Outer left is safer in case there are no kubepod records or if they're latent
let ContainerData = ContainerInv | join kind=leftouter (KubePodInv) on $left.ContainerID1 == $right.ContainerID2;
//Now join ContainerLog table with the 'jointed table' above and project-away redundant fields/columns and rename columns that were rewritten
//Outer left is safer so you don't lose logs even if we can't find container metadata for loglines (due to latency, time skew between data types, etc.)
ContainerLog
| where TimeGenerated >= startTime and TimeGenerated < endTime
| join kind= leftouter (
  ContainerData
) on $left.ContainerID == $right.ContainerID2 | project-away ContainerID1, ContainerID2, Name, Image, ImageTag | project-rename Name = Name1, Image=Image1, ImageTag=ImageTag1

方法 2

すべてのコンテナー ログ行について、これらのプロパティの収集を再び有効にします。

クエリの変更を伴うために最初の方法が難しい場合は、これらのフィールドの収集を再び有効にできます。 データ収集の構成設定に関するページの説明に従い、エージェントの構成マップで log_collection_settings.enrich_container_logs 設定を有効にします。

Note

ノード数が 50 を超える大規模なクラスターでは、2 番目の方法はお勧めしません。 このエンリッチメントを実行するために、クラスター内のすべてのノードから API サーバー呼び出しが生成されます。 この方法を使用すると、収集されるすべてのログ行のデータ サイズも増加します。

オンボード後にクラスターをアップグレードできません

シナリオは次のとおりです。Azure Kubernetes Service クラスターに対して Container insights を有効にしました。 次に、クラスターがデータを送信していた Log Analytics ワークスペースを削除しました。 これにより、クラスターをアップグレードしようとしても、失敗します。 この問題に対処するには、監視を無効にし、その後、サブスクリプション内の別の有効なワークスペースを参照することで、その監視を再び有効にする必要があります。 クラスターのアップグレードをもう一度実行しようとすると、正常に処理され、完了するはずです。

Azure Stack HCI クラスター上でログを収集しない

クラスターを登録したか、HCI Insights を 2023 年 11 月より前に構成した場合、Arc for Servers Insights、VM Insights、コンテナーの分析情報、Defender for Cloud、Microsoft Sentinel など、HCI で Azure Monitor エージェントを使用する機能がログとイベント データを正しく収集していない可能性があります。 エージェントと HCI Insights を再構成する手順については、HCI の AMA エージェントを修正する方法に関するページを参照してください。

次のステップ

AKS クラスター ノードとポッドについて正常性メトリックを取得するための監視が有効になったので、これらの正常性メトリックを Azure portal で利用できます。 コンテナー分析情報を使用する方法については、Azure Kubernetes Service の正常性の表示に関するページをご覧ください。