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

  • Článek

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.

Chybové zprávy Akce
Chybová zpráva Žádná data pro vybrané filtry Vytvoření toku dat monitorování pro nově vytvořené clustery může nějakou dobu trvat. Počkejte alespoň 10 až 15 minut, než se data pro váš cluster zobrazí.

Pokud se data stále nezobrazují, zkontrolujte, jestli je pracovní prostor služby Log Analytics nakonfigurovaný pro disableLocalAuth = true. Pokud ano, aktualizujte zpět na 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
Chybová zpráva Při načítání dat došlo k chybě. Zatímco cluster AKS nastavuje monitorování stavu a výkonu, vytvoří se mezi clusterem a pracovním prostorem služby Log Analytics připojení. Pracovní prostor služby Log Analytics slouží k ukládání všech dat monitorování pro váš cluster. K této chybě může dojít při odstranění pracovního prostoru služby Log Analytics. Zkontrolujte, jestli se pracovní prostor odstranil. Pokud ano, můžete znovu povolit monitorování clusteru pomocí přehledů kontejnerů. Pak zadejte existující pracovní prostor nebo vytvořte nový. Pokud chcete monitorování clusteru znovu povolit, zakažte monitorování clusteru a znovu povolte přehledy kontejnerů.
Chyba při načítání dat po přidání přehledů kontejnerů prostřednictvím az aks cli Když povolíte monitorování pomocí az aks cli, nemusí být přehledy kontejnerů správně nasazené. Zkontrolujte, jestli je řešení nasazené. Pokud to chcete ověřit, přejděte do pracovního prostoru služby Log Analytics a zkontrolujte, jestli je řešení dostupné výběrem starších řešení z podokna na levé straně. Pokud chcete tento problém vyřešit, znovu nasaďte řešení. Postupujte podle pokynů v tématu Povolení přehledů kontejnerů.
Chybová zpráva Chybějící registrace předplatného Pokud se zobrazí chyba Chybějící registrace předplatného pro Microsoft.OperationsManagement, můžete ji vyřešit registrací poskytovatele prostředků Microsoft.OperationsManagement v předplatném, ve kterém je pracovní prostor definovaný. Postup najdete v tématu Řešení chyb registrace poskytovatele prostředků.
Chybová zpráva "Adresa URL odpovědi zadaná v požadavku neodpovídá adresám URL odpovědí nakonfigurovaným pro aplikaci: "<ID> aplikace". Tato chybová zpráva se může zobrazit, když povolíte živé protokoly. Řešení najdete v tématu Zobrazení dat kontejneru v reálném čase pomocí 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. Přístup k tomuto oprávnění mají přístup pouze členové předdefinovaných rolí Vlastník a Uživatelský přístup Správa istrator. 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.

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 pro čtení v pracovním prostoru služby Log Analytics, který tento přehled podporuje, a v kontejneru prostředků řešení Container Insights Přehledy (pracovní prostor).

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 Přehledy. Pokud chcete získat správná oprávnění, obraťte se na správce clusteru.

Kontejner Přehledy 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.

Poznámka:

Nedoporučujeme druhou možnost pro velké clustery, které mají více než 50 uzlů. Generuje volání serveru rozhraní API z každého uzlu v clusteru, aby bylo možné provést toto rozšiřování. Tato možnost také zvyšuje velikost dat pro každý shromážděný řádek protokolu.

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 zaregistrovali cluster nebo jste nakonfigurovali Přehledy HCI před listopadem 2023, nemusí funkce, které používají agenta Azure Monitoru v HCI, jako je Arc for Servers Přehledy, VM Přehledy, Container Přehledy, Defender for Cloud nebo Microsoft Sentinel, správně shromažďovat protokoly a data událostí. Postup opětovné konfigurace agenta AMy a HCI Přehledy 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.