Řešení potíží s přehledy kontejnerů

Když konfigurujete monitorování clusteru Azure Kubernetes Service (AKS) pomocí služby Container Insights, může dojít k problému, který brání shromažďování dat nebo hlášení stavu. Tento článek popisuje některé běžné problémy a kroky pro řešení potíží.

Běžné chybové zprávy

Následující tabulka shrnuje známé chyby, se kterými se můžete setkat při použití přehledů kontejneru.

Abychom vám pomohli s diagnostikou problému, poskytli jsme skript pro řešení potíží.

Chyba autorizace během operace onboardingu nebo aktualizace

Když povolíte službu Container Insights nebo aktualizujete cluster tak, aby podporoval shromažďování metrik, může se zobrazit chyba typu Klient <user's Identity> s ID <user's objectId> objektu nemá autorizaci k provedení akce Microsoft.Authorization/roleAssignments/write v oboru.

Během procesu onboardingu nebo aktualizace se u prostředku clusteru pokusí udělit přiřazení role vydavatele metrik monitorování. Uživatel, který zahájí proces povolení služby Container Insights nebo aktualizace pro podporu shromažďování metrik, musí mít přístup k oprávnění Microsoft.Authorization/roleAssignments/write v oboru prostředků clusteru AKS. K tomuto oprávnění mají přístup pouze členové předdefinovaných rolí Vlastník a Správce uživatelských přístupů. Pokud zásady zabezpečení vyžadují, abyste přiřadili podrobná oprávnění, přečtěte si vlastní role Azure a přiřaďte oprávnění uživatelům, kteří je vyžadují.

Tuto roli můžete také udělit ručně z webu Azure Portal: Přiřaďte roli Vydavatele k oboru metrik monitorování. Podrobný postup najdete v tématu Přiřazení rolí Azure pomocí webu Azure Portal.

Služba Container Insights je povolená, ale nehlásí žádné informace

Pokud chcete diagnostikovat problém, pokud nemůžete zobrazit informace o stavu nebo se nevrátí žádné výsledky z dotazu protokolu:

1. Spuštěním následujícího příkazu zkontrolujte stav agenta:

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

   Počet podů by se měl rovnat počtu linuxových uzlů v clusteru. Výstup by měl vypadat podobně jako v následujícím příkladu, který označuje, že se správně nasadil:

   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. Pokud máte uzly Windows Serveru, zkontrolujte stav agenta spuštěním následujícího příkazu:

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

   Počet podů by se měl rovnat počtu uzlů Windows v clusteru. Výstup by měl vypadat podobně jako v následujícím příkladu, který označuje, že se správně nasadil:

   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. Pomocí následujícího příkazu zkontrolujte stav nasazení:

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

   Výstup by měl vypadat podobně jako v následujícím příkladu, který označuje, že se správně nasadil:

   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. Pomocí příkazu kubectl get pods --namespace=kube-systemzkontrolujte stav podu a ověřte, že je spuštěný.

   Výstup by měl vypadat podobně jako v následujícím příkladu se stavem Running ama-logs:

   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. Pokud jsou pody ve spuštěném stavu, ale v Log Analytics se nezobrazují žádná data nebo se zdá, že se data odesílají jenom během určité části dne, může to značit splnění denního limitu. Když se tento limit splní každý den, data přestanou ingestovat do pracovního prostoru služby Log Analytics a resetují se v době resetování. Další informace najdete v tématu Denní limit log Analytics.

6. Pokud je funkce Containter Insights povolená pomocí Terraformu a msi_auth_for_monitoring_enabled je nastavená na true, ujistěte se, že jsou nasazené také prostředky DCR a DCRA pro povolení shromažďování protokolů. Podrobné kroky najdete v tématu povolení přehledů kontejnerů.

Pody ReplicaSet agenta Container Insights nejsou naplánované v clusteru bez AKS

Pody ReplicaSet agenta Container Insights jsou závislé na následujících selektorech uzlů v uzlech pracovního procesu (nebo agenta) pro plánování:

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

Pokud vaše pracovní uzly nemají připojené popisky uzlů, nenaplánují se pody replik agenta ReplicaSet. Pokyny k připojení popisku najdete v tématu o přiřazování selektorů popisků Kubernetes.

