# Solução de problemas do Container Insights
As seções a seguir podem ajudar se você estiver tendo problemas com o Container Insights.
## Falha na implantação no Amazon EKS ou no Kubernetes
Se o atendente não for implantado corretamente em um cluster do Kubernetes, tente o seguinte:
+ Execute o comando a seguir para obter a lista de pods.
```
kubectl get pods -n amazon-cloudwatch
```
+ Execute o comando a seguir e verifique os eventos na parte inferior da saída.
```
kubectl describe pod pod-name -n amazon-cloudwatch
```
+ Execute o comando a seguir para verificar os logs.
```
kubectl logs pod-name -n amazon-cloudwatch
```
## Pânico não autorizado: não é possível recuperar dados cadvisor do kubelet
Se a implantação falhar com o erro `Unauthorized panic: Cannot retrieve cadvisor data from kubelet`, o kubelet talvez não tenha o modo de autorização Webhook habilitado. Esse modo é necessário para o Container Insights. Para obter mais informações, consulte [Verificação dos pré-requisitos para o Container Insights no CloudWatch](Container-Insights-prerequisites.md).
## Implantar o Container Insights em um cluster excluído e recriado no Amazon ECS
Se você excluir um cluster existente do Amazon ECS que não tenha o Container Insights habilitado e recriá-lo com o mesmo nome, não será possível habilitar o Container Insights nesse novo cluster ao recriá-lo. Você pode habilitá-lo recriando-o e inserindo o seguinte comando:
```
aws ecs update-cluster-settings --cluster myCICluster --settings name=container Insights,value=enabled
```
## Erro de endpoint inválido
Se você vir uma mensagem de erro semelhante à seguinte, verifique se você substituiu todos os espaços reservados, como *cluster-name* e *region-name* nos comandos que você está usando pelas informações corretas para sua implantação.
```
"log": "2020-04-02T08:36:16Z E! cloudwatchlogs: code: InvalidEndpointURL, message: invalid endpoint uri, original error: &url.Error{Op:\"parse\", URL:\"https://logs.{{region_name}}.amazonaws.com/\", Err:\"{\"}, &awserr.baseError{code:\"InvalidEndpointURL\", message:\"invalid endpoint uri\", errs:[]error{(*url.Error)(0xc0008723c0)}}\n",
```
## As métricas não são exibidas no console
Se você não vir nenhuma métrica do Container Insights no Console de gerenciamento da AWS, certifique-se de que você tenha concluído a configuração do Container Insights. As métricas não serão exibidas antes de o Container Insights ser configurado completamente. Para obter mais informações, consulte [Configurar o Container Insights](deploy-container-insights.md).
## Métricas de pod ausentes no Amazon EKS ou no Kubernetes após a atualização do cluster
Esta seção pode ser útil se todas ou algumas métricas de pods estiverem ausentes depois de você implantar o agente do CloudWatch como daemonset em um cluster novo ou atualizado, ou se você vir um log de erros com a mensagem `W! No pod metric collected`.
Esses erros podem ser causados por alterações no runtime do contêiner, como containerd ou o driver cgroup systemd do docker. Normalmente, você pode resolver isso atualizando seu manifesto de implantação para que o soquete containerd do host seja montado no contêiner. Veja o exemplo a seguir:
```
# For full example see https://github.com/aws-samples/amazon-cloudwatch-container-insights/blob/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/cwagent/cwagent-daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: cloudwatch-agent
namespace: amazon-cloudwatch
spec:
template:
spec:
containers:
- name: cloudwatch-agent
# ...
# Don't change the mountPath
volumeMounts:
# ...
- name: dockersock
mountPath: /var/run/docker.sock
readOnly: true
- name: varlibdocker
mountPath: /var/lib/docker
readOnly: true
- name: containerdsock # NEW mount
mountPath: /run/containerd/containerd.sock
readOnly: true
# ...
volumes:
# ...
- name: dockersock
hostPath:
path: /var/run/docker.sock
- name: varlibdocker
hostPath:
path: /var/lib/docker
- name: containerdsock # NEW volume
hostPath:
path: /run/containerd/containerd.sock
```
## Nenhuma métrica de pod ao usar Bottlerocket para o Amazon EKS
O Bottlerocket é um sistema operacional de código aberto baseado em Linux que foi criado especificamente pela AWS para executar contêineres.
O Bottlerocket usa um caminho de `containerd` diferente no host, então é necessário alterar os volumes para o local dele. Se não fizer isso, você verá um erro nos logs que inclui `W! No pod metric collected`. Veja o exemplo a seguir.
```
volumes:
# ...
- name: containerdsock
hostPath:
# path: /run/containerd/containerd.sock
# bottlerocket does not mount containerd sock at normal place
# https://github.com/bottlerocket-os/bottlerocket/commit/91810c85b83ff4c3660b496e243ef8b55df0973b
path: /run/dockershim.sock
```
## Nenhuma métrica do filesystem de contêiner ao usar o runtime do containerd para Amazon EKS ou Kubernetes
Esse é um problema conhecido, e colaboradores da comunidade estão trabalhando nele. Para obter mais informações, consulte [Métrica de uso de disco para conteinerd](https://github.com/google/cadvisor/issues/2785) e [métricas do sistema de arquivos de contêiner não são compatíves com o cadvisor para containerd](https://github.com/aws/amazon-cloudwatch-agent/issues/192) no GitHub.
## Aumento inesperado do volume de log do atendente do CloudWatch ao coletar métricas do Prometheus
Essa foi uma regressão introduzida na versão 1.247347.6b250880 do atendente do CloudWatch. Essa regressão já foi corrigida em versões mais recentes do atendente. Seu impacto foi limitado a cenários em que os clientes coletavam os logs do próprio atendente do CloudWatch e estavam usando o Prometheus. Para obter mais informações, consulte [atendente [do prometheus] está imprimindo todas as métricas extraídas no log](https://github.com/aws/amazon-cloudwatch-agent/issues/209) no GitHub.
## A imagem do Docker mais recente mencionada nas notas de release não foi encontrada no Dockerhub
Atualizamos a nota de release e a etiqueta no Github antes de iniciarmos a versão real internamente. Normalmente, leva de 1 a 2 semanas para ver a imagem do Docker mais recente nos registros depois de bater o número da versão no Github. Não há versão noturna para a imagem do contêiner do atendente do CloudWatch. É possível criar a imagem diretamente da origem no seguinte local: [https://github.com/aws/amazon-cloudwatch-agent/tree/main/amazon-cloudwatch-container-insights/cloudwatch-agent-dockerfile](https://github.com/aws/amazon-cloudwatch-agent/tree/main/amazon-cloudwatch-container-insights/cloudwatch-agent-dockerfile)
## Erro CrashLoopBackoff no atendente do CloudWatch
Ao ver um erro `CrashLoopBackOff` do atendente do CloudWatch, verifique se suas permissões do IAM estão definidas corretamente. Para obter mais informações, consulte [Verificação dos pré-requisitos para o Container Insights no CloudWatch](Container-Insights-prerequisites.md).
## Agente do CloudWatch ou pod do Fluentd travado em pendente
Se você tiver um agente do CloudWatch ou pod do Fluentd travado em `Pending` ou com um erro `FailedScheduling`, determine se seus nós têm recursos de computação suficientes com base no número de núcleos e na quantidade de RAM exigida pelos agentes. Use o comando a seguir para descrever o pod:
```
kubectl describe pod cloudwatch-agent-85ppg -n amazon-cloudwatch
```