進行容器深入解析的疑難排解

當您設定使用容器深入解析來監視 Azure Kubernetes Service (AKS) 叢集時，您也許會遇到阻止資料收集或報告狀態的問題。 本文將說明一些常見問題與疑難排解步驟。

已知的錯誤訊息

下表摘要說明使用容器深入解析時可能會遇到的已知錯誤。

錯誤訊息	動作
「選取的篩選沒有任何資料」錯誤訊息	為新建立的叢集建立監視資料流程可能需要一些時間。 至少需 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 工作區遭到刪除時可能會發生此錯誤。 檢查工作區是否已刪除。 如果是，請使用容器深入解析重新監視叢集。 接著指定現有的工作區或建立新的。 若要重新啟用，請停用對叢集的監視，並再次啟用容器深入解析。
在透過 az aks cli 新增容器深入解析之後出現「擷取資料錯誤」	當您使用 az aks cli 啟用監視時，可能無法正確部署容器深入解析。 檢查這個解決方案是否已部署。 若要驗證，請前往 Log Analytics 工作區，選取左側窗格的 [解決方案]，查看舊版解決方案是否可使用。 若要解決此問題，請重新部署解決方案。 請遵循啟用容器深入解析中的指示。
「缺少訂用帳戶註冊」錯誤訊息	如果您收到「缺少 Microsoft.OperationsManagement 的訂用帳戶註冊」錯誤，您可以在定義工作區的訂用帳戶中註冊資源提供者 Microsoft.OperationsManagement 來解決此問題。 針對步驟，請參閱解決資源提供者註冊的錯誤。
錯誤訊息「在要求中指定的回覆 URL 不符合為應用程式設定的回覆 URL：'<應用程式識別碼>'。」	當您啟用即時記錄時，可能會看到此錯誤訊息。 如需解決方案，請參閱使用容器深入解析即時檢視容器資料。

為了協助診斷問題，我們提供了疑難排解指令碼。

上線或更新作業期間發生授權錯誤

當您啟用容器深入解析或更新叢集以支援收集計量時，您可能會收到錯誤，例如「具有物件識別碼 <user's objectId> 的用戶端 <user's Identity> 沒有權限可對範圍執行動作 Microsoft.Authorization/roleAssignments/write。」

在上線或更新程序期間，會在叢集資源上嘗試授與監視計量發行者角色指派。 起始程序以啟用容器深入解析或更新來支援計量收集的使用者，必須具有 AKS 叢集資源範圍上 Microsoft.Authorization/roleAssignments/write 權限的存取權。 只有擁有者和使用者存取系統管理員內建角色會獲得授與此權限的存取權。 如果您的安全性原則需要您指派細微層級權限，起參閱 Azure 自訂角色，並將權限指派給需要該角色的使用者。

您也可以從 Azure 入口網站手動授與此角色：將發行者角色指派給監視計量範圍。 如需詳細步驟，請參閱使用 Azure 入口網站指派 Azure 角色。

容器深入解析已啟用，但是未報告任何資訊

如果您無法檢視狀態資訊或未從記錄查詢傳回任何結果：

1. 請執行下列命令來檢查代理程式的狀態：

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

   輸出應該會像下列範例，這表示它已正確部署：

   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           beta.kubernetes.io/os=linux   1d
   

2. 如果您有 Windows Server 節點，請執行下列命令來檢查代理程式的狀態：

   kubectl get ds omsagent-win --namespace=kube-system

   輸出應該會像下列範例，這表示它已正確部署：

   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           beta.kubernetes.io/os=windows   1d
   

3. 使用代理程式 06072018 版或更新版本利用下列命令，來檢查部署狀態：

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

   輸出應該會像下列範例，這表示它已正確部署：

   User@aksuser:~$ kubectl get deployment omsagent-rs -n=kube-system
   NAME       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE    AGE
   ama-logs   1         1         1            1            3h
   

4. 執行命令 kubectl get pods --namespace=kube-system 來檢查 Pod 的狀態，以確認其正在執行。

   輸出應該會像下列範例，且 omsagent 的狀態為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. 如果 Pod 處於執行中狀態，但 Log Analytics 中沒有任何資料，或資料似乎只會在一天中的某個部分傳送，則可能表示已符合每日上限。 每天符合此限制時，資料會停止內嵌至 Log Analytics 工作區，並在重設時間重設。 如需詳細資訊，請參閱 Log Analytics 每日上限。

容器深入解析代理程式 ReplicaSet Pod 未在非 AKS 叢集上排程

容器深入解析代理程式 ReplicaSet Pod 相依於背景工作角色 (或代理程式) 節點上的下列節點選取器，以進行排程：

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

如果您的背景工作角色節點未附加節點標籤，則代理程式 ReplicaSet Pod 將不會排程。 如需如何附加標籤的指示，請閱 Kubernetes 指派標籤選取器。

效能圖表不會顯示非 Azure 叢集上節點和容器的 CPU 或記憶體

容器深入解析代理程式 Pod 會使用節點代理程式上的 cAdvisor 端點來收集效能計量。 請確認節點上的容器化代理程式已設定為允許 cAdvisor secure port: 10250 或 cAdvisor unsecure port: 10255 在叢集中的所有節點上開啟，以收集效能計量。 如需詳細資訊，請參閱混合式 Kubernetes 叢集必要條件。

容器深入解析中未顯示非 AKS 叢集

