View a markdown version of this page

Fehlerbehebung beim Amazon SageMaker HyperPod Observability Add-on - Amazon SageMaker KI
Fehlende MetrikenFehler bei der Installation von Add-onsÜberprüfen Sie alle Observability-PodsPods bleiben im Status „Ausstehend“Fehlerbehebung bei der Observability bei eingeschränkten Instance-Gruppen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Fehlerbehebung beim Amazon SageMaker HyperPod Observability Add-on

Verwenden Sie die folgenden Anleitungen, um häufig auftretende Probleme mit dem Amazon SageMaker HyperPod (SageMaker HyperPod) Observability-Add-on zu lösen.

Behebung fehlender Metriken in Amazon Managed Grafana

Wenn Metriken nicht in Ihren Amazon Managed Grafana-Dashboards angezeigt werden, führen Sie die folgenden Schritte aus, um das Problem zu identifizieren und zu lösen.

Überprüfen Sie die Verbindung zwischen Amazon Managed Service für Prometheus und Amazon Managed Grafana

  1. Melden Sie sich bei der Amazon Managed Grafana-Konsole an.

  2. Wählen Sie im linken Bereich Alle Arbeitsbereiche aus.

  3. Wählen Sie in der Tabelle WorkBereiche Ihren Workspace aus.

  4. Wählen Sie auf der Detailseite des Workspace den Tab Datenquellen aus.

  5. Stellen Sie sicher, dass die Datenquelle von Amazon Managed Service für Prometheus vorhanden ist.

  6. Überprüfen Sie die Verbindungseinstellungen:

    • Vergewissern Sie sich, dass die Endpunkt-URL korrekt ist.

    • Stellen Sie sicher, dass die IAM-Authentifizierung ordnungsgemäß konfiguriert ist.

    • Wählen Sie Test connection (Verbindung testen) aus. Stellen Sie sicher, dass der Status „Datenquelle funktioniert“ lautet.

Überprüfen Sie den Amazon-EKS-Add-on-Status

  1. Öffnen Sie die Amazon EKS-Konsole unter https://console.aws.amazon.com/eks/home#/clusters.

  2. Wählen Sie Ihren Cluster aus.

  3. Wählen Sie die Registerkarte Add-ons.

  4. Vergewissern Sie sich, dass das SageMaker HyperPod Observability-Add-on aufgeführt ist und dass sein Status AKTIV ist.

  5. Wenn der Status nicht ACTIVE ist, siehe Behebung von Fehlern bei der Installation von Add-ons.

Überprüfen Sie die Pod-Identity-Zuordnung

  1. Öffnen Sie die Amazon EKS-Konsole unter https://console.aws.amazon.com/eks/home#/clusters.

  2. Wählen Sie Ihren Cluster aus.

  3. Wählen Sie auf der Seite mit den Cluster-Details die Registerkarte Zugriff.

  4. Wählen Sie in der Tabelle mit den Pod-Identity-Zuordnungen die Zuordnung aus, die die folgenden Eigenschaftswerte hat:

    • Namespace: hyperpod-observability

    • Servicekonto: hyperpod-observability-operator-otel-collector

    • Add-on: amazon-sagemaker-hyperpod-observability

  5. Stellen Sie sicher, dass die IAM-Rolle, die dieser Zuordnung zugeordnet ist, über die folgenden Berechtigungen verfügt.

    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. Stellen Sie sicher, dass für die IAM-Rolle, die dieser Zuordnung zugeordnet ist, die folgende Vertrauensrichtlinie definiert ist. Stellen Sie sicher, dass der Quell-ARN und das Quellkonto korrekt sind.

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

Überprüfen Sie die Drosselung von Prometheus bei Amazon Managed Service

  1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Service Quotas Quotas-Konsole unter https://console.aws.amazon.com/servicequotas/.

  2. Suchen Sie im Feld Verwaltete Kontingente nach Amazon Managed Service for Prometheus und wählen Sie es aus.

  3. Wählen Sie das Kontingent der Active-Serie pro Workspace aus.

  4. Wählen Sie auf der Registerkarte Kontingente auf Ressourcenebene Ihren Workspace in Amazon Managed Service für Prometheus aus.

  5. Stellen Sie sicher, dass die Auslastung unter Ihrem aktuellen Kontingent liegt.

  6. Wenn du das Kontingentlimit erreicht hast, wähle deinen Workspace aus, indem du das Optionsfeld links davon auswählst und dann Erhöhung auf Ressourcenebene beantragen auswählst.

Stellen Sie sicher, dass KV-Caching und intelligentes Routing aktiviert sind

Wenn das KVCache Metrics Dashboard fehlt, ist die Funktion entweder nicht aktiviert oder der Port wird in der modelMetrics nicht erwähnt. Weitere Informationen zur Aktivierung finden Sie in den Schritten 1 und 3 unterKonfigurieren Sie KV-Caching und intelligentes Routing für eine verbesserte Leistung.

