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.

Scaling meldet sich an AWS STCK

Mithilfe von Skalierungsprotokollen können Sie aufzeichnen, wie AWS Parallel Computing Service die Rechenknotengruppen in Ihrem Cluster skaliert. Jeder Protokolleintrag zeichnet einen Zustandsübergang für einen Rechenknoten auf: zum Beispiel einen Instance-Start, eine Knotenregistrierung, eine Herunterskalierung oder einen Startfehler mit der entsprechenden Ursache. Sie können Skalierungsprotokolle verwenden, um Fragen zu beantworten, z. B. warum eine Knotengruppe ihre Zielgröße nicht erreicht hat, welche Starts aus Kapazitätsgründen fehlgeschlagen sind und wann ein bestimmter Knoten gestartet oder gestoppt wurde.

Sie können Skalierungsprotokolle an Amazon CloudWatch, Amazon Simple Storage Service (Amazon S3) und Amazon Data Firehose senden. Für jeden Übergang zeichnet AWS PCS die folgenden Daten auf:

AWS PCS liefert Skalierungsprotokolle anhand des PCS_SCALING_LOGS Protokolltyps. Die Skalierung der Protokollzustellung ist optional. AWS PCS liefert keine Skalierungsprotokolle für einen Cluster, bis Sie eine Bereitstellung dafür konfiguriert haben.

Voraussetzungen

Der IAM-Prinzipal, der den AWS PCS-Cluster verwaltet, muss die pcs:AllowVendedLogDeliveryForResource Aktion zulassen.

Das folgende Beispiel für eine IAM-Richtlinie gewährt die erforderlichen Berechtigungen.

{
    "Version": "2012-10-17",
    "Statement": [ 
        {
            "Sid": "PcsAllowVendedLogsDelivery",
            "Effect": "Allow",
            "Action": ["pcs:AllowVendedLogDeliveryForResource"],
            "Resource": [
                "arn:aws:pcs:*::cluster/*"
            ]
        }
    ]
}

Richten Sie Skalierungsprotokolle ein

Sie können Skalierungsprotokolle für Ihren AWS PCS-Cluster mit dem AWS-Managementkonsole oder einrichten AWS CLI.

AWS-Managementkonsole

So richten Sie Skalierungsprotokolle mit der Konsole ein

1. Öffnen Sie die AWS PCS-Konsole.

2. Klicken Sie im Navigationsbereich auf Cluster.

3. Wählen Sie den Cluster aus, dem Sie Skalierungsprotokolle hinzufügen möchten.

4. Wählen Sie auf der Seite mit den Cluster-Details die Registerkarte Logs aus.

5. Wählen Sie unter Scaling Logs die Option Hinzufügen aus, um bis zu 3 Log-Lieferziele aus CloudWatch Logs, Amazon S3 und Firehose hinzuzufügen.

6. Wählen Sie Protokolllieferungen aktualisieren aus.

AWS CLI

Um Skalierungsprotokolle einzurichten, verwenden Sie die AWS CLI

1. Erstellen Sie ein Ziel für die Protokollübermittlung:

   aws logs put-delivery-destination --region region \
     --name pcs-logs-destination \
     --delivery-destination-configuration \
     destinationResourceArn=resource-arn

   Ersetzen Sie:

   • region— Der AWS-Region Ort, an dem Sie das Ziel erstellen möchten, z. B. us-east-1

   • pcs-logs-destination— Ein Name für das Ziel

   • resource-arn— Der Amazon-Ressourcenname (ARN) einer CloudWatch Logs-Protokollgruppe, eines S3-Buckets oder eines Firehose-Lieferstreams.

   Weitere Informationen finden Sie PutDeliveryDestination in der Amazon CloudWatch Logs API-Referenz.

2. Stellen Sie den PCS-Cluster als Quelle für die Protokollübermittlung ein:

   aws logs put-delivery-source --region region \
     --name cluster-logs-source-name \
     --resource-arn cluster-arn \
     --log-type PCS_SCALING_LOGS

   Ersetzen Sie:

   • region— Die AWS-Region Ihres Clusters, wie us-east-1

   • cluster-logs-source-name— Ein Name für die Quelle

   • cluster-arn— der ARN Ihres AWS PCS-Clusters

   Weitere Informationen finden Sie PutDeliverySource in der Amazon CloudWatch Logs API-Referenz.