若要在容器深入解析中檢視非 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 監視器代理程式的使用者指派用戶端識別碼都會變更，因此角色指派應該存在於目前的 msi 用戶端識別碼上。

2. 針對已啟用 Microsoft Entra Pod 身分識別並使用 MSI 的叢集：

   • 透過使用下列命令確認 Azure 監視器代理程式 Pod 上有必要的標籤 kubernetes.azure.com/managedby: aks：

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

   • 透過使用 https://github.com/Azure/aad-pod-identity#1-deploy-aad-pod-identity 的其中一個支援方法，確認當 Pod 身分識別啟用時例外狀況已啟用。

     執行下列命令以進行確認：

     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 監視器容器擴充功能失敗

錯誤資訊清單包含已存在的資源，表示容器深入解析代理程式的資源已存在於已啟用 Azure Arc 的 Kubernetes 叢集上。 此錯誤表示容器深入解析代理程式已安裝。 如果是透過 Azure Arc 連線的 AKS 叢集，則會透過 azuremonitor-containers Helm 圖表或監視附加元件來安裝。

此問題的解決方案是，如果容器深入解析代理程式存在，則會清除現有的資源。 然後啟用 Azure 監視器容器延伸模組。

針對非 AKS 叢集

1. 針對連線至 Azure Arc 的 K8s 叢集，執行下列命令來確認 azmon-containers-release-1 helm 圖表版本是否存在：

   helm list -A

2. 如果前述命令的輸出指出 azmon-containers-release-1 存在，請刪除 helm 圖表版本：

   helm del azmon-containers-release-1

針對 AKS 叢集

1. 執行下列命令並尋找 Azure 監視器代理程式附加元件設定檔，確認是否已啟用 AKS 監視附加元件：

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

2. 如果輸出包含具有 Log Analytics 工作區資源識別碼的 Azure 監視器代理程式附加元件設定檔組態，此資訊表示已啟用 AKS 監視附加元件，且必須停用：

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

如果前述步驟無法解決 Azure 監視器容器擴充功能的安裝問題，請建立支援票證並傳送給 Microsoft 以進一步調查。

收到重複的警示

您可能已啟用 Prometheus 警示規則，而不停用容器深入解析建議的警示。 請參閱從容器深入解析建議警示移轉至 Prometheus 建議的警示規則 (預覽)。

我看到資訊橫幅「您沒有正確的叢集權限」，這會限制您對容器深入解析功能的存取。 請連絡您的叢集管理員以取得正確的權限」

容器深入解析歷來允許使用者根據 Log Analytics 工作區的訪問權限來存取 Azure 入口網站體驗。 這現在會檢查叢集層級的權限，以提供 Azure 入口網站體驗的存取權。 您可能需要叢集管理員來指派此權限。

如需基本的只讀叢集層級存取，請為下列類型的叢集指派監視讀取器角色。

• 已啟用不具 Kubernetes 角色型存取控制 (RBAC) 授權的 AKS
• 已啟用 Microsoft Entra SAML 型單一登入的 AKS
• 已使用 Kubernetes RBAC 授權啟用的 AKS
• 使用叢集角色繫結 clusterMonitoringUser 設定的 AKS
• 已啟用 Azure Arc 的 Kubernetes 叢集

如需如何為 AKS 指派這些角色的詳細資訊，請參閱將角色權限指派給使用者或群組以深入了解解角色指派的詳細資訊，以及 Azure Kubernetes Service (AKS) 的存取和身分識別選項。

當我查詢 ContainerLog 資料表時，看不到已填入的 Image 和 Name 屬性值

針對代理程式版本 ciprod12042019 和後續版本，預設不會針對每個記錄行填入這兩個屬性，以將收集到的記錄資料上所產生的成本降至最低。 有兩個選項可查詢包含這些屬性及其值的資料表：

選項 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

針對每個容器記錄行重新啟用這些屬性的集合。

如果第一個選項因為涉及查詢變更而不方便，您可以重新收集這些欄位。 在代理程式 Configmap 中啟用設定 log_collection_settings.enrich_container_logs，如資料收集組態設定中所述。

注意

對於擁有 50 個以上的節點的大型叢集，我們不建議使用第二個選項。 這會從叢集中的每個節點產生 API 伺服器呼叫，以執行此擴充。 此選項也會針對每個收集到的記錄行增加資料大小。

我無法在上線之後升級叢集

以下是案例：您已為 Azure Kubernetes Service 叢集啟用容器深入解析。 接著您刪除了叢集正在傳送其資料的 Log Analytics 工作區。 現在當您嘗試升級叢集時，這會失敗。 若要解決此問題，您必須停用監視，然後參考您訂用帳戶中不同的有效工作區，以便重新啟用。 當您再次嘗試執行叢集升級時，其應該會處理並順利完成。

未收集 Azure Stack HCI 叢集上的記錄

如果您在 2023 年 11 月之前註冊叢集和/或設定 HCI Insights，則 HCI 上使用 Azure 監視器代理程式的功能，例如 Arc for Servers Insights、VM Insights、Container Insights、Defender for Cloud 或 Microsoft Sentinel，可能無法正確收集記錄和事件資料。 如需重新設定代理程式和 HCI Insights 的步驟，請參閱修復 HCI AMA 代理程式。

下一步

藉由啟用監視來擷取 AKS 叢集節點和 Pod 的健康情況計量，這些健康情況計量都可在 Azure 入口網站中取得。 若要了解如何使用容器深入解析，請參閱檢視 Azure Kubernetes Service 健康情況。