# 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](Container-Insights-prerequisites.md).
## 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 Consola de administración de AWS, 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](deploy-container-insights.md).
## 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](https://github.com/google/cadvisor/issues/2785) (Métrica de uso de disco para containerd) y [container file system metrics is not supported by cadvisor for containerd](https://github.com/aws/amazon-cloudwatch-agent/issues/192) (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](https://github.com/aws/amazon-cloudwatch-agent/issues/209) ([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](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](Container-Insights-prerequisites.md).
## 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
```