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:

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.

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 AWS Management Console, 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.

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 e métricas do sistema de arquivos de contêiner não são compatíves com o cadvisor para containerd 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 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

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.

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