3. Verbinden Sie die Lieferquelle mit dem Lieferziel:

   aws logs create-delivery --region region \
     --delivery-source-name cluster-logs-source \
     --delivery-destination-arn destination-arn

   Ersetzen Sie:

   • region— Die AWS-Region, wie us-east-1

   • cluster-logs-source— Der Name Ihrer Lieferquelle

   • destination-arn— Die ARN Ihres Lieferziels

   Weitere Informationen finden Sie CreateDelivery in der Amazon CloudWatch Logs API-Referenz.

Skalierungsprotokolle finden

Sie können Protokollziele in CloudWatch Logs und Amazon S3 konfigurieren. AWS PCS verwendet die folgenden strukturierten Pfadnamen und Dateinamen.

CloudWatch Protokolle

AWS PCS verwendet das folgende Namensformat für den CloudWatch Logs-Stream:

AWSLogs/PCS/cluster-id/node_lifecycle.log

Beispiel: AWSLogs/PCS/pcs_abc123de45/node_lifecycle.log

Amazon S3

AWS PCS verwendet das folgende Namensformat für den S3-Pfad:

AWSLogs/account-id/PCS/region/cluster-id/node_lifecycle/year/month/day/hour/

Beispiel: AWSLogs/111122223333/PCS/us-east-1/pcs_abc123de45/node_lifecycle/2026/09/03/11/

AWS PCS verwendet das folgende Namensformat für die Protokolldateien:

PCS_cluster-id_node_lifecycle_year-month-day-hour_random-id.log.gz

Beispiel: PCS_pcs_abc123de45_node_lifecycle_2026-09-03-11_04be080b.log.gz

Skalieren von Protokollfeldern

AWS PCS schreibt skalierende Protokolldaten als JSON-Objekte. Jeder Logeintrag enthält Metadatenfelder der obersten Ebene und ein details Objekt. Die Felder der obersten Ebene identifizieren den Cluster, die Ereigniszeit und die Knoten-IDs für Rechenknoten und Scheduler. Das details Objekt enthält die Übergangsdetails.

In der folgenden Tabelle werden die Felder der obersten Ebene in jedem Protokolleintrag beschrieben.

In der folgenden Tabelle werden die Schlüssel beschrieben, die im details Objekt vorkommen können.

Statuscodes und Ursachencodes

Das status_code Feld gibt den Status an, in den der Knoten eingegeben hat. Das reason_code Feld sagt Ihnen warum. Ein LAUNCH_FAILED Status mit einem INSUFFICIENT_CAPACITY Grund bedeutet beispielsweise, dass Amazon EC2 im Zielsubnetz keine Kapazität für den angeforderten Instance-Typ bereitstellen konnte. A LIMIT_EXCEEDED bedeutet, dass ein Amazon EC2-Kontingent den Start blockiert hat.

Beispiel für Skalierungsprotokolle

Das folgende Beispiel zeigt einen erfolgreichen Instance-Start:

{
    "resource_id": "pcs_abc123de45",
    "resource_type": "PCS_CLUSTER",
    "event_timestamp": 1789179816460,
    "compute_node_group_id": "pcs_abcdef01",
    "scheduler_node_id": "compute-1",
    "status_code": "LAUNCHED",
    "reason_code": "SCHEDULER_REQUESTED",
    "description": "Instance launched to satisfy a scheduler scale-up request.",
    "details": {
        "instance_id": "i-0abc12345def67890",
        "instance_type": "c6i.xlarge",
        "subnet_id": "subnet-0123456789abcdef0"
    }
}

Das folgende Beispiel zeigt einen Startfehler, der durch unzureichende EC2-Kapazität verursacht wurde. Nein instance_id ist vorhanden, da keine Instance gestartet wurde.

{
    "resource_id": "pcs_abc123de45",
    "resource_type": "PCS_CLUSTER",
    "event_timestamp": 1789179816460,
    "compute_node_group_id": "pcs_abcdef01",
    "scheduler_node_id": "compute-2",
    "status_code": "LAUNCH_FAILED",
    "reason_code": "INSUFFICIENT_CAPACITY",
    "description": "Node did not get an instance because there was not enough capacity available.",
    "details": {
        "ec2_error_code": "InsufficientInstanceCapacity"
    }
}