Rozwiązywanie problemów z usługą Container Insights

Artykuł
02/15/2024

Podczas konfigurowania monitorowania klastra usługi Azure Kubernetes Service (AKS) za pomocą usługi Container Insights może wystąpić problem uniemożliwiający zbieranie danych lub raportowanie stanu. W tym artykule omówiono niektóre typowe problemy i kroki rozwiązywania problemów.

Znane komunikaty o błędach

W poniższej tabeli przedstawiono podsumowanie znanych błędów, które mogą wystąpić podczas korzystania ze szczegółowych informacji o kontenerze.

Komunikaty o błędach	Akcja
Komunikat o błędzie "Brak danych dla wybranych filtrów"	Uruchomienie przepływu danych monitorowania z nowo utworzonych klastrów może zająć trochę czasu. Poczekaj co najmniej 10 do 15 minut, aby dane pojawiały się w klastrze. Jeśli dane nadal nie są wyświetlane, sprawdź, czy obszar roboczy usługi Log Analytics jest skonfigurowany dla programu `disableLocalAuth = true`. Jeśli tak, zaktualizuj polecenie z powrotem do `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`
Komunikat o błędzie "Błąd podczas pobierania danych"	Podczas konfigurowania klastra usługi AKS na potrzeby monitorowania kondycji i wydajności połączenie jest ustanawiane między klastrem a obszarem roboczym usługi Log Analytics. Obszar roboczy usługi Log Analytics służy do przechowywania wszystkich danych monitorowania klastra. Ten błąd może wystąpić, gdy obszar roboczy usługi Log Analytics został usunięty. Sprawdź, czy obszar roboczy został usunięty. Jeśli tak było, można ponownie monitorować klaster za pomocą szczegółowych informacji o kontenerze. Następnie określ istniejący obszar roboczy lub utwórz nowy. Aby ponownie włączyć, wyłącz monitorowanie klastra i ponownie włącz szczegółowe informacje o kontenerze.
"Błąd podczas pobierania danych" po dodaniu szczegółowych informacji o kontenerze za pomocą `az aks cli`	Po włączeniu monitorowania przy użyciu polecenia `az aks cli`usługa Container Insights może nie zostać prawidłowo wdrożona. Sprawdź, czy rozwiązanie zostało wdrożone. Aby to sprawdzić, przejdź do obszaru roboczego usługi Log Analytics i sprawdź, czy rozwiązanie jest dostępne, wybierając pozycję Starsze rozwiązania w okienku po lewej stronie. Aby rozwiązać ten problem, ponownie wdróż rozwiązanie. Postępuj zgodnie z instrukcjami w artykule Włączanie szczegółowych informacji o kontenerze.
Komunikat o błędzie "Brak rejestracji subskrypcji"	Jeśli zostanie wyświetlony błąd "Brak rejestracji subskrypcji dla microsoft.OperationsManagement", możesz go rozwiązać, rejestrując dostawcę zasobów Microsoft.OperationsManagement w subskrypcji, w której zdefiniowano obszar roboczy. Aby uzyskać instrukcje, zobacz Rozwiązywanie błędów dotyczących rejestracji dostawcy zasobów.
Komunikat o błędzie "Adres URL odpowiedzi określony w żądaniu nie jest zgodny z adresami URL odpowiedzi skonfigurowanymi dla aplikacji: "<identyfikator> aplikacji".	Ten komunikat o błędzie może zostać wyświetlony po włączeniu dzienników na żywo. Aby zapoznać się z rozwiązaniem, zobacz Wyświetlanie danych kontenera w czasie rzeczywistym za pomocą usługi Container Insights.

Aby ułatwić diagnozowanie problemu, udostępniliśmy skrypt rozwiązywania problemów.

Błąd autoryzacji podczas operacji dołączania lub aktualizowania

Po włączeniu usługi Container Insights lub zaktualizowaniu klastra w celu obsługi zbierania metryk może zostać wyświetlony błąd, taki jak "Klient <user's Identity> o identyfikatorze <user's objectId> obiektu nie ma autoryzacji do wykonywania akcji Microsoft.Authorization/roleAssignments/write w zakresie".

