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á.
# Solução de problemas do complemento de SageMaker HyperPod observabilidade da Amazon
Use as orientações a seguir para resolver problemas comuns com o complemento de observabilidade Amazon SageMaker HyperPod (SageMaker HyperPod).
## Solucionar problemas de métricas ausentes no Amazon Managed Grafana
Se as métricas não aparecerem nos painéis do Amazon Managed Grafana, execute as etapas a seguir para identificar e resolver o problema.
### Verificar a conexão do Amazon Managed Service for Prometheus-Amazon Managed Grafana
1. Faça login no console do Amazon Managed Grafana.
1. No painel à esquerda, escolha **Todos os espaços de trabalho**.
1. Na tabela **Espaços de trabalho**, escolha seu espaço de trabalho.
1. Na página de detalhes do espaço de trabalho, escolha a guia **Fontes de dados**.
1. Verifique se a fonte de dados do Amazon Managed Service for Prometheus existe.
1. Verifique as configurações de conexão:
+ Confirme se o URL do endpoint está correto.
+ Verifique se a autenticação do IAM está configurada corretamente.
+ Selecione **Test connection (Testar conexão)**. Verifique se o status é **A fonte de dados está funcionando**.
### Verificar o status do complemento do Amazon EKS
1. Abra o console do Amazon EKS em [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Selecione o cluster
1. Escolha a guia **Add-ons** (Complementos).
1. **Verifique se o complemento SageMaker HyperPod de observabilidade está listado e se seu status é ATIVO.**
1. Se o status não for **ATIVO**, consulte [Solucionar problemas de falha na instalação do complemento](#troubleshooting-addon-installation-failures).
### Verificar a associação de Identidade de Pods
1. Abra o console do Amazon EKS em [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Selecione o cluster
1. Na página de detalhes do cluster, escolha a guia **Acesso**.
1. Na tabela de **Associações de Identidade de Pods**, escolha a associação que tem os seguintes valores de propriedade:
+ **Namespace**: `hyperpod-observability`
+ **Conta de serviço**: `hyperpod-observability-operator-otel-collector`.
+ **Complemento**: `amazon-sagemaker-hyperpod-observability`.
1. O perfil do IAM anexado a essa associação deve ter as permissões a seguir.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PrometheusAccess",
"Effect": "Allow",
"Action": "aps:RemoteWrite",
"Resource": "arn:aws:aps:us-east-1:111122223333:workspace/workspace-ID"
},
{
"Sid": "CloudwatchLogsAccess",
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams",
"logs:PutLogEvents",
"logs:GetLogEvents",
"logs:FilterLogEvents",
"logs:GetLogRecord",
"logs:StartQuery",
"logs:StopQuery",
"logs:GetQueryResults"
],
"Resource": [
"arn:aws:logs:us-east-1:111122223333:log-group:/aws/sagemaker/Clusters/*",
"arn:aws:logs:us-east-1:111122223333:log-group:/aws/sagemaker/Clusters/*:log-stream:*"
]
}
]
}
```
------
1. O perfil do IAM anexado a essa associação tem a política de confiança a seguir. Verifique se o ARN de origem e a conta de origem estão corretos.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:cluster/cluster-name",
"aws:SourceAccount": "111122223333"
}
}
}
]
}
```
------
### Verificar o controle de utilização do Amazon Managed Service for Prometheus
1. Faça login Console de gerenciamento da AWS e abra o console Service Quotas em. [https://console.aws.amazon.com/servicequotas/](https://console.aws.amazon.com/servicequotas/)
1. Na caixa **Cotas gerenciadas**, pesquise e selecione Amazon Managed Service for Prometheus.
1. Escolha a cota **Série ativa por espaço de trabalho**.
1. Na guia **Cotas em nível de recurso**, selecione seu espaço de trabalho do Amazon Managed Service for Prometheus.
1. A utilização deve ser menor que a cota atual.
1. Se você atingiu o limite de cota, selecione seu espaço de trabalho escolhendo o botão de rádio à esquerda e, em seguida, selecione **Solicitar aumento no nível de recurso**.
### Verifique se o cache KV e o roteamento inteligente estão habilitados
Se o `KVCache Metrics` painel estiver ausente, o recurso não está ativado ou a porta não é mencionada no`modelMetrics`. Para obter mais informações sobre como habilitar isso, consulte as etapas 1 e 3 em[Configure o cache KV e o roteamento inteligente para melhorar o desempenho](sagemaker-hyperpod-model-deployment-deploy-ftm.md#sagemaker-hyperpod-model-deployment-deploy-ftm-cache-route).
Se o `Intelligent Router Metrics` painel estiver ausente, ative o recurso para que eles apareçam. Para obter mais informações sobre como habilitar isso, consulte[Configure o cache KV e o roteamento inteligente para melhorar o desempenho](sagemaker-hyperpod-model-deployment-deploy-ftm.md#sagemaker-hyperpod-model-deployment-deploy-ftm-cache-route).
## Solucionar problemas de falha na instalação do complemento
Se a instalação do complemento de observabilidade falhar, use as etapas a seguir para diagnosticar e resolver o problema.
### Verificar o status da sonda de integridade
1. Abra o console do Amazon EKS em [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Selecione o cluster
1. Escolha a guia **Add-ons** (Complementos).
1. Escolha o complemento que falhou.
1. Analise a seção **Problemas de integridade**.
1. Se o problema de integridade estiver relacionado a credenciais ou à identidade de pods, consulte [Verificar a associação de Identidade de Pods](#verify-pod-identity-association). Além disso, o complemento Agente de Identidade de Pods deve estar em execução no cluster.
1. Verifique se há erros nos logs do gerenciador. Para instruções, consulte [Analisar logs do gerenciador](#review-manager-logs).
1. Entre em contato com o AWS Support com os detalhes do problema.
### Analisar logs do gerenciador
1. Obtenha o pod do gerenciador de complementos:
```
kubectl logs -n hyperpod-observability -l control-plane=hyperpod-observability-controller-manager
```
1. Para problemas urgentes, entre em contato com o Suporte.
## Analisar todos os pods de observabilidade
Todos os pods que o complemento de SageMaker HyperPod observabilidade cria estão no namespace. `hyperpod-observability` Para ver o status desses pods, execute o comando a seguir.
```
kubectl get pods -n hyperpod-observability
```
Procure os pods com status `pending` ou `crashloopbackoff`. Execute o comando a seguir para obter os logs desses pods pendentes ou com falha.
```
kubectl logs -n hyperpod-observability pod-name
```
Se você não encontrar erros nos logs, execute o comando a seguir para descrever os pods e procurar erros.
```
kubectl describe -n hyperpod-observability pod pod-name
```
Para ter mais contexto, execute os dois comandos a seguir para descrever as implantações e os daemonsets desses pods.
```
kubectl describe -n hyperpod-observability deployment deployment-name
```
```
kubectl describe -n hyperpod-observability daemonset daemonset-name
```
## Solucionar problemas de pods que estão parados no status pendente
Se você perceber que há pods que estão parados no status `pending`, verifique se o nó é grande o suficiente para conter todos os pods. Para verificar isso, execute as etapas a seguir.
1. Abra o console do Amazon EKS em [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Escolha seu cluster.
1. Escolha a guia **Computação** do cluster.
1. Escolha o nó com o menor tipo de instância.
1. Na seção de alocação de capacidade, procure os pods disponíveis.
1. Se não houver pods disponíveis, você precisará de um tipo de instância maior.
Para problemas urgentes, entre em contato com o AWS Support.
## Solução de problemas de observabilidade em grupos de instâncias restritas
Use as diretrizes a seguir para resolver problemas específicos de clusters com grupos de instâncias restritas.
### Os pods de observabilidade não iniciam em nós restritos
Se os pods de observabilidade não estiverem iniciando em nós restritos, verifique o status e os eventos do pod:
```
kubectl get pods -n hyperpod-observability -o wide
kubectl describe pod pod-name -n hyperpod-observability
```
As causas comuns incluem:
+ **Falhas na extração de imagem: os** eventos do pod podem mostrar erros de extração de imagem se as imagens do contêiner de observabilidade ainda não estiverem na lista de permissões nos nós restritos. Verifique se você está executando a versão mais recente do complemento de observabilidade. Se o problema persistir após a atualização, entre em contato com. Suporte
+ **Tolerâncias de contaminação:** verifique se a especificação do pod inclui a tolerância necessária para nós restritos. O complemento a partir da versão adiciona `v1.0.5-eksbuild.1` automaticamente essa tolerância quando o suporte ao RIG está ativado. Se você estiver usando uma versão mais antiga, atualize para a versão mais recente.
### Visualização de registros de pods em nós restritos
O `kubectl logs` comando não funciona para pods executados em nós restritos. Essa é uma limitação esperada porque o caminho de comunicação necessário para o streaming de registros não está disponível em nós restritos.
Para visualizar registros de nós restritos, use o painel **Cluster Logs** no Amazon Managed Grafana, que consulta CloudWatch os Logs diretamente. Você pode filtrar por ID de instância, fluxo de registros, nível de registro e pesquisa de texto livre para encontrar entradas de registro relevantes.
### Falhas de resolução de DNS em clusters com nós padrão e restritos
Em clusters híbridos (clusters com grupos de instâncias padrão e restritos), pods em nós padrão podem ter tempos limite de resolução de DNS ao tentar alcançar endpoints de serviço, como Amazon AWS Managed Service for Prometheus ou. CloudWatch
**Causa:** o `kube-dns` serviço tem endpoints de pods CoreDNS padrão e pods RIG CoreDNS. Os pods de nós padrão não podem alcançar os endpoints RIG CoreDNS devido ao isolamento da rede. Quando `kube-proxy` balanceia a carga de uma solicitação de DNS de um pod de nós padrão para um endpoint RIG CoreDNS, a solicitação expira.
**Resolução:** configure o `kube-dns` serviço para que os pods só `internalTrafficPolicy: Local` alcancem o CoreDNS em seu nó local:
```
kubectl patch svc kube-dns -n kube-system -p '{"spec":{"internalTrafficPolicy":"Local"}}'
```
Depois de aplicar esse patch, reinicie os pods de observabilidade afetados:
```
kubectl delete pods -n hyperpod-observability -l app.kubernetes.io/name=hyperpod-node-collector
```
### Métricas de nós restritos que não atingem o Amazon Managed Service para Prometheus
Se as métricas de nós restritos não estiverem aparecendo em seu espaço de trabalho do Amazon Managed Service for Prometheus:
1. **Verifique as permissões da função de execução.** Certifique-se de que a função de execução do Grupo de Instâncias Restritas tenha `aps:RemoteWrite` permissão para seu espaço de trabalho do Prometheus. Para obter mais informações, consulte [Pré-requisitos adicionais para grupos de instâncias restritas](hyperpod-observability-addon-setup.md#hyperpod-observability-addon-rig-prerequisites).
1. **Verifique o status do pod coletor de nós.** Execute o comando a seguir e verifique se os pods coletores de nós estão sendo executados em nós restritos:
```
kubectl get pods -n hyperpod-observability | grep node-collector
```
1. **Verifique as implantações do coletor central.** Em clusters com nós restritos, o complemento implanta um coletor central por limite de rede. Verifique se existe um coletor central para cada limite:
```
kubectl get deployments -n hyperpod-observability | grep central-collector
```
1. **Verifique se há erros nos eventos do pod.** Use `kubectl describe` nos pods coletores para procurar eventos de erro:
```
kubectl describe pod collector-pod-name -n hyperpod-observability
```
Se o problema persistir após a verificação acima, entre em contato com. Suporte
### A verificação de identidade do pod não se aplica a nós de grupos de instâncias restritos
As etapas [Verificar a associação de Identidade de Pods](#verify-pod-identity-association) de solução de problemas se aplicam somente aos nós padrão. Em nós restritos, o complemento usa a função de execução do grupo de instâncias de cluster para AWS autenticação em vez do Amazon EKS Pod Identity. Se faltarem métricas nos nós restritos, verifique as permissões da função de execução em vez da associação do Pod Identity.
### O Fluent Bit não está sendo executado em nós restritos
Esse comportamento é esperado. O FluentBit não é implantado intencionalmente em nós restritos. Os registros de nós restritos são publicados CloudWatch por meio da SageMaker HyperPod plataforma, independentemente do complemento de observabilidade. Use o painel **Cluster Logs** no Amazon Managed Grafana para visualizar esses registros.