View a markdown version of this page

Solución de problemas con el complemento de SageMaker HyperPod observabilidad de Amazon - Amazon SageMaker AI

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Solución de problemas con el complemento de SageMaker HyperPod observabilidad de Amazon

Usa la siguiente guía para resolver problemas comunes con el complemento de observabilidad Amazon SageMaker HyperPod (SageMaker HyperPod).

Solución de problemas de métricas que faltan de Amazon Managed Grafana

Si las métricas no aparecen en los paneles de Amazon Managed Grafana, siga estos pasos para identificar y resolver el problema.

Verificación de la conexión entre Amazon Managed Service para Prometheus y Amazon Managed Grafana

  1. Inicie sesión en la consola de Amazon Managed Grafana.

  2. En el panel de navegación izquierdo, elija Todos los espacios de trabajo.

  3. En la tabla Espacios de trabajo, elija su espacio de trabajo.

  4. En la página de detalles del espacio de trabajo, seleccione la pestaña Orígenes de datos.

  5. Compruebe que existe el origen de datos de Amazon Managed Service para Prometheus.

  6. Compruebe los ajustes de la conexión:

    • Confirme que la URL del punto de conexión sea correcta.

    • Compruebe que la autenticación de IAM esté configurada correctamente.

    • Elija Probar conexión. Compruebe que el estado sea El origen de datos funciona.

Verificación del estado del complemento de Amazon EKS

  1. Abra la consola Amazon EKS en https://console.aws.amazon.com/eks/home#/clusters.

  2. Seleccione el clúster.

  3. Elija la pestaña Complementos.

  4. Compruebe que el complemento de SageMaker HyperPod observabilidad aparezca en la lista y que su estado sea ACTIVO.

  5. Si el estado no es ACTIVE, consulte Solución de errores al instalar el complemento.

Verificación de la asociación de Pod Identity

  1. Abra la consola Amazon EKS en https://console.aws.amazon.com/eks/home#/clusters.

  2. Seleccione el clúster.

  3. En la página Detalles del clúster, seleccione la pestaña Acceso.

  4. En la tabla Asociaciones de Pod Identity, elija la asociación que tenga los siguientes valores de propiedad:

    • Espacio de nombres: hyperpod-observability

    • Cuenta de servicio: hyperpod-observability-operator-otel-collector

    • Complemento: amazon-sagemaker-hyperpod-observability

  5. Asegúrese de que el rol de IAM vinculado a esta asociación tenga los siguientes permisos.

    JSON
    { "Version":"2012-10-17", "Statement": [ { "Sid": "PrometheusAccess", "Effect": "Allow", "Action": "aps:RemoteWrite", "Resource": "arn:aws:aps:us-east-1:111122223333:workspace/workspace-ID" }, { "Sid": "CloudwatchLogsAccess", "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:DescribeLogGroups", "logs:DescribeLogStreams", "logs:PutLogEvents", "logs:GetLogEvents", "logs:FilterLogEvents", "logs:GetLogRecord", "logs:StartQuery", "logs:StopQuery", "logs:GetQueryResults" ], "Resource": [ "arn:aws:logs:us-east-1:111122223333:log-group:/aws/sagemaker/Clusters/*", "arn:aws:logs:us-east-1:111122223333:log-group:/aws/sagemaker/Clusters/*:log-stream:*" ] } ] }
  6. Asegúrese de que el rol de IAM vinculado a esta asociación tenga la siguiente política de confianza. Compruebe que el ARN de origen y la cuenta de origen sean correctos.

    JSON
    { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowEksAuthToAssumeRoleForPodIdentity", "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ], "Condition": { "StringEquals": { "aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:cluster/cluster-name", "aws:SourceAccount": "111122223333" } } } ] }

Verificación de la limitación de Amazon Managed Service para Prometheus

  1. Inicie sesión en la consola Service Quotas Consola de administración de AWS y ábrala en https://console.aws.amazon.com/servicequotas/.

  2. En el cuadro Cuotas administradas, busque y seleccione Amazon Managed Service para Prometheus.

  3. Elige la cuota Serie activa por espacio de trabajo.

  4. En la pestaña Cuotas a nivel de recurso, seleccione el espacio de trabajo de Amazon Managed Service para Prometheus.

  5. Asegúrese de que la utilización sea inferior a la cuota actual.

  6. Si ha alcanzado el límite de cuota, seleccione su espacio de trabajo pulsando el botón de opción situado a la izquierda y, a continuación, elija Solicitud de aumento a nivel de recursos.

