Compartir vía

Solución de problemas de Container Insights

  • Artículo

Al configurar la supervisión del clúster de Azure Kubernetes Service (AKS) con Container Insights, es posible que encuentre un problema que impida la recopilación de datos o el informe del estado. En este artículo se detallan algunos problemas comunes y los pasos para solucionarlos.

Mensajes de error conocidos

En la tabla siguiente se resumen los errores conocidos que podría encontrar al usar Container Insights.

Mensajes de error Acción
Mensaje de error "No hay datos para los filtros seleccionados" Es posible que se tarde algún tiempo en establecer el flujo de datos de supervisión para los clústeres recién creados. Espere de 10 a 15 minutos como mínimo para que aparezcan los datos del clúster.

Si los datos todavía no aparecen, compruebe si el área de trabajo de Log Analytics está configurada para disableLocalAuth = true. Si es así, vuelva a actualizar a 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
Mensaje de error "Error al recuperar datos" Mientras un clúster de AKS se configura para la supervisión de rendimiento y mantenimiento, se establece una conexión entre el clúster y un área de trabajo de Log Analytics. Se utiliza un área de trabajo de Log Analytics para almacenar todos los datos de supervisión del clúster. Este error puede producirse cuando el área de trabajo de Log Analytics se ha eliminado. Compruebe si se eliminó el área de trabajo. Si es así, vuelva a habilitar la supervisión del clúster con Container Insights. Después, especifique un área de trabajo existente o cree una nueva. Para volver a habilitar la supervisión, deshabilítela para el clúster y habilite de nuevo Container Insights.
"Error al recuperar datos" después de agregar Container Insights a través de az aks cli Al habilitar la supervisión con az aks cli, es posible que Container Insights no se implemente correctamente. Compruebe que la solución se ha implementado. Para comprobarlo, vaya al área de trabajo de Log Analytics y vea si la solución está disponible seleccionado Soluciones heredadas en el panel de la izquierda. Para resolver este problema, vuelva a implementar la solución. Siga las instrucciones de Habilitación de Container Insights.
Mensaje de error "Falta el registro de suscripción" Si recibe el error "Falta el registro de suscripción de Microsoft.OperationsManagement", puede resolverlo registrando el proveedor de recursos Microsoft.OperationsManagement en la suscripción en la que está definida el área de trabajo. Para seguir los pasos, consulte Resolución de errores del registro del proveedor de recursos.
Mensaje de error "La URL de respuesta especificada en la solicitud no coincide con las URL de respuesta configuradas para la aplicación: "<Id. de aplicación>"". Es posible que vea este mensaje de error al habilitar los registros en vivo. Para la solución, veaVisualización de datos de contenedor en tiempo real con Container Insights.

Para ayudar a diagnosticar el problema, hemos incluido un script de solución de problemas.

Error de autorización durante la operación de incorporación o actualización

Al habilitar Container Insights o actualizar un clúster para admitir la recopilación de métricas, es posible que reciba un error como "El cliente <user's Identity> con el identificador de objeto <user's objectId> no tiene autorización para realizar acciones Microsoft.Authorization/roleAssignments/write en el ámbito".

Durante el proceso de incorporación o de actualización, se intenta la asignación del rol Publicador de métricas de supervisión en el recurso de clúster. El usuario que inicia el proceso para habilitar Container Insights o la actualización para admitir la recopilación de métricas debe tener acceso al permiso Microsoft.Authorization/roleAssignments/write en el ámbito de recurso de clúster de AKS. Solo a los miembros de los roles integrados Propietario y Administrador de acceso de usuario se les ha concedido acceso a este permiso. Si las directivas de seguridad requieren que asigne permisos de nivel granular, consulte Roles personalizados de Azure y asigne permisos a los usuarios que lo requieran.

También puede conceder manualmente este rol desde Azure Portal: asigne el rol Publicador al ámbito Métricas de supervisión. Para obtener los pasos detallados, consulte Asignación de roles de Azure mediante Azure Portal.

Container Insights está habilitado, pero no notifica ninguna información

