

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Registros de escalabilidade AWS PEÇAS
<a name="monitoring_scaling-logs"></a>

Os registros de escalabilidade fornecem um registro de como o AWS Parallel Computing Service dimensiona os grupos de nós de computação em seu cluster. Cada entrada de registro registra uma transição de estado para um nó de computação: por exemplo, uma inicialização de instância, um registro de nó, uma redução de escala ou uma falha de inicialização com seu motivo. Você pode usar registros de escalabilidade para responder perguntas como por que um grupo de nós não atingiu o tamanho desejado, quais inicializações falharam por motivos de capacidade e quando um nó específico foi iniciado ou interrompido.

Você pode enviar logs de escalabilidade para a Amazon CloudWatch, Amazon Simple Storage Service (Amazon S3) e Amazon Data Firehose. Para cada transição, o AWS PCS registra os seguintes dados:
+ Identificadores de grupos de clusters e nós de computação
+ O nome do nó
+ O novo status
+ Um código de motivo e uma descrição legível por humanos
+ O ID da instância EC2, quando uma instância está associada à transição
+ Contexto de inicialização, como tipo de instância e sub-rede, quando relevante

AWS O PCS fornece registros de escalabilidade por meio do tipo de `PCS_SCALING_LOGS` registro. O escalonamento da entrega de registros é opcional. AWS O PCS não entrega registros de escalabilidade para um cluster até que você configure uma entrega para ele.

