Voraussetzungen Richten Sie Skalierungsprotokolle ein Skalierungsprotokolle finden Skalieren von Protokollfeldern Statuscodes und Ursachencodes Beispiel für Skalierungsprotokolle

Scaling meldet sich an AWS STCK

Durch Skalierungsprotokolle können Sie aufzeichnen, wie AWS Parallel Computing Service skaliert die Rechenknotengruppen in Ihrem Cluster. 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 senden CloudWatch, Amazon Simple Storage Service (Amazon S3) und Amazon Data Firehose. Für jeden Übergang AWS PCS zeichnet die folgenden Daten auf:

Gruppen-Identifikatoren für Cluster und Rechenknoten
Der Knotenname
Der neue Status
Ein Ursachencode und eine für Menschen lesbare Beschreibung
Die EC2-Instanz-ID, wenn eine Instance mit dem Übergang verknüpft ist
Starten Sie gegebenenfalls den Kontext, z. B. den Instance-Typ und das Subnetz

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

Inhalt

Voraussetzungen

Der IAM-Principal, der das verwaltet AWS Der PCS-Cluster muss Folgendes zulassen pcs:AllowVendedLogDeliveryForResource Aktion.

Die folgende Beispiel-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 Ihre einrichten AWS PCS-Cluster mit dem AWS-Managementkonsole oder AWS CLI.

AWS-Managementkonsole

Um Skalierungsprotokolle mit der Konsole einzurichten

Öffnen Sie das AWS PCS-Konsole.
Klicken Sie im Navigationsbereich auf Cluster.
Wählen Sie den Cluster aus, dem Sie Skalierungsprotokolle hinzufügen möchten.
Wählen Sie auf der Seite mit den Cluster-Details die Protokolle Registerkarte.
Unter Protokolle skalieren, wählen Hinzufügen um bis zu 3 Log-Lieferziele aus einer Liste hinzuzufügen CloudWatch Logs, Amazon S3 und Firehose.
Wählen Sie Log-Lieferungen aktualisieren.

AWS CLI

Um Skalierungsprotokolle einzurichten mit dem AWS CLI

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 — Das AWS-Region wo 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) eines CloudWatch Protokolliert die Protokollgruppe, den S3-Bucket oder den Firehose-Lieferstream.
Weitere Informationen finden Sie unter PutDeliveryDestination in der Amazonas CloudWatch API-Referenz für Protokolle.
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 — Das 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-Cluster
Weitere Informationen finden Sie unter PutDeliverySource in der Amazonas CloudWatch API-Referenz für Protokolle.
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 — Das AWS-Region, wie us-east-1
- cluster-logs-source — Der Name Ihrer Lieferquelle
- destination-arn — Die ARN Ihres Lieferziels
Weitere Informationen finden Sie unter CreateDelivery in der Amazonas CloudWatch API-Referenz für Protokolle.

Skalierungsprotokolle finden

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

CloudWatch Protokolle

AWS PCS verwendet das folgende Namensformat für CloudWatch Protokolliert den 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 Protokolleintrag enthält Metadatenfelder auf oberster Ebene und eine details Objekt. Die Felder der obersten Ebene identifizieren den Cluster, die Ereigniszeit und die Compute-Knotengruppen- und Scheduler-Knoten-IDs. Die details Objekt enthält die Übergangsdetails.

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

Top-level Felder
Name	Beispielwert	Erforderlich	Hinweise
`resource_id`	`"pcs_22l8nzr3t9"`	Ja	Die AWS PCS-Cluster-ID
`resource_type`	`"PCS_CLUSTER"`	Ja	Immer `"PCS_CLUSTER"`
`event_timestamp`	`1789179816460`	Ja	Unix-Epoche in Millisekunden, als das Ereignis eintrat
`compute_node_group_id`	`"pcs_56zr33g8"`	Ja	Die Rechenknotengruppe, zu der der Knoten gehört
`scheduler_node_id`	`"compute-1"`	Ja	Die Scheduler-Knoten-ID
`status_code`	`"LAUNCH_FAILED"`	Ja	Der neue Status des Knotens. Siehe Statuscodes und Ursachencodes
`reason_code`	`"INSUFFICIENT_CAPACITY"`	Ja	Warum ist der Übergang passiert
`description`	`"The launch failed because EC2 did not have enough capacity"`	Ja	Eine für Menschen lesbare Zusammenfassung, die aus den Status- und Ursachencodes abgeleitet wurde
`details`	`{...}`	Nein	Zusätzlicher Kontext für den Übergang. Die Schlüssel hängen vom Übergangstyp ab

