View a markdown version of this page

Résolution des problèmes liés au module complémentaire SageMaker HyperPod d'observabilité Amazon - Amazon SageMaker AI
Métriques manquantesÉchecs d’installation du module complémentaireExamen de tous les pods d’observabilitéPods bloqués en attenteRésolution des problèmes d'observabilité sur les groupes d'instances restreints

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Résolution des problèmes liés au module complémentaire SageMaker HyperPod d'observabilité Amazon

Suivez les instructions suivantes pour résoudre les problèmes courants liés au module complémentaire d'observabilité Amazon SageMaker HyperPod (SageMaker HyperPod).

Résolution du problème de métriques manquantes dans Amazon Managed Grafana

Si les statistiques n’apparaissent pas dans vos tableaux de bord Amazon Managed Grafana, effectuez les étapes suivantes pour identifier et résoudre le problème.

Vérification de la connexion du service géré Amazon pour Prometheus et d’Amazon Managed Grafana

  1. Connectez-vous à la console Amazon Managed Grafana.

  2. Dans le volet de gauche, choisissez Tous les espaces de travail.

  3. Dans le tableau Espaces de travail, choisissez votre espace de travail.

  4. Sur la page de détails de l’espace de travail, choisissez l’onglet Sources de données.

  5. Vérifiez que la source de données Service géré Amazon pour Prometheus existe.

  6. Vérifiez les paramètres de connexion :

    • Confirmez que l’URL du point de terminaison est correcte.

    • Vérifiez que l’authentification IAM est correctement configurée.

    • Choisissez Test connection (Tester la connexion). Vérifiez que le statut est La source de données fonctionne.

Vérification du statut du module complémentaire Amazon EKS

  1. Ouvrez la console Amazon EKS à l'adresse https://console.aws.amazon.com/eks/home#/clusters.

  2. Sélectionnez votre cluster.

  3. Choisissez l’onglet Modules complémentaires.

  4. Vérifiez que le module complémentaire SageMaker HyperPod d'observabilité est répertorié et que son statut est ACTIF.

  5. Si le statut n’est pas ACTIF, consultez Résolution des échecs d’installation du module complémentaire.

Vérification de l’association d’identité du pod

  1. Ouvrez la console Amazon EKS à l'adresse https://console.aws.amazon.com/eks/home#/clusters.

  2. Sélectionnez votre cluster.

  3. Sur la page de détails du cluster, choisissez l’onglet Accès.

  4. Dans le tableau Associations d’identité du pod, choisissez l’association dont les valeurs de propriété sont les suivantes :

    • Espace de noms : hyperpod-observability

    • Compte de service : hyperpod-observability-operator-otel-collector

    • Module complémentaire : amazon-sagemaker-hyperpod-observability

  5. Assurez-vous que le rôle IAM attaché à cette association dispose des autorisations suivantes.

    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. Assurez-vous que le rôle IAM attaché à cette association possède la politique d’approbation suivante. Vérifiez que l’ARN source et le compte source sont corrects.

    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"
                }
            }
        }
    ]
}

Vérification de la limitation du service géré Amazon pour Prometheus

  1. Connectez-vous à la console Service Quotas AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/servicequotas/.

  2. Dans la zone Quotas gérés, recherchez et sélectionnez le service géré Amazon pour Prometheus.

  3. Choisissez le quota Série active par espace de travail.

  4. Dans l’onglet Quotas au niveau des ressources, sélectionnez votre espace de travail Service géré Amazon pour Prometheus.

  5. Assurez-vous que l’utilisation est inférieure à votre quota actuel.

  6. Si vous avez atteint la limite de quota, sélectionnez votre espace de travail en choisissant la case d’option située à sa gauche, puis choisissez Demander une augmentation au niveau des ressources.

Vérifiez que la mise en cache KV et le routage intelligent sont activés

Si le KVCache Metrics tableau de bord est absent, la fonctionnalité n'est pas activée ou le port n'est pas mentionné dans lemodelMetrics. Pour plus d'informations sur la façon de l'activer, reportez-vous aux étapes 1 et 3 deConfigurer la mise en cache KV et le routage intelligent pour améliorer les performances.