Para diagnosticar el problema si no puede ver la información de estado o no obtiene resultados de una consulta de registro:

  1. Compruebe el estado del agente ejecutando el comando siguiente:

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

    El número de pods debe ser igual al número de nodos de Linux del clúster. Si la salida se parece al ejemplo siguiente, la implementación se ha realizado correctamente:

    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. Si tiene nodos de Windows Server, compruebe el estado del agente mediante la ejecución del comando siguiente:

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

    El número de pods debe ser igual al número de nodos de Windows del clúster. Si la salida se parece al ejemplo siguiente, la implementación se ha realizado correctamente:

    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. Compruebe el estado de implementación mediante el comando siguiente:

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

    Si la salida se parece al ejemplo siguiente, la implementación se ha realizado correctamente:

    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. Con el comando kubectl get pods --namespace=kube-system, consulte el estado del pod para comprobar que se está ejecutando.

    La salida debe ser similar al ejemplo siguiente con un estado de Running para 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. Si los pods están en un estado en ejecución, pero no hay datos en Log Analytics o parece que los datos solo se pueden enviar durante una determinada parte del día, podría ser una indicación de que se ha alcanzado el límite diario. Cuando se alcanza este límite cada día, los datos dejan de ingerirse en el área de trabajo de Log Analytics y se restablecen en el momento del restablecimiento. Para más información, vea Límite diario de Log Analytics.

  6. Si Containter Insights está habilitado mediante Terraform y msi_auth_for_monitoring_enabled está establecido en true, asegúrese de que los recursos DCR y DCRA también se implementan para habilitar la recopilación de registros. Para obtener pasos detallados, consulte habilitación de Container Insights.

Los pods de ReplicaSet del agente de Container Insights no están programados en un clúster de Kubernetes que no es de AKS

Los pods de ReplicaSet del agente de Container Insights tienen una dependencia de los siguientes selectores de nodo en los nodos de trabajo (o agente) para la programación:

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

Si los nodos de trabajo no tienen etiquetas de nodo adjuntas, los pods de ReplicaSet del agente no se programarán. Consulte Selectores de etiqueta de asignación de Kubernetes para obtener instrucciones sobre cómo adjuntar la etiqueta.

Los gráficos de rendimiento no muestran la CPU o la memoria de los nodos y contenedores de un clúster que no es de Azure.

Los pods del agente de Container Insights usan el punto de conexión cAdvisor en el agente de nodo para recopilar las métricas de rendimiento. Compruebe que el agente en contenedor del nodo está configurado para permitir que se abra cAdvisor secure port: 10250 o cAdvisor unsecure port: 10255 en todos los nodos del clúster para recopilar las métricas de rendimiento. Consulte los requisitos previos para los clústeres híbridos de Kubernetes para obtener más información.

Los clústeres que no son de AKS no se muestran en Container Insights

Para ver el clúster de Kubernetes que no es de AKS en Container Insights, se necesita acceso de lectura en el área de trabajo de Log Analytics que admite esta información y en el recurso de la solución de Container Insights ContainerInsights (área de trabajo).

No se están recopilando las métricas

  1. Compruebe que la asignación de roles de Publicador de métricas de supervisión existe con el siguiente comando de la 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"

    En el caso de los clústeres con MSI, el identificador de cliente asignado por el usuario para el agente de Azure Monitor cambia cada vez que la supervisión se habilita y deshabilita, por lo que la asignación de roles debe existir en el identificador de cliente de MSI actual.

  2. En el caso de los clústeres con identidad de pod de Microsoft Entra habilitada y con MSI:

    • Compruebe que la etiqueta necesaria kubernetes.azure.com/managedby: aks está presente en los pods del agente de Azure Monitor con el siguiente comando:

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

    • Compruebe que las excepciones están habilitadas cuando la identidad de pod está habilitada mediante uno de los métodos admitidos en https://github.com/Azure/aad-pod-identity#1-deploy-aad-pod-identity.

      Para comprobarlo, ejecute el comando siguiente:

      kubectl get AzurePodIdentityException -A -o yaml

      Debería recibir un resultado similar al siguiente ejemplo:

      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

Error en la instalación de la extensión Containers de Azure Monitor en un clúster de Kubernetes habilitado para Azure Arc

El error "los manifiestos contienen un recurso que ya existe" indica que los recursos del agente de Container Insights ya existen en el clúster de Kubernetes habilitado para Azure Arc. Este error indica que el agente de Container Insights ya está instalado. Se instala a través de un gráfico de Helm de azuremonitor-containers o el complemento de supervisión si se trata de un clúster de AKS que está conectado a través de Azure Arc.

La solución a este problema es limpiar los recursos existentes del agente de Container Insights si existe. A continuación, habilite la extensión Containers de Azure Monitor para contenedores.

Para clústeres que no son de AKS

  1. En el clúster K8s conectado a Azure Arc, ejecute el siguiente comando para comprobar si la versión del gráfico de Helm azmon-containers-release-1 existe o no:

    helm list -A

  2. Si la salida del comando anterior indica que azmon-containers-release-1 existe, elimine la versión del gráfico de Helm:

    helm del azmon-containers-release-1

Para clústeres de AKS

  1. Ejecute los comandos siguientes y busque el perfil del complemento del agente de Azure Monitor para comprobar si el complemento de supervisión de AKS está habilitado:

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

  2. Si la salida incluye una configuración de perfil de complemento del agente de Azure Monitor con un identificador de recurso del área de trabajo de Log Analytics, esta información indica que el complemento de supervisión de AKS está habilitado y debe deshabilitarse:

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

