

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

# Escalando los inicios de sesión AWS PC
<a name="monitoring_scaling-logs"></a>

Los registros de escalado proporcionan un registro de cómo AWS Parallel Computing Service escala los grupos de nodos de procesamiento de su clúster. Cada entrada de registro registra una transición de estado para un nodo de procesamiento: por ejemplo, el lanzamiento de una instancia, el registro de un nodo, una reducción de escala o un error de lanzamiento con el motivo. Puedes usar los registros de escalado para responder a preguntas como por qué un grupo de nodos no alcanzó su tamaño objetivo, qué lanzamientos fallaron por motivos de capacidad y cuándo se inició o detuvo un nodo específico.

Puede enviar registros de escalado a Amazon CloudWatch, Amazon Simple Storage Service (Amazon S3) y Amazon Data Firehose. Para cada transición, AWS PCS registra los siguientes datos:
+ Identificadores de grupos de clústeres y nodos de cómputos
+ El nombre del nodo
+ El nuevo estado
+ Un código de motivo y una descripción legible por humanos
+ El ID de instancia EC2, cuando una instancia está asociada a la transición
+ Inicie el contexto, como el tipo de instancia y la subred, cuando sea relevante

AWS PCS proporciona registros de escalado según el tipo de `PCS_SCALING_LOGS` registro. La entrega de registros de escalado es opcional. AWS PCS no entrega registros de escalado para un clúster hasta que usted configure una entrega para él.

