Solución de problemas de Información de contenedores - Amazon CloudWatch
Error de implementación en Amazon EKS o KubernetesPánico no autorizado: no se puede recuperar datos de cadvisor desde kubeletImplementación de Información de contenedores en un clúster que se eliminó y recreó en Amazon ECSError de punto de enlace inválidoLas métricas no aparecen en la consolaFaltan métricas de pod en Amazon EKS o en Kubernetes después de actualizar el clústerNo hay métricas de pod cuando se utiliza Bottlerocket para Amazon EKSNo hay métricas del sistema de archivos de contenedor cuando se utiliza el tiempo de ejecución containerd para Amazon EKS o KubernetesAumento inesperado del volumen de registro del agente de CloudWatch al recopilar métricas de PrometheusLa última imagen de docker mencionada en las notas de la versión que no se encontró en DockerhubError de CrashLoopBackoff en el agente de CloudWatchAgente de CloudWatch o pod FluentD bloqueado en pendiente

Solución de problemas de Información de contenedores

Las siguientes secciones pueden servir de ayuda si está teniendo problemas con Información de contenedores.

Error de implementación en Amazon EKS o Kubernetes

Si el agente no se implementa correctamente en un clúster de Kubernetes, pruebe lo siguiente:

  • Ejecute el siguiente comando para obtener la lista de pods.

    kubectl get pods -n amazon-cloudwatch

  • Ejecute el siguiente comando y compruebe los eventos de la parte inferior de la salida.

    kubectl describe pod pod-name -n amazon-cloudwatch

  • Ejecute el siguiente comando para comprobar los registros.

    kubectl logs pod-name -n amazon-cloudwatch

Pánico no autorizado: no se puede recuperar datos de cadvisor desde kubelet

Si su implementación falla con el error Unauthorized panic: Cannot retrieve cadvisor data from kubelet, su kubelet podría no tener el modo de autorización Webhook habilitado. Este modo es obligatorio para Información de contenedores. Para obtener más información, consulte Verificación de los requisitos previos de Información de contenedores en CloudWatch.

Implementación de Información de contenedores en un clúster que se eliminó y recreó en Amazon ECS

Si elimina un clúster de Amazon ECS existente que no tiene habilitado Información de contenedores y lo vuelve a crear con el mismo nombre, no podrá habilitar Información de contenedores en ese nuevo clúster en el momento de volver a crearlo. Puede habilitarlo si lo vuelve a crear y, a continuación, escribe el siguiente comando:

aws ecs update-cluster-settings --cluster myCICluster --settings name=container Insights,value=enabled

Error de punto de enlace inválido

Si aparece un mensaje de error similar al siguiente, compruebe que ha reemplazado todos los marcadores de posición, como nombre-clúster y nombre-región, por la información correcta para la implementación en los comandos que utiliza.

"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",

Las métricas no aparecen en la consola

Si no ve ningún métrica de Información de contenedores en la AWS Management Console, asegúrese de haber completado la configuración de Información de contenedores. Las métricas no aparecen antes de haber configurado por completo Información de contenedores. Para obtener más información, consulte Configuración de Información de contenedores.

Faltan métricas de pod en Amazon EKS o en Kubernetes después de actualizar el clúster

Esta sección puede ser útil si faltan todas o algunas métricas de pod después de implementar el agente de CloudWatch como un conjunto de daemons en un clúster nuevo o actualizado, o si ve un registro de errores con el mensaje W! No pod metric collected.

Estos errores pueden deberse a cambios en el tiempo de ejecución del contenedor, como containerd o el controlador docker systemd cgroup. Por lo general, puede resolverlo mediante la actualización del manifiesto de implementación para que el socket containerd del host esté montado en el contenedor. Vea el siguiente ejemplo:

# 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

No hay métricas de pod cuando se utiliza Bottlerocket para Amazon EKS

Bottlerocket es un sistema operativo de código abierto basado en Linux que está diseñado específicamente por AWS para ejecutar contenedores.

Bottlerocket utiliza una ruta diferente containerd en el host, por lo que debe cambiar los volúmenes a la ubicación. De lo contrario, aparece un error en los registros que incluye W! No pod metric collected. Consulte el siguiente ejemplo.

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

No hay métricas del sistema de archivos de contenedor cuando se utiliza el tiempo de ejecución containerd para Amazon EKS o Kubernetes

Se trata de un problema conocido y los colaboradores de la comunidad lo están tratando. Para obtener más información, consulte Disk usage metric for containerd (Métrica de uso de disco para containerd) y container file system metrics is not supported by cadvisor for containerd (métricas del sistema de archivos de contenedor no son compatibles con cadvisor para containerd) en GitHub.

Aumento inesperado del volumen de registro del agente de CloudWatch al recopilar métricas de Prometheus

Esta fue una regresión que se presentó en la versión 1.247347.6b250880 del agente CloudWatch. Esta regresión ya se ha corregido en versiones más recientes del agente. Su impacto se limitó a situaciones en las que los clientes recopilaban los registros del propio agente de CloudWatch y también utilizaban Prometheus. Para obtener más información, consulte [prometheus] agent is printing all the scraped metrics in log ([prometheus] el agente está imprimiendo todas las métricas raspadas en el registro) en GitHub.

La última imagen de docker mencionada en las notas de la versión que no se encontró en Dockerhub

Hemos actualizado la nota de la versión y la etiqueta en Github antes de comenzar la versión real internamente. Por lo general, toma 1 o 2 semanas ver la última imagen de docker en los registros después de que se actualizó el número de versión en Github. No hay ninguna versión nocturna para la imagen del contenedor del agente de CloudWatch. Puede crear la imagen directamente desde la fuente en la siguiente ubicación: https://github.com/aws/amazon-cloudwatch-agent/tree/main/amazon-cloudwatch-container-insights/cloudwatch-agent-dockerfile

Error de CrashLoopBackoff en el agente de CloudWatch

Si ve un error CrashLoopBackOff del agente de CloudWatch, asegúrese de que los permisos de IAM estén establecidos correctamente. Para obtener más información, consulte Verificación de los requisitos previos de Información de contenedores en CloudWatch.

Agente de CloudWatch o pod FluentD bloqueado en pendiente

Si dispone de un agente de CloudWatch o un pod Fluentd bloqueado en Pending o con un error FailedScheduling, determine si los nodos tienen suficientes recursos informáticos en función del número de núcleos y la cantidad de RAM que necesitan los agentes. Especifique el siguiente comando para describir el pod:

kubectl describe pod cloudwatch-agent-85ppg -n amazon-cloudwatch