Compruebe que el almacenamiento en caché KV y el enrutamiento inteligente estén habilitados

Si falta el KVCache Metrics panel de control, la función no está habilitada o el puerto no se menciona en el. modelMetrics Para obtener más información sobre cómo activarlo, consulta los pasos 1 y 3 deConfigure el almacenamiento en caché KV y el enrutamiento inteligente para mejorar el rendimiento.

Si falta el Intelligent Router Metrics panel de control, active la función para que aparezcan. Para obtener más información sobre cómo habilitar esto, consulteConfigure el almacenamiento en caché KV y el enrutamiento inteligente para mejorar el rendimiento.

Solución de errores al instalar el complemento

Si el complemento de observabilidad no se instala, siga estos pasos para diagnosticar y resolver el problema.

Comprobación del estado de la sonda

  1. Abra la consola Amazon EKS en https://console.aws.amazon.com/eks/home#/clusters.

  2. Seleccione el clúster.

  3. Elija la pestaña Complementos.

  4. Seleccione el complemento que ha fallado.

  5. Consulte la sección Problemas de estado.

  6. Si el problema de estado está relacionado con las credenciales o Pod Identity, consulte Verificación de la asociación de Pod Identity. Asegúrese también de que el complemento del agente de Pod Identity se esté ejecutando en el clúster.

  7. Compruebe si hay errores en los registros del administrador. Para obtener instrucciones, consulte Consulta de los registros del administrador.

  8. Póngase en contacto con AWS Support con los detalles del problema.

Consulta de los registros del administrador

  1. Obtención del pod del administrador de complementos:

    kubectl logs -n hyperpod-observability -l control-plane=hyperpod-observability-controller-manager
  2. Si tiene problemas urgentes, póngase en contacto con Soporte.

Consulta de todos los pods de observabilidad

Todos los módulos que crea el complemento de SageMaker HyperPod observabilidad están en el hyperpod-observability espacio de nombres. Ejecute el siguiente comando para obtener el estado de estos pods.

kubectl get pods -n hyperpod-observability

Busque los pods cuyo estado sea pending o crashloopbackoff. Ejecute el siguiente comando para obtener los registros de estos pods pendientes o fallidos.

kubectl logs -n hyperpod-observability pod-name

Si no encuentra errores en los registros, ejecute el siguiente comando para describir los pods y buscar errores.

kubectl describe -n hyperpod-observability pod pod-name

Para obtener más contexto, ejecute los dos comandos siguientes para describir las implementaciones y los daemonsets de estos pods.

kubectl describe -n hyperpod-observability deployment deployment-name
kubectl describe -n hyperpod-observability daemonset daemonset-name

Solución de problemas de los pods que están bloqueados con el estado pendiente

Si ve que hay pods bloqueados con el estado pending, asegúrese de que el nodo sea suficientemente grande para que quepa en todos los pods. Para comprobarlo, realice los siguientes pasos.

  1. Abra la consola Amazon EKS en https://console.aws.amazon.com/eks/home#/clusters.

  2. Elija su clúster.

  3. Elija la pestaña Computación del clúster.

  4. Elija el nodo con el tipo de instancia más pequeño.

  5. En la sección de asignación de capacidad, busque los pods disponibles.

  6. Si no hay pods disponibles, necesitará un tipo de instancia más grande.

Si tiene problemas urgentes, póngase en contacto con AWS Support.

Solución de problemas de observabilidad en grupos de instancias restringidos

Usa la siguiente guía para resolver problemas específicos de los clústeres con grupos de instancias restringidos.

Los módulos de observabilidad no se inician en los nodos restringidos

Si los módulos de observabilidad no se inician en los nodos restringidos, compruebe el estado y los eventos del módulo:

kubectl get pods -n hyperpod-observability -o wide kubectl describe pod pod-name -n hyperpod-observability

Entre las causas comunes, se incluyen las siguientes:

  • Fallos de extracción de imágenes: los eventos del módulo pueden mostrar errores de extracción de imágenes si las imágenes del contenedor de observabilidad aún no están incluidas en la lista de permitidos en los nodos restringidos. Asegúrese de que está ejecutando la última versión del complemento de observabilidad. Si el problema persiste después de la actualización, ponte en contacto con Soporte.

  • Tolerancias a la contaminación: compruebe que las especificaciones del módulo incluyan la tolerancia requerida para los nodos restringidos. El complemento, a partir de la versión, añade v1.0.5-eksbuild.1 automáticamente esta tolerancia cuando se habilita la compatibilidad con RIG. Si está utilizando una versión anterior, actualice a la última versión.