Si le Intelligent Router Metrics tableau de bord est absent, activez la fonctionnalité pour qu'ils apparaissent. Pour plus d'informations sur la façon de l'activer, consultezConfigurer la mise en cache KV et le routage intelligent pour améliorer les performances.

Résolution des échecs d’installation du module complémentaire

Si le module complémentaire d’observabilité ne s’installe pas, suivez les étapes ci-dessous pour diagnostiquer et résoudre le problème.

Vérification du statut de vérification de l’état

  1. Ouvrez la console Amazon EKS à l'adresse https://console.aws.amazon.com/eks/home#/clusters.

  2. Sélectionnez votre cluster.

  3. Choisissez l’onglet Modules complémentaires.

  4. Choisissez le module complémentaire qui a échoué.

  5. Examinez la section Problèmes de santé.

  6. Si le problème d’état est lié aux informations d’identification ou à l’identité du pod, consultez Vérification de l’association d’identité du pod. Assurez-vous également que le module complémentaire d’agent d’identité du pod est en cours d’exécution dans le cluster.

  7. Recherchez des erreurs dans les journaux du gestionnaire. Pour obtenir des instructions, veuillez consulter Examen des journaux du gestionnaire.

  8. Contactez le AWS Support pour obtenir les détails du problème.

Examen des journaux du gestionnaire

  1. Obtenez le pod de gestion du module complémentaire :

    kubectl logs -n hyperpod-observability -l control-plane=hyperpod-observability-controller-manager

  2. Pour des problèmes urgents, contactez Support.

Examen de tous les pods d’observabilité

Tous les pods créés par le module complémentaire SageMaker HyperPod d'observabilité se trouvent dans l'espace de hyperpod-observability noms. Pour obtenir le statut de ces pods, exécutez la commande suivante.

kubectl get pods -n hyperpod-observability

Recherchez les pods dont le statut est pending ou crashloopbackoff. Exécutez la commande suivante pour obtenir les journaux de ces pods en attente ou défaillants.

kubectl logs -n hyperpod-observability pod-name

Si vous ne trouvez aucune erreur dans les journaux, exécutez la commande suivante pour décrire les pods et rechercher des erreurs.

kubectl describe -n hyperpod-observability pod pod-name

Pour obtenir plus de contexte, exécutez les deux commandes suivantes pour décrire les déploiements et les daemonsets de ces pods.

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

Résolution des problèmes liés aux pods bloqués avec le statut En attente

Si vous constatez que certains pods sont bloqués avec le statut pending, assurez-vous que le nœud est suffisamment grand pour contenir tous les pods. Pour vérifier cela, effectuez les opérations suivantes.

  1. Ouvrez la console Amazon EKS à l'adresse https://console.aws.amazon.com/eks/home#/clusters.

  2. Choisissez votre cluster.

  3. Choisissez l’onglet Calcul du cluster.

  4. Choisissez le nœud avec le plus petit type d’instance.

  5. Dans la section d’allocation de capacité, recherchez les pods disponibles.

  6. Si aucun pod n’est disponible, vous avez besoin d’un type d’instance plus grand.

Pour des problèmes urgents, contactez AWS Support.

Résolution des problèmes d'observabilité sur les groupes d'instances restreints

Suivez les instructions suivantes pour résoudre les problèmes spécifiques aux clusters dotés de groupes d'instances restreints.

Les pods d'observabilité ne démarrent pas sur des nœuds restreints

Si les pods d'observabilité ne démarrent pas sur des nœuds restreints, vérifiez l'état et les événements du pod :

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

Les causes courantes incluent :

  • Échec de l'extraction d'images : les événements du pod peuvent provoquer des erreurs d'extraction d'images si les images du conteneur d'observabilité ne sont pas encore autorisées sur les nœuds restreints. Assurez-vous que vous utilisez la dernière version du module complémentaire d'observabilité. Si le problème persiste après la mise à niveau, contactez Support.

  • Tolérances d'altération : vérifiez que les spécifications du pod incluent la tolérance requise pour les nœuds restreints. Le module complémentaire à partir de la version ajoute v1.0.5-eksbuild.1 automatiquement cette tolérance lorsque le support RIG est activé. Si vous utilisez une ancienne version, veuillez passer à la dernière version.