In der folgenden Tabelle werden die Schlüssel beschrieben, die in der details Objekt.

Felder innerhalb der `Details` Objekt
Name	Beispielwert	Erforderlich	Hinweise
`instance_id`	`"i-0abcdef01234567a"`	Nein	Die dem Knoten zugeordnete EC2-Instanz. Fehlt, wenn keine Instanz zugeordnet ist, z. B. nach einem Startfehler
`ec2_error_code`	`"InsufficientInstanceCapacity"`	Nein	Der EC2-Fehlercode für einen fehlgeschlagenen Start. Derselbe Code erscheint in der CloudTrail Aufzeichnung des CreateFleet rufen Sie Ihr Konto an
`instance_type`	`"t4g.micro"`	Nein	Der gestartete Instanztyp
`subnet_id`	`"subnet-0abc123"`	Nein	Das Subnetz, auf das der Start abzielt

Statuscodes und Ursachencodes

Das status_code Das Feld gibt den Status an, in den der Knoten eingegeben hat. Das reason_code Das Feld sagt dir warum. Zum Beispiel ein LAUNCH_FAILED Status mit einem INSUFFICIENT_CAPACITY Grund bedeutet, 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.

Statuscodes und Ursachencodes
Statuscode	Ursachencode	Description
`LAUNCHED`	`SCHEDULER_REQUESTED`	Die Instanz wurde gestartet, um eine Scale-Up-Anfrage des Schedulers zu erfüllen
`LAUNCHED`	`MAINTAIN_MIN_CAPACITY`	Die Instanz wurde gestartet, um die Mindestkapazität der Knotengruppe aufrechtzuerhalten
`REGISTERED`	`REGISTER_SUCCESS`	Der Knoten wurde erfolgreich über den PCS-Agenten registriert
`ACTIVE`	`BOOTSTRAP_SUCCESS`	Der Knoten-Bootstrap ist abgeschlossen; slurmd läuft und akzeptiert Jobs
`PENDING_REPLACEMENT`	`NODE_GROUP_UPDATE`	Der Knoten ist leer, bevor er für ein Knotengruppen-Update heruntergefahren wird
`PENDING_REPLACEMENT`	`EC2_HEALTH_CHECK_FAILED`	Der Knoten ist überlastet, weil eine Integritätsprüfung des Knotens oder seiner Instanz fehlgeschlagen ist
`PENDING_REPLACEMENT`	`EC2_SCHEDULED_EVENT`	Der Knoten ist überlastet, weil für seine Instanz ein geplantes EC2-Wartungsereignis stattfindet
`LAUNCH_FAILED`	`INSUFFICIENT_CAPACITY`	Der Knoten hat keine Instance erhalten, da nicht genügend Kapazität verfügbar war
`LAUNCH_FAILED`	`LIMIT_EXCEEDED`	Der Instanzstart ist fehlgeschlagen, weil ein Kontingent überschritten wurde
`LAUNCH_FAILED`	`LAUNCH_ERROR`	Der Knoten konnte seine Instanz nicht starten
`TERMINATED`	`SCHEDULER_REQUESTED`	Die Instanz wurde beendet, nachdem der Scheduler den Knoten angehalten hatte (Timeout im Leerlauf oder vom Benutzer veranlasstes Herunterfahren)
`TERMINATED`	`UNHEALTHY_NODE`	Die Instanz wurde beendet, weil der Scheduler den Knoten als fehlerhaft gemeldet hat
`TERMINATED`	`BOOTSTRAP_FAILED`	Die Instanz wurde beendet, weil der Knoten nicht gestartet werden konnte
`TERMINATED`	`EXTERNALLY_TERMINATED`	Die Instanz wurde außerhalb von PCS beendet. Der Knoten wurde freigegeben, sodass er ersetzt werden kann
`TERMINATED`	`REPLACEMENT_REQUESTED`	Die Instanz wurde beendet, weil der Knoten für den Austausch leer war
`TERMINATED`	`NODE_GROUP_DELETION`	Die Instanz wurde im Rahmen des Löschens der Compute-Knotengruppe beendet
`TERMINATE_FAILED`	`EC2_OPERATION_NOT_PERMITTED`	Das Beenden der Instanz ist fehlgeschlagen. Stellen Sie sicher, dass der Kündigungsschutz auf der Instance nicht aktiviert ist
`TERMINATE_FAILED`	`EC2_ERROR`	Die Beendigung der Instanz ist fehlgeschlagen

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, weil keine Instanz 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"
    }
}

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Scheduler-Auditprotokolle

Überwachung mit CloudWatch