この記事では、Container Insights を使用して Kubernetes クラスターを監視するときの一般的な問題とトラブルシューティングの手順について説明します。
重複するアラートが作成されている
コンテナー分析情報の推奨アラートを無効にせずに、Prometheus の警告ルールを有効にしている可能性があります。 Container insights の推奨アラートから Prometheus 推奨警告ルール (プレビュー) への移行に関する記事を参照してください。
クラスターのアクセス許可
クラスターに必要なアクセス許可がない場合は、エラー メッセージが表示されることがあります。 You do not have the right cluster permissions which will restrict your access to Container Insights features. Please reach out to your cluster admin to get the right permission.
Container Insights では以前、ユーザーは Log Analytics ワークスペースのアクセス許可に基づいて Azure portal エクスペリエンスにアクセスすることができました。 現在ではクラスター レベルのアクセス許可をチェックして、Azure portal エクスペリエンスへのアクセスを提供するようになりました。 クラスター管理者がこのアクセス許可を割り当てることが必要な場合があります。
基本的な読み取り専用クラスター レベルのアクセスの場合は、次の種類のクラスターに 監視閲覧者 ロールを割り当てます。
- Kubernetes ロールベースのアクセス制御 (RBAC) 承認が有効になっていない AKS
- Microsoft Entra の SAML ベースのシングルサインオンによって AKS が有効化されました
- Kubernetes RBAC 認証を使って AKS が有効
- AKS は clusterMonitoringUser というクラスターロールバインディングで構成されています
- Azure Arc 対応 Kubernetes クラスター
これらのロールをAKSに割り当てる方法の詳細については、ユーザーまたはグループにロールのアクセス許可 を、ロールの割り当ての詳細については、Azure Kubernetes Service (AKS) のアクセスオプションとIDオプション を参照してください。
オンボードと更新の問題
次のセクションでは、クラスターで Container Insights をオンボードまたは更新するときに発生する可能性がある問題について説明します。
サブスクリプション未登録
エラー Missing Subscription registrationが表示された場合は、リソース プロバイダー の Microsoft.OperationsManagement を Log Analytics ワークスペースのサブスクリプションに登録します。 「リソース プロバイダーの登録のエラーを解決する」を参照してください。
認証エラー
Container Insights を有効にしたり、クラスターを更新したりすると、次のようなエラーが表示されることがあります。 The client <user's identity> with object id <user's objectId> does not have authorization to perform action Microsoft.Authorization/roleAssignments/write over scope.
オンボードまたは更新プロセス中に、 監視メトリック パブリッシャー ロールをクラスター リソースに割り当てようとします。 プロセスを開始するユーザーは、AKS クラスター リソース スコープに対する Microsoft.Authorization/roleAssignments/write アクセス許可にアクセスできる必要があります。 このアクセス許可へのアクセスが付与されるのは、 [所有者] および [ユーザー アクセスの管理者] 組み込みロールのメンバーだけです。 セキュリティ ポリシーで詳細なレベルのアクセス許可を割り当てる必要がある場合は、「Azure カスタム ロール」を参照し、必要とするユーザーにアクセス許可を割り当てます。 Azure portal でパブリッシャーロールを 監視メトリックに割り当てるには、Azure portal を使用した Azure ロールの割り当てに関するガイダンスを使用してください。
クラスターをアップグレードできない
AKS クラスターのインストール後に Container Insights をアップグレードできない場合は、クラスターがデータを送信していた Log Analytics ワークスペースが削除されている可能性があります。 クラスターの監視を無効にし、別のワークスペースを使用して Container Insights を再度有効にします。
Azure Monitor コンテナー拡張機能のインストールが失敗する
エラー manifests contain a resource that already exists は、Container insights エージェントのリソースが Azure Arc 対応 Kubernetes クラスターに既に存在していることを示しています。これは、Container insights エージェントが既にインストールされていることを意味します。 Container insights エージェントの既存のリソースをクリーンアップし、Azure Monitor コンテナー拡張機能を有効にして、この問題を解決します。
AKS クラスター
次のコマンドを実行して Azure Monitor Agent アドオン プロファイルを検索し、AKS 監視アドオンが有効になっているかどうかを確認します。
az account set -s <clusterSubscriptionId>
az aks show -g <clusterResourceGroup> -n <clusterName>
出力に Log Analytics ワークスペース リソース ID を持つ Azure Monitor エージェント アドオン プロファイル構成が含まれている場合、AKS 監視アドオンは有効になり、次のコマンドで無効にする必要があります。
az aks disable-addons -a monitoring -g <clusterResourceGroup> -n <clusterName>
AKS 以外のクラスター
クラスターに対して次のコマンドを実行して、 azmon-containers-release-1 Helm チャートリリースが存在するかどうかを確認します。
helm list -A
出力に azmon-containers-release-1 が存在することを示す場合は、次のコマンドを使用して Helm チャートリリースを削除します。
helm del azmon-containers-release-1
欠落しているデータ
クラスターで Container Insights を有効にした後、データが表示されるまでに最大 15 分かかる場合があります。 15 分経ってもデータが表示されない場合は、潜在的な問題と解決策については、次のセクションを参照してください。
データの取得中のエラー メッセージ
クラスターがデータを送信していた Log Analytics ワークスペースが削除された場合、エラー メッセージ Error retrieving data が発生する可能性があります。 その場合は、クラスターの監視を 無効に し、別のワークスペースを使用して Container Insights を再度 有効にします 。
ローカル認証が無効になっている
次の CLI コマンドを使用して、Log Analytics ワークスペースがローカル認証用に構成されているかどうかを確認します。
az resource show --ids "/subscriptions/[Your subscription ID]/resourcegroups/[Your resource group]/providers/microsoft.operationalinsights/workspaces/[Your workspace name]"disableLocalAuth = true場合は、次のコマンドを実行します。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 |
日次上限が満たされました
Log Analytics ワークスペースの日次上限に達すると、リセット時刻までデータの収集が停止されます。 Log Analytics の日次上限を参照してください。
Terraform で DCR がデプロイされていない
Terraform を使用して Container insights が有効になっており、 msi_auth_for_monitoring_enabled が true に設定されている場合は、ログ収集を有効にするために DCR リソースと DCRA リソースもデプロイされていることを確認します。 コンテナーの分析情報を有効にするを参照してください。
コンテナーの分析情報で情報がまったく報告されていない
状態情報を表示できない場合、またはログ クエリから結果が返されない場合は、次の手順を使用します。
次のコマンドを使用して、エージェントの状態を確認します。
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> 1dWindows 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次のコマンドを使用してデプロイの状態を確認します。
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 24dkubectl 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ポッドが実行中の状態であっても、Log Analytics にデータがない場合、またはデータが送信されるのは 1 日の特定の時間帯のみである場合は、日次上限が満たされていることを示している可能性があります。 この制限が毎日満たされると、データは Log Analytics ワークスペースへの取り込みを停止し、リセット時にリセットされます。 詳細については、「Log Analytics の日次上限 」を参照してください。
メトリックが収集されない
次の 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 に存在する必要があります。
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 以外のクラスター上のノードとコンテナーの CPU またはメモリが表示されない
Container insights エージェント ポッドは、ノード エージェントの cAdvisor エンドポイントを使用してパフォーマンス メトリックを収集します。 ノードのコンテナー化されたエージェントが、クラスター内のすべてのノードで cAdvisor secure port: 10250 または cAdvisor unsecure port: 10255 を開いてパフォーマンス メトリックを収集できるように構成されていることを確認します。 ハイブリッド Kubernetes クラスターの前提条件を参照してください。
ContainerLog テーブルにイメージと名前の値が設定されていない
エージェント バージョン ciprod12042019 以降では、収集されたログ データに対するコストを最小限に抑えるために、ログ行ごとにこれらの 2 つのプロパティが既定で設定されるわけではありません。 これらのプロパティのコレクションを有効にするか、クエリを変更して他のテーブルからこれらのプロパティを含めることができます。
Image プロパティに基づき結合することで、ImageTag テーブルの ContainerInventory プロパティと ContainerID プロパティがクエリに含まれるように変更します。 Name プロパティに基づき結合することで、ContainerLog テーブルの KubepodInventory フィールドの ContainerName プロパティ (以前は ContainerID テーブルに表示されていました) を含めることができます。
次のサンプル クエリは、結合を使用してこれらの値を取得する方法を示しています。
//Set the time window for the query
let startTime = ago(1h);
let endTime = now();
//
//Get the latest Image & ImageTag for every containerID
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;
//
//Get the latest Name for every containerID
let KubePodInv = KubePodInventory | where ContainerID != "" | where TimeGenerated >= startTime | where TimeGenerated < endTime | summarize arg_max(TimeGenerated, *) by ContainerID2 = ContainerID, Name1=ContainerName | project ContainerID2 , Name1;
//
//Join the above to get a jointed table that has name, image & imagetag. Outer left is used in case there are no kubepod records or if they're latent
let ContainerData = ContainerInv | join kind=leftouter (KubePodInv) on $left.ContainerID1 == $right.ContainerID2;
//
//Join ContainerLog table with the jointed table above, project-away redundant fields/columns, and rename columns that were rewritten. Outer left is used so logs aren't lost even if no container metadata for loglines is found.
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
警告
ノード数が 50 を超える大規模なクラスターでは、プロパティを有効にすることはお勧めしません。 クラスター内のすべてのノードから API サーバー呼び出しが生成され、収集されるすべてのログ行のデータ サイズも増加します。
これらのフィールドの収集を有効にしてクエリを変更する必要がないようにするには、log_collection_settings.enrich_container_logs構成設定の説明に従って、エージェント構成マップで設定を有効にします。
Azure ローカル クラスターでログが収集されない
2023 年 11 月より前にクラスターを登録したり、Azure Local 用に Insights を構成したりした場合、Arc for Servers Insights、VM Insights、Container Insights、Defender for Cloud、Microsoft Sentinel など、Azure Local で Azure Monitor エージェントを使用する機能がログとイベント データを正しく収集していない可能性があります。 Azure Local のエージェントと Insights を再構成する手順については、「Azure Local の AMA エージェントを修復する」を参照してください。
大規模なクラスターにデータが見つからない
次の表のいずれかにデータがない場合、ポッドまたはノードの数が多いため、大きなペイロードの解析に関連している可能性があります。 これは、既定のPODS_CHUNK_SIZE (1000) のため、大きな JSON ペイロードを解析する Ruby プラグインの既知の問題です。
この問題に対処するために、既定のPODS_CHUNK_SIZE値をより小さい値に調整する計画があります。
- KubePodInventory (キューブポッドインベントリー)
- KubeNodeInventory
- KubeEvents
- クベPVインベントリー
- KubeServices
次のコマンドを使用して、クラスターで小さい
PODS_CHUNK_SIZE値を構成したかどうかを確認します。# verify if kube context being set for right cluster kubectl cluster-info # check if the configmap configured with smaller PODS_CHUNK_SIZE chunksize already kubectl logs <ama-logs-rs pod name> -n kube-system -c ama-logs | grep PODS_CHUNK_SIZE # If it's configured, the output will be similar to "Using config map value: PODS_CHUNK_SIZE = 10"クラスターがより小さい
PODS_CHUNK_SIZE値に対して既に構成されている場合は、大規模なクラスターに対してクラスターを有効にする必要があります。クラスターが既定の
PODS_CHUNK_SIZE=1000を使用している場合は、クラスターに多数のポッドまたはノードがあるかどうかを確認します。# check the total number of PODS kubectl get pods -A -o wide | wc -l # check the total number of NODES kubectl get nodes -o wide | wc -lポッドとノードの数が十分に多く、クラスターで既定の
PODS_CHUNK_SIZE=1000が使用されていることを確認した後、次のコマンドを使用して configmap を構成します。# Check if the cluster has container-azm-ms-agentconfig configmap in kube-system namespace kubectl get cm -n kube-system | grep container-azm-ms-agentconfig # If there is no existing container-azm-ms-agentconfig configmap, then configmap needs to be downloaded and applied curl -L https://raw.githubusercontent.com/microsoft/Docker-Provider/refs/heads/ci_prod/kubernetes/container-azm-ms-agentconfig.yaml -o container-azm-ms-agentconfig kubectl apply -f container-azm-ms-agentconfig # Edit the configmap and uncomment agent_settings.chunk_config and PODS_CHUNK_SIZE lines under agent-settings: |- in the configmap kubectl edit cm -n kube-system container-azm-ms-agentconfig -o yaml
エージェント OOM が強制終了される
デーモンセット コンテナーの OOM が強制終了される
まず、次のコマンドを使用して、OOM が強制終了されるコンテナーを特定します。 これにより、
ama-logs、ama-logs-prometheus、またはその両方が識別されます。# verify if kube context being set for right cluster kubectl cluster-info # get the ama-logs pods and status kubectl get pods -n kube-system -o custom-columns=NAME:.metadata.name | grep -E ama-logs-[a-z0-9]{5} # from the result of above command, find out which ama-logs pod instance getting OOM killed kubectl describe pod <ama-logs-pod> -n kube-system # review the output of the above command to findout which ama-logs container is getting OOM killed次のコマンドを使用して、
mdsd.errログ ファイルにネットワーク エラーがあるかどうかを確認します。mkdir log # for ama-logs-prometheus container use -c ama-logs-prometheus instead of -c ama-logs kubectl cp -c ama-logs kube-system/<ama-logs pod name>:/var/opt/microsoft/linuxmonagent/log log cd log cat mdsd.err送信エンドポイントがブロックされていることが原因でエラーが発生した場合は、 Kubernetes クラスターのエンドポイント要件を監視するためのネットワーク ファイアウォール 要件に関する説明を参照してください。
データ収集エンドポイント (DCE) またはデータ収集規則 (DCR) が不足しているためにエラーが発生した場合は、「 Kubernetes クラスターの監視を有効にする」のガイダンスを使用して、Container Insights を再度有効にします。
エラーがない場合は、ログスケールに関連している可能性があります。 Container Insights (プレビュー) での高スケール ログの収集に関する説明を参照してください。
レプリカセット コンテナーの OOM が強制終了される
次のコマンドを使用して、ポッド
ama-logs-rsOOM が強制終了される頻度を特定します。# verify if kube context being set for right cluster kubectl cluster-info # get the ama-logs pods and status kubectl get pods -n kube-system -o wide | grep ama-logs-rs # from the result of above command, find out which ama-logs pod instance getting OOM killed kubectl describe pod <ama-logs-rs-pod> -n kube-system # review the output of the above command to confirm the OOM killama-logs-rs が OOM を強制終了した場合は、次のコマンドを使用してネットワーク エラーがあるかどうかを確認します。
mkdir log kubectl cp -c ama-logs kube-system/<ama-logs-rs pod name>:/var/opt/microsoft/linuxmonagent/log log cd log cat mdsd.err送信エンドポイントがブロックされていることが原因でエラーが発生した場合は、 Kubernetes クラスターのエンドポイント要件を監視するためのネットワーク ファイアウォール 要件に関する説明を参照してください。
データ収集エンドポイント (DCE) またはデータ収集規則 (DCR) が不足しているためにエラーが発生した場合は、「 Kubernetes クラスターの監視を有効にする」のガイダンスを使用して、Container Insights を再度有効にします。
ネットワーク エラーがない場合は、configmap の [prometheus_data_collection_settings.cluster] 設定を確認して、クラスター レベルの prometheus スクレイピングが有効になっているかどうかを確認します。
# Check if the cluster has container-azm-ms-agentconfig configmap in kube-system namespace kubectl get cm -n kube-system | grep container-azm-ms-agentconfig # If there is no existing container-azm-ms-agentconfig configmap, then means cluster level prometheus data collection not enabledノードとポッドの数の観点からクラスターのサイズを確認します。
# Check if the cluster has container-azm-ms-agentconfig configmap in kube-system namespace NodeCount=$(kubectl get nodes | wc -l) echo "Total number of nodes: ${NodeCount}" PodCount=$(kubectl get pods -A -o wide | wc -l) echo "Total number of pods: ${PodCount}" # If there is no existing container-azm-ms-agentconfig configmap, then means cluster level prometheus data collection is not enabled.問題がクラスターのスケールに関連している場合は、ama-logs-rs メモリ制限を増やす必要があります。 この要求を行うには、Microsoft でサポート ケースを開きます。
待機時間に関する問題
既定では、Container insights は、データ収集設定を構成したり変換を追加したりしない限り、60 秒ごとに監視データを収集 します。 Log Analytics ワークスペースでの待機時間と予想される インジェスト時間 の詳細については、Azure Monitor のログ データ インジェスト時間に関するページを参照してください。
次のクエリを使用して、クラスターに関連付けられているログ分析ワークスペースのレポートされたテーブルと時間枠の待機時間を確認します。
let clusterResourceId = "/subscriptions/<subscriptionId>/resourceGroups/<rgName>/providers/Microsoft.ContainerService/managedClusters/<clusterName>";
let startTime = todatetime('2024-11-20T20:34:11.9117523Z');
let endTime = todatetime('2024-11-21T20:34:11.9117523Z');
KubePodInventory #Update this table name to the one you want to check
| where _ResourceId =~ clusterResourceId
| where TimeGenerated >= startTime and TimeGenerated <= endTime
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated
| extend AgentLatency = _TimeReceived - TimeGenerated
| summarize max(E2EIngestionLatency), max(AgentLatency) by Computer
| project Computer, max_AgentLatency, max_ingestionLatency = (max_E2EIngestionLatency - max_AgentLatency),max_E2EIngestionLatency
エージェントの待機時間が長い場合は、Container Insights DCR で既定の 60 秒とは異なるログ収集間隔を構成しているかどうかを確認します。
# set the subscriptionId of the cluster
az account set -s "<subscriptionId>"
# check if ContainerInsightsExtension data collection rule association exists
az monitor data-collection rule association list --resource <clusterResourceId>
# get the data collection rule resource id associated to ContainerInsightsExtension from above step
az monitor data-collection rule show --ids <dataCollectionRuleResourceIdFromAboveStep>
# check if there are any data collection settings related to interval from the output of the above step
複数行ログの問題
複数行ログ機能 は configmap で有効にすることができ、次のシナリオをサポートします。
- 既定の制限である 16 KB ではなく、最大 64 KB のログ メッセージをサポートします。
- サポートされている言語 .NET、Go、Python、Java の例外呼び出しスタック トレースを結合します。
次のコマンドを使用して、複数行機能と ContainerLogV2 スキーマが有効になっていることを確認します。
# get the list of ama-logs and these pods should be in Running state
# If these are not in Running state, then this needs to be investigated
kubectl get po -n kube-system | grep ama-logs
# exec into any one of the ama-logs daemonset pod and check for the environment variables
kubectl exec -it ama-logs-xxxxx -n kube-system -c ama-logs -- bash
# after exec into the container run this command
env | grep AZMON_MULTILINE
# result should have environment variables which indicates the multiline and languages enabled
AZMON_MULTILINE_LANGUAGES=java,go
AZMON_MULTILINE_ENABLED=true
# check if the containerlog v2 schema enabled or not
env | grep AZMON_CONTAINER_LOG_SCHEMA_VERSION
# output should be v2. If not v2, then check whether this is being enabled through DCR
AZMON_CONTAINER_LOG_SCHEMA_VERSION=v2