Podczas procesu dołączania lub aktualizowania przypisywanie roli Wydawca metryk monitorowania jest podejmowane na zasobie klastra. Użytkownik inicjujący proces włączania usługi Container Insights lub aktualizacji do obsługi kolekcji metryk musi mieć dostęp do uprawnienia Microsoft.Authorization/roleAssignments/write w zakresie zasobów klastra usługi AKS. Tylko członkowie ról wbudowanych właściciela i dostępu użytkowników Administracja istrator otrzymują dostęp do tego uprawnienia. Jeśli zasady zabezpieczeń wymagają przypisania uprawnień na poziomie szczegółowym, zobacz Role niestandardowe platformy Azure i przypisz uprawnienia do użytkowników, którzy tego potrzebują.

Tę rolę można również przyznać ręcznie w witrynie Azure Portal: przypisz rolę wydawcy do zakresu metryki monitorowania. Aby uzyskać szczegółowe instrukcje, zobacz Przypisywanie ról platformy Azure przy użyciu witryny Azure Portal.

Usługa Container Insights jest włączona, ale nie zgłasza żadnych informacji

Aby zdiagnozować problem, jeśli nie można wyświetlić informacji o stanie lub nie są zwracane żadne wyniki z zapytania dziennika:

Sprawdź stan agenta, uruchamiając następujące polecenie:

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

Liczba zasobników powinna być równa liczbie węzłów systemu Linux w klastrze. Dane wyjściowe powinny przypominać następujący przykład, który wskazuje, że został prawidłowo wdrożony:
```
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
```
Jeśli masz węzły systemu Windows Server, sprawdź stan agenta, uruchamiając następujące polecenie:

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

Liczba zasobników powinna być równa liczbie węzłów systemu Windows w klastrze. Dane wyjściowe powinny przypominać następujący przykład, który wskazuje, że został prawidłowo wdrożony:
```
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
```
Sprawdź stan wdrożenia przy użyciu następującego polecenia:

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

Dane wyjściowe powinny przypominać następujący przykład, który wskazuje, że został prawidłowo wdrożony:
```
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
```

Sprawdź stan zasobnika, aby sprawdzić, czy jest uruchomiony przy użyciu polecenia kubectl get pods --namespace=kube-system.

Dane wyjściowe powinny przypominać następujący przykład ze stanem dla dzienników Running ama:

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

Jeśli zasobniki są w stanie uruchomienia, ale nie ma danych w usłudze Log Analytics lub dane wydają się być wysyłane tylko w określonej części dnia, może to oznaczać, że dzienny limit został spełniony. Gdy ten limit zostanie osiągnięty każdego dnia, dane przestaną pozyskiwać do obszaru roboczego usługi Log Analytics i resetować je w czasie resetowania. Aby uzyskać więcej informacji, zobacz Dzienny limit usługi Log Analytics.

Zasobniki replicaSet agenta usługi Container Insights nie są zaplanowane w klastrze spoza usługi AKS

Zasobniki replicaSet agenta usługi Container Insights mają zależność od następujących selektorów węzłów w węzłach procesu roboczego (lub agenta) na potrzeby planowania:

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

Jeśli węzły procesu roboczego nie mają dołączonych etykiet węzłów, zasobniki ReplicaSet agenta nie zostaną zaplanowane. Aby uzyskać instrukcje dotyczące dołączania etykiety, zobacz Kubernetes assign label selectors (Przypisywanie selektorów etykiet na platformie Kubernetes).

Wykresy wydajności nie pokazują procesora CPU ani pamięci węzłów i kontenerów w klastrze spoza platformy Azure

Zasobniki agenta usługi Container Insights używają punktu końcowego cAdvisor w agencie węzła do zbierania metryk wydajności. Sprawdź, czy konteneryzowany agent w węźle jest skonfigurowany do zezwalania cAdvisor secure port: 10250 na otwieranie na wszystkich węzłach w klastrze lub cAdvisor unsecure port: 10255 otwieranie go w celu zbierania metryk wydajności. Aby uzyskać więcej informacji, zobacz wymagania wstępne dotyczące hybrydowych klastrów Kubernetes.

Klastry inne niż AKS nie są wyświetlane w usłudze Container Insights

Aby wyświetlić klaster spoza usługi AKS w usłudze Container Insights, dostęp do odczytu jest wymagany w obszarze roboczym usługi Log Analytics, który obsługuje te szczegółowe informacje i w kontenerze zasobów rozwiązania Container Insights Szczegółowe informacje (obszar roboczy).

Metryki nie są zbierane