**Contents**
+ [Pré-requisitos](#monitoring_scaling-logs_prereqs)
+ [Configurar registros de escalabilidade](#monitoring_scaling-logs_setup)
+ [Encontrando registros de escalabilidade](#monitoring_scaling-logs_access)
  + [CloudWatch Registros](#monitoring_scaling-logs_access_cloudwatch)
  + [Amazon S3](#monitoring_scaling-logs_access_s3)
+ [Campos de registro de escalabilidade](#monitoring_scaling-logs_fields)
+ [Códigos de status e códigos de motivo](#monitoring_scaling_logs-status-codes-and-reason-codes)
+ [Exemplos de registros de escalabilidade](#monitoring_scaling-logs_example)

## Pré-requisitos
<a name="monitoring_scaling-logs_prereqs"></a>

O principal do IAM que gerencia o cluster AWS PCS deve permitir a `pcs:AllowVendedLogDeliveryForResource` ação.

O exemplo de política do IAM a seguir concede as permissões necessárias.

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

## Configurar registros de escalabilidade
<a name="monitoring_scaling-logs_setup"></a>

Você pode configurar registros de escalabilidade para seu cluster AWS PCS com o Console de gerenciamento da AWS ou AWS CLI.

------
#### [ Console de gerenciamento da AWS ]

**Para configurar registros de escalabilidade com o console**

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

1. No painel de navegação, escolha **Clusters**.

1. Escolha o cluster em que você deseja adicionar registros de escalabilidade.

1. Na página de detalhes do cluster, escolha a ** guia ** Logs.

1. Em ** Scaling Logs**, escolha ** Adicionar ** para adicionar até 3 destinos de entrega de log entre CloudWatch Logs, Amazon S3 e Firehose.

1. Escolha ** Atualizar entregas ** de registros.

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

**Para configurar registros de escalabilidade com o AWS CLI**

1. Crie um destino de entrega de registros:

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

   Substitua:
   + {{region}}— O Região da AWS local onde você deseja criar o destino, como `us-east-1`
   + {{pcs-logs-destination}}— Um nome para o destino
   + {{resource-arn}}— O nome de recurso da Amazon (ARN) de um grupo de CloudWatch logs do Logs, bucket do S3 ou stream de entrega do Firehose.

   Para obter mais informações, consulte [ PutDeliveryDestination ](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html) a Referência da API * Amazon CloudWatch Logs*.

1. Defina o cluster PCS como uma fonte de entrega de log:

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

   Substitua:
   + {{region}}— O Região da AWS do seu cluster, como `us-east-1`
   + {{cluster-logs-source-name}}— Um nome para a fonte
   + {{cluster-arn}}— o ARN do seu cluster AWS PCS

   Para obter mais informações, consulte [ PutDeliverySource ](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html) a Referência da API * Amazon CloudWatch Logs*.

1. Conecte a fonte de entrega ao destino da entrega:

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

   Substitua:
   + {{region}}— O Região da AWS, como `us-east-1`
   + {{cluster-logs-source}}— O nome da sua fonte de entrega
   + {{destination-arn}}— O ARN do seu destino de entrega

   Para obter mais informações, consulte [ CreateDelivery ](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html) a Referência da API * Amazon CloudWatch Logs*.

------

## Encontrando registros de escalabilidade
<a name="monitoring_scaling-logs_access"></a>

Você pode configurar destinos de log no CloudWatch Logs e no Amazon S3. AWS O PCS usa os seguintes nomes de caminhos estruturados e nomes de arquivo.

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

AWS O PCS usa o seguinte formato de nome para o fluxo de CloudWatch registros:

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

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

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

AWS O PCS usa o seguinte formato de nome para o caminho S3:

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

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

AWS O PCS usa o seguinte formato de nome para os arquivos de log:

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

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

## Campos de registro de escalabilidade
<a name="monitoring_scaling-logs_fields"></a>

AWS O PCS grava dados de log de escalabilidade como objetos JSON. Cada entrada de registro contém campos de metadados de nível superior e um `details` objeto. Os campos de nível superior identificam o cluster, a hora do evento e os IDs do grupo de nós de computação e dos nós do agendador. O `details` objeto contém os detalhes da transição.

A tabela a seguir descreve os campos de nível superior em cada entrada de registro.


**Top-level campos**  

| Nome | Valor de exemplo | Obrigatório | Observações | 
| --- | --- | --- | --- | 
| resource\_id | "pcs\_22l8nzr3t9" | Sim | O ID do cluster AWS PCS | 
| resource\_type | "PCS\_CLUSTER" | Sim | Sempre "PCS\_CLUSTER" | 
| event\_timestamp | 1789179816460 | Sim | Época Unix: milissegundos em que o evento ocorreu | 
| compute\_node\_group\_id | "pcs\_56zr33g8" | Sim | O grupo de nós de computação ao qual o nó pertence | 
| scheduler\_node\_id | "compute-1" | Sim | O ID do nó do agendador | 
| status\_code | "LAUNCH\_FAILED" | Sim | O novo status do nó. Consulte [Códigos de status e códigos de motivo](#monitoring_scaling_logs-status-codes-and-reason-codes) | 
| reason\_code | "INSUFFICIENT\_CAPACITY" | Sim | Por que a transição aconteceu | 
| description | "The launch failed because EC2 did not have enough capacity" | Sim | Um resumo legível por humanos derivado dos códigos de status e motivo | 
| details | {...} | Não | Contexto adicional para a transição. As chaves dependem do tipo de transição | 

A tabela a seguir descreve as chaves que podem aparecer dentro do `details` objeto.


**Campos dentro do `objeto de` detalhes**  

| Nome | Valor de exemplo | Obrigatório | Observações | 
| --- | --- | --- | --- | 
| instance\_id | "i-0abcdef01234567a" | Não | A instância do EC2 associada ao nó. Ausente quando nenhuma instância está associada, como após uma falha de inicialização | 
| ec2\_error\_code | "InsufficientInstanceCapacity" | Não | O código de erro do EC2 para uma falha na inicialização. O mesmo código aparece no CloudTrail registro da CreateFleet chamada em sua conta | 
| instance\_type | "t4g.micro" | Não | O tipo de instância lançado | 
| subnet\_id | "subnet-0abc123" | Não | A sub-rede alvo do lançamento | 

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

O `status_code` campo informa o estado em que o nó entrou. O `reason_code` campo explica o porquê. Por exemplo, um `LAUNCH_FAILED` status com um `INSUFFICIENT_CAPACITY` motivo significa que o Amazon EC2 não pôde fornecer capacidade para o tipo de instância solicitado na sub-rede de destino. A `LIMIT_EXCEEDED` significa que uma cota do Amazon EC2 bloqueou o lançamento.


**Códigos de status e códigos de motivo**  

| Código de status | Código do motivo | Description | 
| --- | --- | --- | 
| LAUNCHED | SCHEDULER\_REQUESTED | Instância iniciada para atender a uma solicitação de aumento de escala do agendador | 
| LAUNCHED | MAINTAIN\_MIN\_CAPACITY | Instância lançada para manter a capacidade mínima do grupo de nós | 
| REGISTERED | REGISTER\_SUCCESS | Node registrado com sucesso por meio do agente PCS | 
| ACTIVE | BOOTSTRAP\_SUCCESS | A inicialização do Node foi concluída; o slurmd está executando e aceitando trabalhos | 
| PENDING\_REPLACEMENT | NODE\_GROUP\_UPDATE | O Node está se esgotando antes de ser desligado para uma atualização do grupo de nós | 
| PENDING\_REPLACEMENT | EC2\_HEALTH\_CHECK\_FAILED | O nó está se esgotando porque uma verificação de integridade do nó ou de sua instância falhou | 
| PENDING\_REPLACEMENT | EC2\_SCHEDULED\_EVENT | O Node está se esgotando porque sua instância tem um evento de manutenção do EC2 agendado | 
| LAUNCH\_FAILED | INSUFFICIENT\_CAPACITY | O Node não obteve uma instância porque não havia capacidade suficiente disponível | 
| LAUNCH\_FAILED | LIMIT\_EXCEEDED | Falha na inicialização da instância porque uma cota de conta foi excedida | 
| LAUNCH\_FAILED | LAUNCH\_ERROR | O Node falhou ao iniciar sua instância | 
| TERMINATED | SCHEDULER\_REQUESTED | Instância encerrada após o agendador liberar o nó (tempo limite de inatividade ou desligamento) | 
| TERMINATED | UNHEALTHY\_NODE | A instância foi encerrada porque o agendador relatou que o nó não estava íntegro | 
| TERMINATED | BOOTSTRAP\_FAILED | A instância foi encerrada porque o nó falhou ao inicializar | 
| TERMINATED | EXTERNALLY\_TERMINATED | A instância foi encerrada fora do PCS; o nó foi liberado para que pudesse ser substituído | 
| TERMINATED | REPLACEMENT\_REQUESTED | A instância foi encerrada porque o nó foi drenado para substituição | 
| TERMINATED | NODE\_GROUP\_DELETION | Instância encerrada como parte da exclusão do grupo de nós de computação | 
| TERMINATE\_FAILED | EC2\_OPERATION\_NOT\_PERMITTED | Falha no encerramento da instância. Certifique-se de que a proteção contra encerramento não esteja ativada na instância | 
| TERMINATE\_FAILED | EC2\_ERROR | Falha no encerramento da instância | 

## Exemplos de registros de escalabilidade
<a name="monitoring_scaling-logs_example"></a>

O exemplo a seguir mostra o lançamento bem-sucedido de uma instância:

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

O exemplo a seguir mostra uma falha de inicialização causada pela capacidade insuficiente do EC2. Não `instance_id` está presente porque nenhuma instância foi iniciada.

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