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:
+ 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 den Kontext, z. B. den Instance-Typ und das Subnetz, sofern relevant
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.
**Contents**
+ [Voraussetzungen](#monitoring_scaling-logs_prereqs)
+ [Richten Sie Skalierungsprotokolle ein](#monitoring_scaling-logs_setup)
+ [Skalierungsprotokolle finden](#monitoring_scaling-logs_access)
+ [CloudWatch Protokolle](#monitoring_scaling-logs_access_cloudwatch)
+ [Amazon S3](#monitoring_scaling-logs_access_s3)
+ [Skalieren von Protokollfeldern](#monitoring_scaling-logs_fields)
+ [Statuscodes und Ursachencodes](#monitoring_scaling_logs-status-codes-and-reason-codes)
+ [Beispiel für Skalierungsprotokolle](#monitoring_scaling-logs_example)
## 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](https://console.aws.amazon.com/pcs).
1. Klicken Sie im Navigationsbereich auf **Cluster**.
1. Wählen Sie den Cluster aus, dem Sie Skalierungsprotokolle hinzufügen möchten.
1. Wählen Sie auf der Seite mit den Cluster-Details die ** Registerkarte ** Logs aus.
1. 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.
1. 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 ](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html) in der * Amazon CloudWatch Logs API-Referenz. *
1. 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 ](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html) in der * Amazon CloudWatch Logs API-Referenz*.
1. 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 ](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html) 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.
**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](#monitoring_scaling_logs-status-codes-and-reason-codes) |
| 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 im `details` Objekt vorkommen können.
**Felder innerhalb des `` Detailobjekts**
| Name | Beispielwert | Erforderlich | Hinweise |
| --- | --- | --- | --- |
| instance\_id | "i-0abcdef01234567a" | Nein | Die EC2-Instanz, die dem Knoten zugeordnet ist. Fehlt, wenn keine Instance 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 Anrufs in Ihrem Konto |
| instance\_type | "t4g.micro" | Nein | Der Instanztyp wurde gestartet |
| subnet\_id | "subnet-0abc123" | Nein | Das Subnetz, auf das der Start abzielt |
## 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.
**Statuscodes und Ursachencodes**
| Statuscode | Ursachencode | Description |
| --- | --- | --- |
| LAUNCHED | SCHEDULER\_REQUESTED | Die Instance 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 freigegeben hatte (Timeout im Leerlauf oder Ausschalten) |
| 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, 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"
}
}
```