# Container Insights 문제 해결
Container Insights에 문제가 있는 경우 다음 단원을 참조하면 도움이 됩니다.
## Amazon EKS 또는 Kubernetes에서 배포 실패
에이전트가 Kubernetes 클러스터에 올바르게 배포하지 않는 경우 다음을 수행해 보세요.
+ 다음 명령을 실행하여 Pod 목록을 가져옵니다.
```
kubectl get pods -n amazon-cloudwatch
```
+ 다음 명령을 실행하고 출력 하단에서 이벤트를 확인합니다.
```
kubectl describe pod pod-name -n amazon-cloudwatch
```
+ 다음 명령을 실행하여 로그를 확인합니다.
```
kubectl logs pod-name -n amazon-cloudwatch
```
## 권한이 없는 패닉: Kubelet에서 cadvisor 데이터를 검색할 수 없음
`Unauthorized panic: Cannot retrieve cadvisor data from kubelet` 오류가 표시되면서 배포에 실패한 경우 kubelet 에 Webhook 인증 모드가 활성화되어 있지 않을 수 있습니다. 이는 Container Insights에 필요한 모드입니다. 자세한 내용은 [CloudWatch에서 Container Insights에 대한 사전 요구 사항 확인](Container-Insights-prerequisites.md) 섹션을 참조하세요.
## 삭제하고 다시 생성한 Amazon ECS의 클러스터에 Container Insights 배포
Container Insights가 사용되지 않은 기존 Amazon ECS 클러스터를 삭제하고 같은 이름으로 다시 생성하는 경우 다시 생성하는 시점에는 이 새 클러스터에서 Container Insights를 사용할 수 없습니다. 다시 생성한 후 다음 명령을 입력해야만 활성화할 수 있습니다.
```
aws ecs update-cluster-settings --cluster myCICluster --settings name=container Insights,value=enabled
```
## 잘못된 엔드포인트 오류
다음과 유사한 오류 메시지가 표시되는 경우 사용하는 명령의 *cluster-name* 및 *region-name* 같은 자리 표시자를 모두 배포에 해당하는 올바른 정보로 바꿨는지 확인합니다.
```
"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",
```
## 콘솔에 지표가 나타나지 않음
AWS Management Console에 Container Insights 지표가 보이지 않는 경우 Container Insights 설정을 완료했는지 확인합니다. Container Insights가 완전히 설정되지 않으면 지표가 나타나지 않습니다. 자세한 내용은 [Container Insights 설정](deploy-container-insights.md) 섹션을 참조하세요.
## 클러스터를 업그레이드한 후 Amazon EKS 또는 Kubernetes에서 포드 지표가 누락됨
이 섹션은 CloudWatch 에이전트를 새 클러스터 또는 업그레이드된 클러스터에 DaemonSet로 배포한 후 전체 또는 일부 포드 지표가 누락되거나 `W! No pod metric collected` 메시지와 함께 오류 로그가 표시되는 경우에 유용할 수 있습니다.
이러한 오류는 containerd 또는 docker systemd cgroup 드라이버와 같은 컨테이너 런타임의 변경으로 인해 발생할 수 있습니다. 일반적으로 호스트의 containerd 소켓이 컨테이너에 탑재되도록 배포 매니페스트를 업데이트함으로써 이 문제를 해결할 수 있습니다. 다음 예를 참조하세요.
```
# 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
```
## Amazon EKS에 Bottlerocket을 사용할 때 포드 지표가 없음
Bottlerocket은 AWS에서 컨테이너를 실행하기 위해 특별히 구축한 Linux 기반 오픈 소스 운영 체제입니다.
Bottlerocket은 호스트에서 다른 `containerd` 경로를 사용하므로 볼륨을 해당 위치로 변경해야 합니다. 그러지 않으면 `W! No pod metric collected`가 포함된 오류가 로그에 표시됩니다. 다음 예제를 참조하세요.
```
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
```
## Amazon EKS 또는 Kubernetes에 containerd 런타임을 사용할 때 컨테이너 파일 시스템 지표가 없음
이는 알려진 문제이며, 커뮤니티 기여자가 이 문제를 해결하기 위해 노력하고 있습니다. 자세한 내용은 GitHub에서 [containerd의 디스크 사용량 지표](https://github.com/google/cadvisor/issues/2785) 및 [containerd용 cadvisor에서 컨테이너 파일 시스템 지표를 지원하지 않음](https://github.com/aws/amazon-cloudwatch-agent/issues/192)을 참조하세요.
## Prometheus 지표를 수집할 때 CloudWatch 에이전트에서 예상치 못한 로그 볼륨 증가
이는 CloudWatch 에이전트 버전 1.247347.6b250880에 도입된 회귀였습니다. 이 회귀는 최신 버전의 에이전트에서 이미 수정되었습니다. 따라서 이 문제의 영향은 고객이 CloudWatch 에이전트 자체의 로그를 수집하고 Prometheus도 사용하는 시나리오로 제한되었습니다. 자세한 내용은 GitHub에서 [[prometheus] 에이전트가 로그에 스크레이프한 모든 지표를 인쇄하고 있음](https://github.com/aws/amazon-cloudwatch-agent/issues/209)을 참조하세요.
## 릴리스 정보에 언급된 최신 Docker 이미지를 DockerHub에서 찾을 수 없음
내부적으로 실제 릴리스를 시작하기 전에 Github에서 릴리스 정보와 태그를 업데이트합니다. Github에 버전 번호를 올린 후 레지스트리에서 최신 Docker 이미지를 확인하는 데 일반적으로 1\$12주가 걸립니다. CloudWatch 에이전트 컨테이너 이미지에 대한 야간 릴리스는 없습니다. 다음 위치의 소스에서 직접 이미지를 구축할 수 있습니다. [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)
## CloudWatch 에이전트의 CrashLoopBackoff 오류
CloudWatch 에이전트에 대해 `CrashLoopBackOff` 오류가 표시되면 IAM 권한이 정확하게 설정되어 있는지 확인합니다. 자세한 내용은 [CloudWatch에서 Container Insights에 대한 사전 요구 사항 확인](Container-Insights-prerequisites.md) 섹션을 참조하세요.
## CloudWatch 에이전트 또는 Fluentd 포드가 보류 상태에서 멈춤
`Pending` 상태에서 멈춰 있거나 `FailedScheduling` 오류가 있는 CloudWatch 에이전트 또는 Fluentd 포드가 있는 경우 에이전트에 필요한 코어 수와 RAM 양을 기반으로 노드에 충분한 컴퓨팅 리소스가 있는지 확인합니다. 다음 명령을 입력하여 Pod를 설명합니다.
```
kubectl describe pod cloudwatch-agent-85ppg -n amazon-cloudwatch
```