**Contents**
+ [Requisitos previos](#monitoring_scaling-logs_prereqs)
+ [Configura los registros de escalado](#monitoring_scaling-logs_setup)
+ [Búsqueda de registros de escalado](#monitoring_scaling-logs_access)
  + [CloudWatch Registros](#monitoring_scaling-logs_access_cloudwatch)
  + [Amazon S3](#monitoring_scaling-logs_access_s3)
+ [Escalar los campos de registro](#monitoring_scaling-logs_fields)
+ [Códigos de estado y códigos de motivo](#monitoring_scaling_logs-status-codes-and-reason-codes)
+ [Ejemplos de registros de escalado](#monitoring_scaling-logs_example)

## Requisitos previos
<a name="monitoring_scaling-logs_prereqs"></a>

El director de IAM que administra el clúster de AWS PCS debe permitir la `pcs:AllowVendedLogDeliveryForResource` acción.

El siguiente ejemplo de política de IAM otorga los permisos necesarios.

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

## Configura los registros de escalado
<a name="monitoring_scaling-logs_setup"></a>

Puede configurar los registros de escalado para su clúster AWS PCS con la tecla Consola de administración de AWS o AWS CLI.

------
#### [ Consola de administración de AWS ]

**Para configurar los registros de escalado con la consola**

1. Abra la consola [AWS PCS](https://console.aws.amazon.com/pcs).

1. En el panel de navegación, seleccione **Clusters (Clústeres)**.

1. Elija el clúster en el que desea agregar los registros de escalado.

1. En la página de detalles del clúster, selecciona la ** pestaña ** Registros.

1. En Registros de ** escalado**, elija ** Agregar ** para agregar hasta 3 destinos de entrega de CloudWatch registros de entre Logs, Amazon S3 y Firehose.

1. Seleccione ** Actualizar las entregas ** de registros.

------
#### [ AWS CLI ]

**Para configurar el escalado de los registros con AWS CLI**

1. Cree un destino de entrega de registros:

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

   Reemplace:
   + {{region}}— El Región de AWS lugar en el que desea crear el destino, como `us-east-1`
   + {{pcs-logs-destination}}— Un nombre para el destino
   + {{resource-arn}}— El nombre de recurso de Amazon (ARN) de un grupo de CloudWatch registros de Logs, un bucket de S3 o una secuencia de entrega de Firehose.

   Para obtener más información, consulte la referencia de [ PutDeliveryDestination ](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html) la API de * Amazon CloudWatch Logs. *

1. Configure el clúster PCS como fuente de entrega de registros:

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

   Reemplace:
   + {{region}}— El Región de AWS de su clúster, como `us-east-1`
   + {{cluster-logs-source-name}}— Un nombre para la fuente
   + {{cluster-arn}}— el ARN de su clúster de AWS PCS

   Para obtener más información, consulte la referencia [ PutDeliverySource ](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html) * de la API de * Amazon CloudWatch Logs.

1. Conecta la fuente de entrega con el destino de entrega:

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

   Reemplace:
   + {{region}}— Los Región de AWS, como `us-east-1`
   + {{cluster-logs-source}}— El nombre de su fuente de entrega
   + {{destination-arn}}— El ARN de tu destino de entrega

   Para obtener más información, consulte la referencia [ CreateDelivery ](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html) * de la API de * Amazon CloudWatch Logs.

------

## Búsqueda de registros de escalado
<a name="monitoring_scaling-logs_access"></a>

Puede configurar los destinos de los CloudWatch registros en Logs y Amazon S3. AWS PCS usa los siguientes nombres de ruta y archivos estructurados.

### CloudWatch Registros
<a name="monitoring_scaling-logs_access_cloudwatch"></a>

AWS PCS usa el siguiente formato de nombre para la transmisión de CloudWatch registros:

```
AWSLogs/PCS/{{cluster-id}}/node_lifecycle.log
```

Por ejemplo: `AWSLogs/PCS/pcs_abc123de45/node_lifecycle.log`

### Amazon S3
<a name="monitoring_scaling-logs_access_s3"></a>

AWS PCS usa el siguiente formato de nombre para la ruta S3:

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

Por ejemplo: `AWSLogs/111122223333/PCS/us-east-1/pcs_abc123de45/node_lifecycle/2026/09/03/11/`

AWS PCS utiliza el siguiente formato de nombre para los archivos de registro:

```
PCS_{{cluster-id}}_node_lifecycle_{{year}}-{{month}}-{{day}}-{{hour}}_{{random-id}}.log.gz
```

Por ejemplo: `PCS_pcs_abc123de45_node_lifecycle_2026-09-03-11_04be080b.log.gz`

## Escalar los campos de registro
<a name="monitoring_scaling-logs_fields"></a>

AWS PCS escribe los datos de registro de escalado como objetos JSON. Cada entrada de registro contiene campos de metadatos de nivel superior y un `details` objeto. Los campos de nivel superior identifican el clúster, la hora del evento y los ID del grupo de nodos de cálculo y del nodo planificador. El `details` objeto contiene los detalles de la transición.

En la tabla siguiente se describen los campos de nivel superior de cada entrada de registro.


**Top-level campos**  

| Name | Ejemplo de valor | Obligatorio | Notas | 
| --- | --- | --- | --- | 
| resource\_id | "pcs\_22l8nzr3t9" | Sí | El ID del clúster AWS PCS | 
| resource\_type | "PCS\_CLUSTER" | Sí | Siempre "PCS\_CLUSTER" | 
| event\_timestamp | 1789179816460 | Sí | Unix epoch milisegundos cuando ocurrió el evento | 
| compute\_node\_group\_id | "pcs\_56zr33g8" | Sí | El grupo de nodos de computación al que pertenece el nodo | 
| scheduler\_node\_id | "compute-1" | Sí | El identificador del nodo del planificador | 
| status\_code | "LAUNCH\_FAILED" | Sí | El nuevo estado del nodo. Consulte [Códigos de estado y códigos de motivo](#monitoring_scaling_logs-status-codes-and-reason-codes) | 
| reason\_code | "INSUFFICIENT\_CAPACITY" | Sí | Por qué se produjo la transición | 
| description | "The launch failed because EC2 did not have enough capacity" | Sí | Un resumen legible por humanos derivado de los códigos de estado y motivo | 
| details | {...} | No | Contexto adicional para la transición. Las claves dependen del tipo de transición | 

En la tabla siguiente se describen las claves que pueden aparecer dentro del `details` objeto.


**Campos del `objeto de` detalles**  

| Name | Ejemplo de valor | Obligatorio | Notas | 
| --- | --- | --- | --- | 
| instance\_id | "i-0abcdef01234567a" | No | La instancia EC2 asociada al nodo. Ausente cuando no hay ninguna instancia asociada, por ejemplo, después de un error de lanzamiento | 
| ec2\_error\_code | "InsufficientInstanceCapacity" | No | El código de error de EC2 para un lanzamiento fallido. El mismo código aparece en el CloudTrail registro de la CreateFleet llamada de su cuenta | 
| instance\_type | "t4g.micro" | No | El tipo de instancia lanzada | 
| subnet\_id | "subnet-0abc123" | No | La subred a la que se dirige el lanzamiento | 

## Códigos de estado y códigos de motivo
<a name="monitoring_scaling_logs-status-codes-and-reason-codes"></a>

El `status_code` campo indica el estado en el que ha entrado el nodo. El `reason_code` campo indica el motivo. Por ejemplo, un `LAUNCH_FAILED` estado con un `INSUFFICIENT_CAPACITY` motivo significa que Amazon EC2 no pudo proporcionar capacidad para el tipo de instancia solicitado en la subred de destino. A `LIMIT_EXCEEDED` significa que una cuota de Amazon EC2 bloqueó el lanzamiento.


**Códigos de estado y códigos de motivo**  

| Código de estado | Código de motivo | Description (Descripción) | 
| --- | --- | --- | 
| LAUNCHED | SCHEDULER\_REQUESTED | Instancia lanzada para satisfacer una solicitud de ampliación del planificador | 
| LAUNCHED | MAINTAIN\_MIN\_CAPACITY | Instancia lanzada para mantener la capacidad mínima del grupo de nodos | 
| REGISTERED | REGISTER\_SUCCESS | El nodo se registró correctamente mediante el agente PCS | 
| ACTIVE | BOOTSTRAP\_SUCCESS | Se completó el arranque del nodo; slurmd se está ejecutando y está aceptando trabajos | 
| PENDING\_REPLACEMENT | NODE\_GROUP\_UPDATE | El nodo se está agotando antes de apagarlo para actualizar un grupo de nodos | 
| PENDING\_REPLACEMENT | EC2\_HEALTH\_CHECK\_FAILED | El nodo se está agotando porque no se pudo realizar una comprobación de estado del nodo o de su instancia | 
| PENDING\_REPLACEMENT | EC2\_SCHEDULED\_EVENT | El nodo se está agotando porque su instancia tiene un evento de mantenimiento de EC2 programado | 
| LAUNCH\_FAILED | INSUFFICIENT\_CAPACITY | El nodo no recibió una instancia porque no había suficiente capacidad disponible | 
| LAUNCH\_FAILED | LIMIT\_EXCEEDED | El lanzamiento de la instancia falló porque se superó la cuota de la cuenta | 
| LAUNCH\_FAILED | LAUNCH\_ERROR | El nodo no pudo lanzar su instancia | 
| TERMINATED | SCHEDULER\_REQUESTED | La instancia finalizó después de que el planificador liberara el nodo (se agotó el tiempo de espera o se apagó) | 
| TERMINATED | UNHEALTHY\_NODE | La instancia finalizó porque el planificador informó que el nodo no estaba en buen estado | 
| TERMINATED | BOOTSTRAP\_FAILED | La instancia finalizó porque el nodo no pudo arrancar | 
| TERMINATED | EXTERNALLY\_TERMINATED | La instancia se terminó fuera de PCS; el nodo se liberó para poder reemplazarlo | 
| TERMINATED | REPLACEMENT\_REQUESTED | La instancia se terminó porque el nodo se agotó para reemplazarlo | 
| TERMINATED | NODE\_GROUP\_DELETION | La instancia finalizó como parte de la eliminación del grupo de nodos de procesamiento | 
| TERMINATE\_FAILED | EC2\_OPERATION\_NOT\_PERMITTED | Falló la finalización de la instancia. Asegúrese de que la protección contra la terminación no esté habilitada en la instancia | 
| TERMINATE\_FAILED | EC2\_ERROR | Falló la terminación de la instancia | 

## Ejemplos de registros de escalado
<a name="monitoring_scaling-logs_example"></a>

El siguiente ejemplo muestra el lanzamiento exitoso de una instancia:

```
{
    "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"
    }
}
```

El siguiente ejemplo muestra un error de lanzamiento provocado por una capacidad insuficiente de EC2. No `instance_id` está presente porque no se lanzó ninguna instancia.

```
{
    "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"
    }
}
```