Sprawdź, czy przypisanie roli Wydawca metryk monitorowania istnieje przy użyciu następującego polecenia interfejsu wiersza polecenia:
```
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"
```
W przypadku klastrów z tożsamością usługi zarządzanego identyfikator klienta przypisany przez użytkownika dla agenta usługi Azure Monitor zmienia się za każdym razem, gdy monitorowanie jest włączone i wyłączone, więc przypisanie roli powinno istnieć na bieżącym identyfikatorze klienta MSI.
W przypadku klastrów z włączoną tożsamością zasobnika firmy Microsoft Entra i przy użyciu tożsamości usługi ZARZĄDZANEj:
- Sprawdź, czy wymagana etykieta kubernetes.azure.com/managedby: aks znajduje się w zasobnikach agenta usługi Azure Monitor, używając następującego polecenia:
  
  kubectl get pods --show-labels -n kube-system | grep ama-logs
- Sprawdź, czy wyjątki są włączone, gdy tożsamość zasobnika jest włączona przy użyciu jednej z obsługiwanych metod w witrynie https://github.com/Azure/aad-pod-identity#1-deploy-aad-pod-identity.
  
  Uruchom następujące polecenie, aby sprawdzić:
  
  kubectl get AzurePodIdentityException -A -o yaml
  
  Powinny zostać wyświetlone dane wyjściowe podobne do następującego przykładu:
```
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
```

Instalacja rozszerzenia kontenerów usługi Azure Monitor kończy się niepowodzeniem w klastrze Kubernetes z obsługą usługi Azure Arc

Błąd "manifesty zawierają już istniejący zasób" wskazuje, że zasoby agenta usługi Container Insights już istnieją w klastrze Kubernetes z obsługą usługi Azure Arc. Ten błąd wskazuje, że agent usługi Container Insights jest już zainstalowany. Jest on instalowany za pośrednictwem pakietu Helm azuremonitor-containers lub dodatku do monitorowania, jeśli jest to klaster usługi AKS połączony za pośrednictwem usługi Azure Arc.

Rozwiązaniem tego problemu jest wyczyszczenie istniejących zasobów agenta usługi Container Insights, jeśli istnieje. Następnie włącz rozszerzenie kontenerów usługi Azure Monitor.

W przypadku klastrów innych niż AKS

W przypadku klastra K8s połączonego z usługą Azure Arc uruchom następujące polecenie, aby sprawdzić, czy azmon-containers-release-1 wydanie pakietu Helm istnieje, czy nie:

helm list -A
Jeśli dane wyjściowe powyższego polecenia wskazują, że azmon-containers-release-1 istnieje, usuń wydanie pakietu Helm:

helm del azmon-containers-release-1

W przypadku klastrów usługi AKS

Uruchom następujące polecenia i poszukaj profilu dodatku agenta usługi Azure Monitor, aby sprawdzić, czy dodatek monitorowania usługi AKS jest włączony:
```
az  account set -s <clusterSubscriptionId>
az aks show -g <clusterResourceGroup> -n <clusterName>
```
Jeśli dane wyjściowe zawierają konfigurację profilu dodatku agenta usługi Azure Monitor z identyfikatorem zasobu obszaru roboczego usługi Log Analytics, te informacje wskazują, że dodatek monitorowania usługi AKS jest włączony i musi być wyłączony:

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

Jeśli powyższe kroki nie rozwiązały problemów z instalacją rozszerzenia kontenerów usługi Azure Monitor, utwórz bilet pomocy technicznej do wysłania do firmy Microsoft w celu przeprowadzenia dalszych badań.

Odbierane są zduplikowane alerty

Być może włączono reguły alertów Rozwiązania Prometheus bez wyłączania zalecanych alertów usługi Container Insights. Zobacz Migrowanie z zalecanych alertów usługi Container Insights do zalecanych reguł alertów (wersja zapoznawcza) rozwiązania Prometheus.

Kontener Szczegółowe informacje historycznie zezwolił użytkownikom na dostęp do środowiska witryny Azure Portal na podstawie uprawnień dostępu do obszaru roboczego usługi Log Analytics. Teraz sprawdza uprawnienia na poziomie klastra, aby zapewnić dostęp do środowiska witryny Azure Portal. Może być konieczne przypisanie tego uprawnienia przez administratora klastra.

Aby uzyskać podstawowy dostęp na poziomie klastra tylko do odczytu, przypisz rolę Czytelnik monitorowania dla następujących typów klastrów.