Grafy výkonu nezobrazují procesor ani paměť uzlů a kontejnerů v clusteru mimo Azure

Pody agenta Container Insights používají koncový bod cAdvisoru v agentu uzlu ke shromažďování metrik výkonu. Ověřte, že je kontejnerizovaný agent na uzlu nakonfigurovaný tak, aby povoloval cAdvisor secure port: 10250 nebo cAdvisor unsecure port: 10255 byl otevřen na všech uzlech v clusteru, aby shromažďoval metriky výkonu. Další informace najdete v požadavcích pro hybridní clustery Kubernetes.

Clustery bez AKS se nezobrazují v Přehledech kontejnerů

Pokud chcete zobrazit cluster bez AKS v Přehledech kontejnerů, vyžaduje se přístup ke čtení v pracovním prostoru služby Log Analytics, který tento přehled podporuje, a v prostředku řešení ContainerInsights (pracovní prostor) pro přehledy kontejnerů.

Metriky se neshromažďují

1. Pomocí následujícího příkazu rozhraní příkazového řádku ověřte, že existuje přiřazení role Vydavatel metrik monitorování metrik:

   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"
   

   U clusterů s MSI se ID klienta přiřazené uživatelem pro agenta Azure Monitoru změní při každém povolení a zakázání monitorování, takže přiřazení role by mělo existovat na aktuálním ID klienta MSI.

2. Pro clustery s povolenou identitou podu Microsoft Entra a s využitím MSI:

   • Pomocí následujícího příkazu ověřte, že požadovaný popisek kubernetes.azure.com/managedby: aks se nachází na podech agenta služby Azure Monitor:

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

   • Pomocí jedné z podporovaných metod na adrese https://github.com/Azure/aad-pod-identity#1-deploy-aad-pod-identity. ověřte, že jsou povoleny výjimky, pokud je povolena identita podu.

     Spuštěním následujícího příkazu ověřte:

     kubectl get AzurePodIdentityException -A -o yaml

     Měl by se zobrazit výstup podobný následujícímu příkladu:

     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
     

Instalace rozšíření kontejnerů služby Azure Monitor selže v clusteru Kubernetes s podporou Služby Azure Arc

Chyba Manifesty obsahují prostředek, který již existuje, značí, že prostředky agenta Container Insights už existují v clusteru Kubernetes s podporou Služby Azure Arc. Tato chyba značí, že agent Container Insights je už nainstalovaný. Instaluje se buď prostřednictvím chartu Helm pro azuremonitor-containers, nebo doplňku pro monitorování, pokud se jedná o cluster AKS připojený přes Azure Arc.

Řešením tohoto problému je vyčištění existujících prostředků agenta Container Insights, pokud existuje. Pak povolte rozšíření azure Monitor Containers.

Pro clustery mimo AKS

1. V clusteru K8s, který je připojený ke službě Azure Arc, spusťte následující příkaz a ověřte, jestli verze chartu azmon-containers-release-1 Helm existuje, nebo ne:

   helm list -A

2. Pokud výstup předchozího příkazu indikuje, že azmon-containers-release-1 existuje, odstraňte verzi chartu Helm:

   helm del azmon-containers-release-1

Pro clustery AKS

1. Spusťte následující příkazy a vyhledejte profil doplňku agenta služby Azure Monitor a ověřte, jestli je povolený doplněk monitorování AKS:

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

2. Pokud výstup obsahuje konfiguraci profilu doplňku agenta služby Azure Monitor s ID prostředku pracovního prostoru služby Log Analytics, tyto informace označují, že je povolený doplněk pro monitorování AKS a musí být zakázaný:

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

Pokud předchozí kroky nevyřešily problémy s instalací rozšíření kontejnerů služby Azure Monitor, vytvořte lístek podpory, který odešle Microsoftu k dalšímu šetření.

Příjem duplicitních výstrah

Možná jste povolili pravidla upozornění Prometheus bez zakázání doporučených upozornění služby Container Insights. Podívejte se na téma Migrace z doporučených upozornění služby Container Insights na doporučená pravidla upozornění pro Prometheus (Preview).