Visualización de los registros de los pods en los nodos restringidos

El kubectl logs comando no funciona para los pods que se ejecutan en nodos restringidos. Esta es una limitación esperada, ya que la ruta de comunicación necesaria para la transmisión de registros no está disponible en los nodos restringidos.

Para ver los registros de los nodos restringidos, utilice el panel Cluster Logs de Amazon Managed Grafana, que consulta CloudWatch los registros directamente. Puede filtrar por ID de instancia, flujo de registro, nivel de registro y búsqueda de texto libre para encontrar las entradas de registro relevantes.

Fallos de resolución de DNS en clústeres con nodos estándar y restringidos

En los clústeres híbridos (clústeres con grupos de instancias estándar y restringidos), los pods de los nodos estándar pueden experimentar tiempos de espera de resolución de DNS al intentar llegar a puntos de enlace de AWS servicio, como Amazon Managed Service for Prometheus o. CloudWatch

Causa: el kube-dns servicio tiene puntos de conexión tanto de pods de CoreDNS estándar como de pods de CoreDNS de RIG. Los pods de nodos estándar no pueden llegar a los puntos finales de RIG CoredNS debido al aislamiento de la red. Cuando se kube-proxy equilibra la carga de una solicitud de DNS desde un pod de nodo estándar a un punto final de RIG CoreDNS, se agota el tiempo de espera de la solicitud.

Solución: internalTrafficPolicy: Local configúrelo en el kube-dns servicio de modo que los pods solo lleguen a CoredNS en su nodo local:

kubectl patch svc kube-dns -n kube-system -p '{"spec":{"internalTrafficPolicy":"Local"}}'

Tras aplicar este parche, reinicie los módulos de observabilidad afectados:

kubectl delete pods -n hyperpod-observability -l app.kubernetes.io/name=hyperpod-node-collector

Las métricas de los nodos restringidos no llegan a Amazon Managed Service para Prometheus

Si las métricas de los nodos restringidos no aparecen en tu espacio de trabajo de Amazon Managed Service for Prometheus:

  1. Compruebe los permisos de la función de ejecución. Asegúrese de que el rol de ejecución del grupo de instancias restringido tenga aps:RemoteWrite permiso para su espacio de trabajo de Prometheus. Para obtener más información, consulte Requisitos previos adicionales para los grupos de instancias restringidos.

  2. Compruebe el estado del pod del recopilador de nodos. Ejecute el siguiente comando y compruebe que los pods del recopilador de nodos se estén ejecutando en nodos restringidos:

    kubectl get pods -n hyperpod-observability | grep node-collector
  3. Compruebe las implementaciones del recopilador central. En los clústeres con nodos restringidos, el complemento implementa un recopilador central por límite de red. Compruebe que existe un recopilador central para cada límite:

    kubectl get deployments -n hyperpod-observability | grep central-collector
  4. Compruebe si hay errores en los eventos del pod. kubectl describeUtilízalo en los módulos recopiladores para buscar eventos de error:

    kubectl describe pod collector-pod-name -n hyperpod-observability

Si el problema persiste después de verificar lo anterior, ponte en contacto con nosotros Soporte.

La verificación de identidad del pod no se aplica a los nodos de grupos de instancias restringidos

Los pasos Verificación de la asociación de Pod Identity de solución de problemas solo se aplican a los nodos estándar. En los nodos restringidos, el complemento utiliza la función de ejecución del grupo de instancias del clúster para la AWS autenticación en lugar de Amazon EKS Pod Identity. Si faltan métricas en los nodos restringidos, verifica los permisos de la función de ejecución en lugar de la asociación de Pod Identity.

Fluent Bit no se ejecuta en nodos restringidos

Este es el comportamiento esperado. Fluent Bit no se implementa intencionalmente en nodos restringidos. Los registros de los nodos restringidos se publican a CloudWatch través de la SageMaker HyperPod plataforma independientemente del complemento de observabilidad. Utilice el panel de registros de clústeres de Amazon Managed Grafana para ver estos registros.