Afficher les journaux des pods sur des nœuds restreints

La kubectl logs commande ne fonctionne pas pour les pods exécutés sur des nœuds restreints. Il s'agit d'une limitation attendue car le chemin de communication requis pour le streaming des journaux n'est pas disponible sur les nœuds restreints.

Pour consulter les journaux provenant de nœuds restreints, utilisez le tableau de bord Cluster Logs d'Amazon Managed Grafana, qui interroge directement CloudWatch les journaux. Vous pouvez filtrer par ID d'instance, flux de journal, niveau de journal et recherche en texte libre pour trouver les entrées de journal pertinentes.

Défaillances de résolution DNS dans les clusters comportant à la fois des nœuds standard et restreints

Dans les clusters hybrides (clusters comprenant à la fois des groupes d'instances standard et restreints), les pods des nœuds standard peuvent rencontrer des délais de résolution DNS lorsqu'ils tentent d'atteindre des points de terminaison de AWS service tels qu'Amazon Managed Service for Prometheus ou. CloudWatch

Cause : Le kube-dns service possède des points de terminaison provenant à la fois de pods CoreDNS standard et de pods RIG CoreDNS. Les pods de nœuds standard ne peuvent pas atteindre les points de terminaison RIG CoreDNS en raison de l'isolation du réseau. Lorsque la kube-proxy charge d'une requête DNS d'un pod de nœuds standard est équilibrée vers un point de terminaison RIG CoreDNS, la demande expire.

Résolution : configurez internalTrafficPolicy: Local le kube-dns service de manière à ce que les pods n'atteignent CoreDNS que sur leur nœud local :

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

Après avoir appliqué ce correctif, redémarrez les modules d'observabilité concernés :

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

Les métriques provenant de nœuds restreints n'atteignent pas Amazon Managed Service for Prometheus

Si les statistiques des nœuds restreints n'apparaissent pas dans votre espace de travail Amazon Managed Service for Prometheus :

  1. Vérifiez les autorisations du rôle d'exécution. Assurez-vous que le rôle d'exécution du groupe d'instances restreint est aps:RemoteWrite autorisé à accéder à votre espace de travail Prometheus. Pour de plus amples informations, veuillez consulter Conditions préalables supplémentaires pour les groupes d'instances restreints.

  2. Vérifiez l'état du pod du collecteur de nœuds. Exécutez la commande suivante et vérifiez que les pods du collecteur de nœuds s'exécutent sur des nœuds restreints :

    kubectl get pods -n hyperpod-observability | grep node-collector

  3. Vérifiez les déploiements du collecteur central. Dans les clusters dotés de nœuds restreints, le module complémentaire déploie un collecteur central par limite de réseau. Vérifiez qu'il existe un collecteur central pour chaque limite :

    kubectl get deployments -n hyperpod-observability | grep central-collector

  4. Vérifiez les événements du pod pour détecter les erreurs. kubectl describeÀ utiliser sur les pods du collecteur pour rechercher les événements d'erreur :

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

Si le problème persiste après avoir vérifié ce qui précède, contactez Support.

La vérification de l'identité du pod ne s'applique pas aux nœuds de groupes d'instances restreints

Les étapes Vérification de l’association d’identité du pod de résolution des problèmes s'appliquent uniquement aux nœuds standard. Sur les nœuds restreints, le module complémentaire utilise le rôle d'exécution du groupe d'instances de cluster pour AWS l'authentification au lieu d'Amazon EKS Pod Identity. Si les métriques sont absentes des nœuds restreints, vérifiez les autorisations du rôle d'exécution plutôt que l'association Pod Identity.

Fluent Bit ne fonctionne pas sur des nœuds restreints

Ce comportement est normal. Fluent Bit n'est intentionnellement pas déployé sur des nœuds restreints. Les journaux des nœuds restreints sont publiés CloudWatch sur la SageMaker HyperPod plateforme indépendamment du module complémentaire d'observabilité. Utilisez le tableau de bord Cluster Logs d'Amazon Managed Grafana pour consulter ces journaux.