Zobrazuje se informační zpráva "Nemáte správná oprávnění ke clusteru, která omezí váš přístup k funkcím Container Insights. Pokud chcete získat správná oprávnění, obraťte se na správce clusteru.

Container Insights má historicky povolený přístup uživatelů k prostředí webu Azure Portal na základě oprávnění přístupu pracovního prostoru služby Log Analytics. Teď kontroluje oprávnění na úrovni clusteru a poskytuje přístup k prostředí webu Azure Portal. K přiřazení tohoto oprávnění možná budete potřebovat správce clusteru.

Pro základní přístup na úrovni clusteru jen pro čtení přiřaďte roli Čtenář monitorování pro následující typy clusterů.

• AKS bez povolení řízení přístupu na základě role (RBAC) Kubernetes
• Povolení AKS s jednotným přihlašováním založeným na Microsoft Entra SAML
• Povolení AKS s autorizací RBAC Kubernetes
• AKS nakonfigurované s vazbou role clusteru clusterMonitoringUser
• Clustery Kubernetes s podporou Azure Arc

Další informace o přiřazení rolí najdete v tématu Přiřazení oprávnění role uživateli nebo skupině , kde najdete podrobnosti o tom, jak přiřadit tyto role pro AKS a možnosti přístupu a identit pro Službu Azure Kubernetes Service (AKS ).

Při dotazování na tabulku ContainerLog se nezobrazují hodnoty vlastností Image a Name

Pro verzi agenta ciprod12042019 a novější se ve výchozím nastavení tyto dvě vlastnosti nenaplní pro každý řádek protokolu, aby se minimalizovaly náklady na shromážděná data protokolu. Existují dvě možnosti dotazu na tabulku, která obsahuje tyto vlastnosti s jejich hodnotami:

Možnost 1

Spojte další tabulky, abyste tyto hodnoty vlastností zahrnuli do výsledků.

Upravte dotazy tak, aby zahrnovaly Image a ImageTag vlastnosti z ContainerInventory tabulky se připojují k ContainerID vlastnosti. Vlastnost (jak se dříve objevila v ContainerLog tabulce) můžete zahrnout Name z KubepodInventory pole tabulky ContainerName tak, že se k ContainerID vlastnosti připojíte. Tuto možnost doporučujeme.

Následující příklad je ukázkový podrobný dotaz, který vysvětluje, jak získat tyto hodnoty polí pomocí spojení.

//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

Možnost 2

Opětovně použitelná kolekce pro tyto vlastnosti pro každý řádek protokolu kontejneru.

Pokud první možnost není vhodná kvůli změnám dotazů, můžete tato pole znovu shromáždit. Povolte nastavení log_collection_settings.enrich_container_logs v mapě konfigurace agenta, jak je popsáno v nastavení konfigurace shromažďování dat.

Po onboardingu nejde upgradovat cluster

Tady je scénář: Povolili jste přehledy kontejnerů pro cluster Azure Kubernetes Service. Potom jste odstranili pracovní prostor služby Log Analytics, ve kterém cluster odesílal data. Když se teď pokusíte cluster upgradovat, selže. Chcete-li tento problém vyřešit, musíte zakázat monitorování a potom ho znovu povolit odkazováním na jiný platný pracovní prostor ve vašem předplatném. Když se pokusíte provést upgrade clusteru znovu, měl by se proces zpracovat a úspěšně dokončit.

Neshromažďování protokolů v clusteru Azure Stack HCI

Pokud jste cluster zaregistrovali nebo nakonfigurovali přehledy HCI před listopadem 2023, nemusí funkce, které používají agenta Azure Monitoru v HCI, jako je Arc for Servers Insights, VM Insights, Container Insights, Defender for Cloud nebo Microsoft Sentinel, správně shromažďovat protokoly a data událostí. Postup opětovné konfigurace agenta a přehledů HCI najdete v tématu Oprava agenta AMA pro HCI .

Další kroky

Pokud je monitorování povolené pro zachycení metrik stavu pro uzly a pody clusteru AKS, jsou tyto metriky stavu k dispozici na webu Azure Portal. Informace o používání přehledů kontejnerů najdete v tématu Zobrazení Stav služby Azure Kubernetes.