Usługa AKS bez włączonej autoryzacji kontroli dostępu opartej na rolach (RBAC) platformy Kubernetes
Usługa AKS włączona przy użyciu logowania jednokrotnego opartego na protokole SAML firmy Microsoft
Usługa AKS włączona z autoryzacją RBAC na platformie Kubernetes
Usługa AKS skonfigurowana za pomocą klastra powiązania roli klastraMonitoringUser
Klastry Kubernetes z obsługą usługi Azure Arc

Zobacz Przypisywanie uprawnień roli do użytkownika lub grupy , aby uzyskać szczegółowe informacje na temat przypisywania tych ról dla usługi AKS oraz opcji dostępu i tożsamości dla usługi Azure Kubernetes Service (AKS), aby dowiedzieć się więcej na temat przypisań ról.

Nie widzę wartości właściwości Obraz i Nazwa wypełnione podczas wykonywania zapytania względem tabeli ContainerLog

W przypadku wersji agenta ciprod12042019 i nowszych te dwie właściwości nie są domyślnie wypełniane dla każdego wiersza dziennika w celu zminimalizowania kosztów poniesionych na zebrane dane dziennika. Istnieją dwie opcje wykonywania zapytań dotyczących tabeli, które zawierają te właściwości z ich wartościami:

Opcja 1

Dołącz inne tabele, aby uwzględnić te wartości właściwości w wynikach.

Zmodyfikuj ContainerInventory zapytania, aby uwzględnić Image właściwości i ImageTag z tabeli, dołączając do ContainerID właściwości . Właściwość (tak jak wcześniej wyświetlana w tabeli) można uwzględnić Name w KubepodInventory polu tabeliContainerName, łącząc ją z właściwościąContainerID.ContainerLog Zalecamy wybranie tej opcji.

Poniższy przykład to przykładowe szczegółowe zapytanie, które wyjaśnia, jak uzyskać te wartości pól ze sprzężeniami.

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

Opcja 2

Można ponownie przywrócić kolekcję dla tych właściwości dla każdego wiersza dziennika kontenera.

Jeśli pierwsza opcja nie jest wygodna z powodu zmian zapytań, możesz ponownie zbierać te pola. Włącz ustawienie log_collection_settings.enrich_container_logs na mapie konfiguracji agenta zgodnie z opisem w ustawieniach konfiguracji zbierania danych.

Uwaga

Nie zalecamy drugiej opcji dla dużych klastrów, które mają więcej niż 50 węzłów. Generuje ona wywołania serwera interfejsu API z każdego węzła w klastrze w celu przeprowadzenia tego wzbogacania. Ta opcja zwiększa również rozmiar danych dla każdego zebranego wiersza dziennika.

Nie mogę uaktualnić klastra po dołączeniu

Oto scenariusz: Włączono szczegółowe informacje o kontenerze dla klastra usługi Azure Kubernetes Service. Następnie usunięto obszar roboczy usługi Log Analytics, w którym klaster wysyłał jego dane. Teraz, gdy próbujesz uaktualnić klaster, kończy się niepowodzeniem. Aby obejść ten problem, należy wyłączyć monitorowanie, a następnie przywrócić go, odwołując się do innego prawidłowego obszaru roboczego w ramach subskrypcji. Po ponowieniu próby przeprowadzenia uaktualnienia klastra powinien on przetworzyć i zakończyć pomyślnie.

Nie zbieraj dzienników w klastrze usługi Azure Stack HCI

Jeśli zarejestrowano klaster i/lub skonfigurowano Szczegółowe informacje HCI przed listopadem 2023 r., funkcje korzystające z agenta usługi Azure Monitor w rozwiązaniu HCI, takie jak Arc for Servers Szczegółowe informacje, vm Szczegółowe informacje, container Szczegółowe informacje, Defender dla Chmury lub Usługa Microsoft Sentinel może nie zbierać dzienników i danych zdarzeń prawidłowo. Zobacz Naprawianie agenta AMA dla rozwiązania HCI, aby uzyskać instrukcje dotyczące ponownej konfiguracji agenta i Szczegółowe informacje HCI.

Następne kroki

Po włączeniu monitorowania w celu przechwytywania metryk kondycji dla węzłów i zasobników klastra usługi AKS te metryki kondycji są dostępne w witrynie Azure Portal. Aby dowiedzieć się, jak używać usługi Container Insights, zobacz Wyświetlanie Kondycja usługi usługi Azure Kubernetes.