Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Scaling se connecte AWS PIÈCES
Les journaux de dimensionnement vous permettent d'enregistrer la manière dont AWS Parallel Computing Service adapte les groupes de nœuds de calcul de votre cluster. Chaque entrée de journal enregistre une transition d'état pour un nœud de calcul : par exemple, le lancement d'une instance, l'enregistrement d'un nœud, une réduction d'échelle ou un échec de lancement avec sa raison. Vous pouvez utiliser les journaux de dimensionnement pour répondre à des questions telles que pourquoi un groupe de nœuds n'a pas atteint sa taille cible, quels lancements ont échoué pour des raisons de capacité et quand un nœud spécifique a démarré ou s'est arrêté.
Vous pouvez envoyer des journaux de dimensionnement à Amazon CloudWatch, Amazon Simple Storage Service (Amazon S3) et Amazon Data Firehose. Pour chaque transition, AWS PCS enregistre les données suivantes :
+ Identifiants de cluster et de groupe de nœuds de calcul
+ Le nom du nœud
+ Le nouveau statut
+ Un code de motif et une description lisible par l'homme
+ L'ID d'instance EC2, lorsqu'une instance est associée à la transition
+ Contexte de lancement, tel que le type d'instance et le sous-réseau, le cas échéant
AWS PCS fournit des journaux de dimensionnement via le type de `PCS_SCALING_LOGS` journal. La mise à l'échelle de la livraison des journaux est optionnelle. AWS PCS ne fournit pas de journaux de dimensionnement pour un cluster tant que vous n'avez pas configuré une livraison pour celui-ci.
**Contents**
+ [Conditions préalables](#monitoring_scaling-logs_prereqs)
+ [Configurer des journaux de dimensionnement](#monitoring_scaling-logs_setup)
+ [Recherche de journaux de dimensionnement](#monitoring_scaling-logs_access)
+ [CloudWatch Journaux](#monitoring_scaling-logs_access_cloudwatch)
+ [Amazon S3](#monitoring_scaling-logs_access_s3)
+ [Dimensionnement des champs de journal](#monitoring_scaling-logs_fields)
+ [Codes de statut et codes de motif](#monitoring_scaling_logs-status-codes-and-reason-codes)
+ [Exemples de journaux de dimensionnement](#monitoring_scaling-logs_example)
## Conditions préalables
Le principal IAM qui gère le cluster AWS PCS doit autoriser l'`pcs:AllowVendedLogDeliveryForResource`action.
L'exemple de politique IAM suivant accorde les autorisations requises.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PcsAllowVendedLogsDelivery",
"Effect": "Allow",
"Action": ["pcs:AllowVendedLogDeliveryForResource"],
"Resource": [
"arn:aws:pcs:*::cluster/*"
]
}
]
}
```
## Configurer des journaux de dimensionnement
Vous pouvez configurer des journaux de dimensionnement pour votre cluster AWS PCS à l'aide du Console de gestion AWS ou AWS CLI.
------
#### [ Console de gestion AWS ]
**Pour configurer les journaux de dimensionnement à l'aide de la console**
1. Ouvrez la console [AWS PCS](https://console.aws.amazon.com/pcs).
1. Dans le panneau de navigation, choisissez **Clusters**.
1. Choisissez le cluster dans lequel vous souhaitez ajouter des journaux de dimensionnement.
1. Sur la page des détails du cluster, choisissez l'**onglet ** Journaux.
1. Dans ** Scaling Logs**, choisissez ** Ajouter ** pour ajouter jusqu'à 3 destinations de livraison des CloudWatch journaux parmi Logs, Amazon S3 et Firehose.
1. Choisissez ** Mettre à jour les livraisons de journaux**.
------
#### [ AWS CLI ]
**Pour configurer des journaux de dimensionnement avec AWS CLI**
1. Créez une destination de livraison des journaux :
```
aws logs put-delivery-destination --region {{region}} \
--name {{pcs-logs-destination}} \
--delivery-destination-configuration \
destinationResourceArn={{resource-arn}}
```
Remplacez :
+ {{region}}— L' Région AWS endroit où vous souhaitez créer la destination, par exemple `us-east-1`
+ {{pcs-logs-destination}}— Un nom pour la destination
+ {{resource-arn}}— Le nom de ressource Amazon (ARN) d'un groupe de CloudWatch journaux Logs, d'un bucket S3 ou d'un flux de diffusion Firehose.
Pour plus d'informations, consultez [ PutDeliveryDestination ](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html) le manuel * Amazon CloudWatch Logs API Reference*.
1. Définissez le cluster PCS comme source de livraison de journaux :
```
aws logs put-delivery-source --region {{region}} \
--name {{cluster-logs-source-name}} \
--resource-arn {{cluster-arn}} \
--log-type PCS_SCALING_LOGS
```
Remplacez :
+ {{region}}— Le Région AWS de votre cluster, tel que `us-east-1`
+ {{cluster-logs-source-name}}— Un nom pour la source
+ {{cluster-arn}}— l'ARN de votre cluster AWS PCS
Pour plus d'informations, consultez [ PutDeliverySource ](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html) le manuel * Amazon CloudWatch Logs API Reference*.
1. Connectez la source de livraison à la destination de livraison :
```
aws logs create-delivery --region {{region}} \
--delivery-source-name {{cluster-logs-source}} \
--delivery-destination-arn {{destination-arn}}
```
Remplacez :
+ {{region}}— Les Région AWS, tels que `us-east-1`
+ {{cluster-logs-source}}— Le nom de votre source de livraison
+ {{destination-arn}}— L'ARN de votre destination de livraison
Pour plus d'informations, consultez [ CreateDelivery ](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html) le manuel * Amazon CloudWatch Logs API Reference*.
------
## Recherche de journaux de dimensionnement
Vous pouvez configurer les destinations des CloudWatch journaux dans Logs et Amazon S3. AWS PCS utilise les noms de chemin et de fichier structurés suivants.
### CloudWatch Journaux
AWS PCS utilise le format de nom suivant pour le flux CloudWatch Logs :
```
AWSLogs/PCS/{{cluster-id}}/node_lifecycle.log
```
Par exemple : `AWSLogs/PCS/pcs_abc123de45/node_lifecycle.log`
### Amazon S3
AWS PCS utilise le format de nom suivant pour le chemin S3 :
```
AWSLogs/{{account-id}}/PCS/{{region}}/{{cluster-id}}/node_lifecycle/{{year}}/{{month}}/{{day}}/{{hour}}/
```
Par exemple : `AWSLogs/111122223333/PCS/us-east-1/pcs_abc123de45/node_lifecycle/2026/09/03/11/`
AWS PCS utilise le format de nom suivant pour les fichiers journaux :
```
PCS_{{cluster-id}}_node_lifecycle_{{year}}-{{month}}-{{day}}-{{hour}}_{{random-id}}.log.gz
```
Par exemple : `PCS_pcs_abc123de45_node_lifecycle_2026-09-03-11_04be080b.log.gz`
## Dimensionnement des champs de journal
AWS PCS écrit les données du journal de dimensionnement sous forme d'objets JSON. Chaque entrée de journal contient des champs de métadonnées de niveau supérieur et un `details` objet. Les champs de niveau supérieur identifient le cluster, l'heure de l'événement et les identifiants du groupe de nœuds de calcul et des nœuds du planificateur. L'`details`objet contient les détails de la transition.
Le tableau suivant décrit les champs de niveau supérieur de chaque entrée de journal.
**Top-level champs**
| Nom | Exemple de valeur | Obligatoire | Remarques |
| --- | --- | --- | --- |
| resource\_id | "pcs\_22l8nzr3t9" | Oui | L'identifiant du cluster AWS PCS |
| resource\_type | "PCS\_CLUSTER" | Oui | Toujours "PCS\_CLUSTER" |
| event\_timestamp | 1789179816460 | Oui | Époque Unix : millisecondes à laquelle l'événement s'est produit |
| compute\_node\_group\_id | "pcs\_56zr33g8" | Oui | Le groupe de nœuds de calcul auquel appartient le nœud |
| scheduler\_node\_id | "compute-1" | Oui | L'identifiant du nœud du planificateur |
| status\_code | "LAUNCH\_FAILED" | Oui | Le nouvel état du nœud. Consultez [Codes de statut et codes de motif](#monitoring_scaling_logs-status-codes-and-reason-codes) |
| reason\_code | "INSUFFICIENT\_CAPACITY" | Oui | Pourquoi la transition s'est produite |
| description | "The launch failed because EC2 did not have enough capacity" | Oui | Un résumé lisible par l'homme dérivé des codes de statut et de motif |
| details | {...} | Non | Contexte supplémentaire pour la transition. Les clés dépendent du type de transition |
Le tableau suivant décrit les touches qui peuvent apparaître à l'intérieur de l'`details`objet.
**Champs à l'intérieur de l'`objet de` détails**
| Nom | Exemple de valeur | Obligatoire | Remarques |
| --- | --- | --- | --- |
| instance\_id | "i-0abcdef01234567a" | Non | L'instance EC2 associée au nœud. Absent lorsqu'aucune instance n'est associée, par exemple après un échec de lancement |
| ec2\_error\_code | "InsufficientInstanceCapacity" | Non | Code d'erreur EC2 correspondant à un échec de lancement. Le même code apparaît dans l' CloudTrail enregistrement de l' CreateFleet appel sur votre compte |
| instance\_type | "t4g.micro" | Non | Le type d'instance lancé |
| subnet\_id | "subnet-0abc123" | Non | Le sous-réseau visé par le lancement |
## Codes de statut et codes de motif
Le `status_code` champ indique l'état saisi par le nœud. Le `reason_code` champ vous explique pourquoi. Par exemple, un `LAUNCH_FAILED` statut avec une `INSUFFICIENT_CAPACITY` raison signifie qu'Amazon EC2 n'a pas pu fournir de capacité pour le type d'instance demandé dans le sous-réseau ciblé. A `LIMIT_EXCEEDED` signifie qu'un quota Amazon EC2 a bloqué le lancement.
**Codes de statut et codes de motif**
| Code de statut | Code de motif | Description |
| --- | --- | --- |
| LAUNCHED | SCHEDULER\_REQUESTED | Instance lancée pour répondre à une demande de mise à l'échelle d'un planificateur |
| LAUNCHED | MAINTAIN\_MIN\_CAPACITY | Instance lancée pour maintenir la capacité minimale du groupe de nœuds |
| REGISTERED | REGISTER\_SUCCESS | Nœud enregistré avec succès via l'agent PCS |
| ACTIVE | BOOTSTRAP\_SUCCESS | Le bootstrap du nœud est terminé ; slurmd est en cours d'exécution et accepte les jobs |
| PENDING\_REPLACEMENT | NODE\_GROUP\_UPDATE | Le nœud est en train de se vider avant d'être mis hors tension pour une mise à jour du groupe de nœuds |
| PENDING\_REPLACEMENT | EC2\_HEALTH\_CHECK\_FAILED | Le nœud est en train de se vider car un contrôle de santé du nœud ou de son instance a échoué |
| PENDING\_REPLACEMENT | EC2\_SCHEDULED\_EVENT | Le nœud est en train de se vider car son instance comporte un événement de maintenance EC2 planifié |
| LAUNCH\_FAILED | INSUFFICIENT\_CAPACITY | Le nœud n'a pas obtenu d'instance car la capacité disponible était insuffisante |
| LAUNCH\_FAILED | LIMIT\_EXCEEDED | Le lancement de l'instance a échoué car un quota de compte a été dépassé |
| LAUNCH\_FAILED | LAUNCH\_ERROR | Le nœud n'a pas pu lancer son instance |
| TERMINATED | SCHEDULER\_REQUESTED | L'instance s'est arrêtée après que le planificateur a libéré le nœud (délai d'inactivité ou mise hors tension) |
| TERMINATED | UNHEALTHY\_NODE | Instance arrêtée car le planificateur a signalé que le nœud était défectueux |
| TERMINATED | BOOTSTRAP\_FAILED | L'instance s'est arrêtée car le nœud n'a pas pu démarrer |
| TERMINATED | EXTERNALLY\_TERMINATED | L'instance a été arrêtée en dehors du PCS ; le nœud a été libéré afin de pouvoir être remplacé |
| TERMINATED | REPLACEMENT\_REQUESTED | L'instance a été arrêtée car le nœud a été vidé pour être remplacé |
| TERMINATED | NODE\_GROUP\_DELETION | Instance arrêtée dans le cadre de la suppression d'un groupe de nœuds de calcul |
| TERMINATE\_FAILED | EC2\_OPERATION\_NOT\_PERMITTED | La résiliation de l'instance a échoué. Assurez-vous que la protection contre les interruptions n'est pas activée sur l'instance |
| TERMINATE\_FAILED | EC2\_ERROR | La résiliation de l'instance a échoué |
## Exemples de journaux de dimensionnement
L'exemple suivant montre un lancement d'instance réussi :
```
{
"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"
}
}
```
L'exemple suivant montre un échec de lancement dû à une capacité EC2 insuffisante. Non `instance_id` est présent car aucune instance n'a été lancée.
```
{
"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"
}
}
```