Si con los pasos anteriores no se solucionó la instalación de la extensión de Containers de Azure Monitor, cree una incidencia de soporte técnico para que el equipo de Microsoft lo investigue más a fondo.

Se reciben alertas duplicadas

Es posible que haya habilitado reglas de alertas de Prometheus sin deshabilitar las alertas recomendadas de Container Insights. Consulte Migración de alertas recomendadas de Container Insights a reglas de alertas recomendadas de Prometheus (versión preliminar).

Veo el banner de información"No tiene los permisos de clúster adecuados, lo que restringirá el acceso a las características de Container Insights. Póngase en contacto con el administrador del clúster para obtener el permiso correcto"

Container Insights ha permitido históricamente a los usuarios acceder a la experiencia de Azure Portal en función del permiso de acceso del área de trabajo de Log Analytics. Ahora comprueba el permiso de nivel de clúster para proporcionar acceso a la experiencia de Azure Portal. Es posible que necesite que el administrador del clúster asigne este permiso.

Para el acceso básico de nivel de clúster de solo lectura, asigne el rol Lector de supervisión para los siguientes tipos de clústeres.

  • AKS sin la autorización de control de acceso basado en rol (RBAC) de Kubernetes habilitada
  • AKS habilitado con inicio de sesión único basado en SAML de Microsoft Entra
  • AKS habilitado con autorización de RBAC de Kubernetes
  • AKS configurado con el enlace de rol de clúster clusterMonitoringUser
  • Clústeres de Kubernetes habilitados para Azure Arc

Consulte Asignación de permisos de rol a un usuario o grupo para obtener más información sobre cómo asignar estos roles para AKS y Opciones de acceso e identidad para Azure Kubernetes Service (AKS) para obtener más información sobre las asignaciones de roles.

No veo que los valores de propiedad Name e Image se rellenen cuando consulto la tabla ContainerLog

En el caso de la versión del agente ciprod12042019 y versiones posteriores, estas dos propiedades no se rellenan de manera predeterminada en cada línea de registro con el fin de reducir el coste generado en los datos de registro recopilados. Hay dos opciones para consultar la tabla que incluyen estas propiedades con sus valores:

Opción 1

Combinar otras tablas para incluir estos valores de propiedad en los resultados.

Modifique las consultas para que incluyan las propiedades Image e ImageTag de la tabla ContainerInventory mediante la combinación de la propiedad ContainerID. Puede incluir la propiedad Name (como aparecía anteriormente en la tabla ContainerLog) del campo KubepodInventory de la tabla ContainerName mediante la combinación de la propiedad ContainerID. Le recomendamos esta opción.

El ejemplo siguiente es una consulta detallada de ejemplo que explica cómo obtener estos valores de campo con combinaciones.

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

Opción 2

Volver a habilitar la recopilación para estas propiedades en cada línea de registro de contenedor.

Si la primera opción no es conveniente debido a los cambios de consulta implicados, puede volver a habilitar la recopilación de estos campos. Habilite la configuración log_collection_settings.enrich_container_logs en el mapa de configuración del agente como se describe en los valores de configuración de recopilación de datos.

Nota:

No se recomienda la segunda opción para clústeres grandes que tengan más de 50 nodos. Genera llamadas al servidor API desde cada nodo del clúster para realizar este enriquecimiento. Esta opción también aumenta el tamaño de los datos de cada línea de registro recopilada.

No se puede actualizar un clúster después de incorporarlo

Este es el escenario: Ha habilitado Container Insights para un clúster de Azure Kubernetes Service. A continuación, ha eliminado el área de trabajo de Log Analytics donde el clúster envió sus datos. Ahora, cuando intenta actualizar el clúster, se produce un error. Para solucionar este problema, deberá deshabilitar la supervisión y, después, volver a habilitarla, pero de forma que haga referencia a otra área de trabajo válida de la suscripción. Tras ello, cuando intente llevar a cabo la actualización del clúster de nuevo, debería procesarse y completarse correctamente.

No se recopilan registros en el clúster de Azure Stack HCI

Si registró el clúster o configurado HCI Insights antes de noviembre de 2023, es posible que las características que usan el agente de Azure Monitor en HCI, como Arc for Servers Insights, VM Insights, Container Insights, Defender for Cloud o Microsoft Sentinel no recopilen registros ni datos de eventos correctamente. Consulte Reparación del agente AMA para HCI para ver los pasos para volver a configurar el agente y HCI Insights.

Pasos siguientes

Cuando la supervisión está habilitada para capturar métricas de estado para los pods y nodos del clúster de AKS, estas métricas de estado están disponibles en Azure Portal. Para obtener información sobre cómo usar Container Insights, vea Ver el estado de Azure Kubernetes Service.