View a markdown version of this page

Fehlerbehebung beim Amazon Observability-Add-on SageMaker HyperPod - Amazon SageMaker KI
Fehlende MetrikenAdd-on Fehler bei der InstallationÜberprüfen Sie alle Observability-PodsPods bleiben im Status „Ausstehend“Fehlerbehebung bei Observability bei eingeschränkten Instanzgruppen

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 Observability-Add-on SageMaker HyperPod

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 zu Amazon Managed Service for Prometheus-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 aus.

  4. Stellen Sie sicher, 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 Quota-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 im Tab Resource-level Kontingente Ihren Amazon Managed Service for Prometheus-Workspace 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 im modelMetrics nicht erwähnt. Weitere Informationen zur Aktivierung finden Sie in den Schritten 1 und 3 unterKonfigurieren Sie KV-Caching und intelligentes Routing.

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.

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 aus.

  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 Einzelheiten zum Problem 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 Observability bei eingeschränkten Instanzgruppen

Verwenden Sie die folgenden Anleitungen, um Probleme zu lösen, die speziell auf Cluster mit eingeschränkten Instanzgruppen zurückzuführen sind.

Observability-Pods starten nicht auf eingeschränkten Knoten

Wenn Observability-Pods nicht auf eingeschränkten Knoten starten, ü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 kann es zu Fehlern beim Abrufen von Bildern kommen, 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

  • Taint-Toleranzen: Stellen Sie sicher, dass die Pod-Spezifikation die erforderliche Toleranz für eingeschränkte Knoten enthält. Das Add-on fügt diese Toleranz ab Version 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 erwartete Einschränkung, da der für das Log-Streaming erforderliche Kommunikationspfad auf eingeschränkten Knoten nicht verfügbar ist.

Verwenden Sie das Cluster Logs-Dashboard in Amazon Managed Grafana, das Protokolle direkt abfragt, um CloudWatch Protokolle von eingeschränkten Knoten einzusehen. Sie können nach Instanz-ID, Log-Stream, Log-Level und Freitextsuche filtern, um relevante Logeinträge zu finden.

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

In Hybridclustern (Clustern mit sowohl standardmäßigen als auch eingeschränkten Instanzgruppen) kann es bei Pods auf Standardknoten zu Timeouts bei der DNS-Auflösung kommen, wenn versucht wird, AWS Service-Endpunkte wie Amazon Managed Service für 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 aufgrund der Netzwerkisolierung keine RIG CoreDNS-Endpunkte erreichen. Beim kube-proxy Lastenausgleich einer DNS-Anfrage von einem Standard-Node-Pod zu einem RIG CoreDNS-Endpunkt kommt es bei der Anfrage zu einem Timeout.

Lösung: Stellen Sie internalTrafficPolicy: Local den kube-dns Service so ein, dass Pods CoreDNS nur 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 Knoten mit eingeschränktem Zugriff erreichen Amazon Managed Service für Prometheus nicht

Wenn Metriken von eingeschränkten Nodes 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 die aps:RemoteWrite Berechtigung 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 Collectors. 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 zentralen Collector-Bereitstellungen. In Clustern mit eingeschränkten Knoten stellt das Add-on einen zentralen Kollektor 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 es kubectl describe auf den Collector-Pods, um nach Fehlerereignissen zu suchen:

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

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

Die Überprüfung der Pod-Identität gilt nicht für Knoten mit eingeschränkten Instanzgruppen

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-Gruppen-Ausführungsrolle für die AWS Authentifizierung anstelle von Amazon EKS Pod Identity. Wenn auf eingeschränkten Knoten Metriken 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 absichtlich 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.