Wenn das Intelligent Router Metrics Dashboard fehlt, aktivieren Sie die Funktion, damit sie angezeigt werden. Weitere Informationen zur Aktivierung dieser Funktion finden Sie unterKonfigurieren Sie KV-Caching und intelligentes Routing für eine verbesserte Leistung.

Behebung von Fehlern bei der Installation von Add-ons

Wenn das Observability-Add-on nicht installiert werden kann, gehen Sie wie folgt vor, um das Problem zu diagnostizieren und zu beheben.

Überprüfen Sie den Status der Gesundheitsprüfung

  1. Öffnen Sie die Amazon EKS-Konsole unter https://console.aws.amazon.com/eks/home#/clusters.

  2. Wählen Sie Ihren Cluster aus.

  3. Wählen Sie die Registerkarte Add-ons.

  4. Wählen Sie das fehlgeschlagene Add-on aus.

  5. Lesen Sie den Abschnitt Gesundheitsprobleme.

  6. Wenn das Gesundheitsproblem mit Anmeldeinformationen oder der Pod-Identität zusammenhängt, finden Sie weitere Informationen unterÜberprüfen Sie die Pod-Identity-Zuordnung. Stellen Sie außerdem sicher, dass das Pod Identity Agent-Add-on im Cluster ausgeführt wird.

  7. Suchen Sie in den Manager-Protokollen nach Fehlern. Detaillierte Anweisungen finden Sie unter Überprüfen von Manager-Protokollen.

  8. Wenden Sie sich mit den Problemdetails an den AWS Support.

Überprüfen von Manager-Protokollen

  1. Holen Sie sich den Add-On-Manager-Pod:

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

  2. Bei dringenden Problemen wenden Sie sich an Support.

Überprüfen Sie alle Observability-Pods

Alle Pods, die das SageMaker HyperPod Observability-Add-on erstellt, befinden sich im hyperpod-observability Namespace. Um den Status dieser Pods abzurufen, führen Sie den folgenden Befehl aus.

kubectl get pods -n hyperpod-observability

Suchen Sie nach den Pods, deren Status entweder pending oder crashloopbackoff ist. Führen Sie den folgenden Befehl aus, um die Protokolle dieser ausstehenden oder fehlgeschlagenen Pods abzurufen.

kubectl logs -n hyperpod-observability pod-name

Wenn Sie in den Protokollen keine Fehler finden, führen Sie den folgenden Befehl aus, um die Pods zu beschreiben und nach Fehlern zu suchen.

kubectl describe -n hyperpod-observability pod pod-name

Um mehr Kontext zu erhalten, führen Sie die beiden folgenden Befehle aus, um die Bereitstellungen und Daemonsets für diese Pods zu beschreiben.

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

Problembehandlung bei Pods, die im Status „Ausstehend“ hängen bleiben

Wenn Sie feststellen, dass Pods mit dem pending Status „hängengeblieben“ sind, stellen Sie sicher, dass der Knoten groß genug ist, um in alle Pods zu passen. Führen Sie die folgenden Schritte aus, um zu überprüfen, ob dies der Fall ist.

  1. Öffnen Sie die Amazon EKS-Konsole unter https://console.aws.amazon.com/eks/home#/clusters.

  2. Wählen Sie Ihren Cluster aus.

  3. Wählen Sie die Registerkarte Compute des Clusters aus.

  4. Wählen Sie den Knoten mit dem kleinsten Instance-Typ aus.

  5. Suchen Sie im Bereich Kapazitätszuweisung nach verfügbaren Pods.

  6. Wenn keine Pods verfügbar sind, benötigen Sie einen größeren Instance-Typ.

Bei dringenden Problemen wenden Sie sich an AWS Support.

Fehlerbehebung bei der Observability bei eingeschränkten Instance-Gruppen

Verwenden Sie die folgenden Anleitungen, um Probleme zu lösen, die sich speziell auf Cluster mit eingeschränkten Instanzgruppen beziehen.

Observability-Pods starten nicht auf eingeschränkten Knoten

Wenn Observability-Pods nicht auf eingeschränkten Knoten gestartet werden, überprüfen Sie den Pod-Status und die Ereignisse:

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

Zu den häufigsten Ursachen gehören:

  • Fehler beim Abrufen von Bildern: Bei den Pod-Ereignissen können Fehler beim Abrufen von Bildern auftreten, wenn die Observability-Container-Images auf den eingeschränkten Knoten noch nicht zugelassen sind. Stellen Sie sicher, dass Sie die neueste Version des Observability-Add-ons ausführen. Wenn das Problem nach dem Upgrade weiterhin besteht, wenden Sie sich an. Support

  • Toleranzen vor schädlichen Einflüssen: Stellen Sie sicher, dass die Pod-Spezifikation die erforderlichen Toleranzen für eingeschränkte Knoten enthält. Ab der Version fügt das Add-on diese Toleranz v1.0.5-eksbuild.1 automatisch hinzu, wenn die RIG-Unterstützung aktiviert ist. Wenn Sie eine ältere Version verwenden, aktualisieren Sie bitte auf die neueste Version.

Protokolle für Pods auf eingeschränkten Knoten anzeigen

Der kubectl logs Befehl funktioniert nicht für Pods, die auf eingeschränkten Knoten ausgeführt werden. Dies ist eine zu erwartende Einschränkung, da der für das Protokollstreaming erforderliche Kommunikationspfad auf eingeschränkten Knoten nicht verfügbar ist.

Um Protokolle von eingeschränkten Knoten anzuzeigen, verwenden Sie das Cluster-Logs-Dashboard in Amazon Managed Grafana, das CloudWatch Protokolle direkt abfragt. Sie können nach Instance-ID, Protokollstream, Protokollebene und Freitextsuche filtern, um relevante Protokolleinträge zu finden.

Fehler bei der DNS-Auflösung in Clustern mit sowohl Standardknoten als auch eingeschränkten Knoten

In Hybrid-Clustern (Clustern mit sowohl standardmäßigen als auch eingeschränkten Instance-Gruppen) kann es bei Pods auf Standardknoten zu Timeouts bei der DNS-Auflösung kommen, wenn versucht wird, AWS Service-Endpunkte wie Amazon Managed Service for Prometheus oder zu erreichen. CloudWatch

Ursache: Der kube-dns Dienst hat Endpunkte sowohl von Standard-CoreDNS-Pods als auch von RIG-CoreDNS-Pods. Standard-Node-Pods können RIG CoreDNS-Endpunkte aufgrund der Netzwerkisolierung nicht erreichen. Beim kube-proxy Lastenausgleich einer DNS-Anfrage von einem Standardknoten-Pod zu einem RIG-CoreDNS-Endpunkt kommt es bei der Anfrage zu einem Timeout.

Lösung: Stellen Sie internalTrafficPolicy: Local den kube-dns Dienst so ein, dass Pods nur CoreDNS auf ihrem lokalen Knoten erreichen:

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

Starten Sie nach der Installation dieses Patches die betroffenen Observability-Pods neu:

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

Metriken von eingeschränkten Knoten, die Amazon Managed Service for Prometheus nicht erreichen

Wenn Metriken von eingeschränkten Knoten nicht in Ihrem Amazon Managed Service for Prometheus-Workspace angezeigt werden:

  1. Überprüfen Sie die Berechtigungen für die Ausführungsrolle. Stellen Sie sicher, dass die Ausführungsrolle für die eingeschränkte Instanzgruppe über aps:RemoteWrite Berechtigungen für Ihren Prometheus-Workspace verfügt. Weitere Informationen finden Sie unter Zusätzliche Voraussetzungen für eingeschränkte Instanzgruppen.

  2. Überprüfen Sie den Pod-Status des Node Collector. Führen Sie den folgenden Befehl aus und stellen Sie sicher, dass Node Collector-Pods auf eingeschränkten Knoten ausgeführt werden:

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

  3. Überprüfen Sie die Central Collector-Bereitstellungen. In Clustern mit eingeschränkten Knoten stellt das Add-On einen Central Collector pro Netzwerkgrenze bereit. Stellen Sie sicher, dass für jede Grenze ein zentraler Collector vorhanden ist:

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

  4. Überprüfen Sie die Pod-Ereignisse auf Fehler. Verwenden Sie kubectl describe auf den Collector-Pods, um nach Fehlerereignissen zu suchen:

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

Wenn das Problem nach der Überprüfung der oben genannten Punkte weiterhin besteht, wenden Sie sich an. Support

Die Überprüfung der Pod-Identität gilt nicht für eingeschränkte Instanzgruppenknoten

Die Schritte Überprüfen Sie die Pod-Identity-Zuordnung zur Fehlerbehebung gelten nur für Standardknoten. Auf eingeschränkten Knoten verwendet das Add-on die Cluster-Instance-Gruppenausführungsrolle für die AWS Authentifizierung anstelle von Amazon EKS Pod Identity. Wenn Metriken für eingeschränkte Knoten fehlen, überprüfen Sie die Berechtigungen für die Ausführungsrolle und nicht die Pod Identity-Zuordnung.

Fluent Bit läuft nicht auf eingeschränkten Knoten

Dieses Verhalten wird erwartet. Fluent Bit wird bewusst nicht auf eingeschränkten Knoten eingesetzt. Protokolle von eingeschränkten Knoten werden unabhängig vom SageMaker HyperPod Observability-Add-on CloudWatch über die Plattform veröffentlicht. Verwenden Sie das Cluster-Logs-Dashboard in Amazon Managed Grafana, um diese Protokolle einzusehen.