本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 針對容器洞見進行故障診斷
<a name="ContainerInsights-troubleshooting"></a>

若您在使用容器洞見時發生問題，下列各節可協助您。

## 在 Amazon EKS 或 Kubernetes 上部署失敗
<a name="ContainerInsights-setup-EKS-troubleshooting-general"></a>

若代理程式無法正確地在 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 資料
<a name="ContainerInsights-setup-EKS-troubleshooting-permissions"></a>

如果部署失敗，並出現錯誤 `Unauthorized panic: Cannot retrieve cadvisor data from kubelet`，您的 kubelet 可能還沒有啟用 Webhook 授權模式。容器洞見需要使用此模式。如需詳細資訊，請參閱[在 CloudWatch 中驗證 Container Insights 的先決條件](Container-Insights-prerequisites.md)。

## 在 Amazon ECS 上已刪除和重新建立的叢集上部署 Container Insights
<a name="ContainerInsights-troubleshooting-recreate"></a>

若您刪除未啟用 Container Insights 的現有 Amazon ECS 叢集，且您使用相同的名稱將其重新建立，則您無法在重新建立此新叢集時在其上啟用 Container Insights。您可以透過重新建立它，然後輸入以下命令來進行啟用：

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

## 無效端點錯誤
<a name="ContainerInsights-setup-invalid-endpoint"></a>

如果您看到類似以下的錯誤訊息，請檢查確認您已將您使用的命令中的所有預留位置 (例如 *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",
```

## 指標沒有出現在主控台
<a name="ContainerInsights-setup-EKS-troubleshooting-nometrics"></a>

如果您在 中看不到任何 Container Insights 指標 AWS 管理主控台，請確定您已完成 Container Insights 的設定。在完整設定容器洞見前指標都不會出現。如需詳細資訊，請參閱[設定 Container Insights](deploy-container-insights.md)。

## 升級叢集後，Amazon EKS 或 Kubernetes 上的 Pod 指標遺失
<a name="ContainerInsights-troubleshooting-podmetrics-missing"></a>

如果您將 CloudWatch 代理程式作為 daemonset 部署在新叢集或升級的叢集上後，遺失了全部或部分 Pod 指標，或者您看到包含訊息 `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
```

## 使用 Bottlerocket for Amazon EKS 時，沒有 Pod 指標
<a name="ContainerInsights-troubleshooting-bottlerocket"></a>

Bottlerocket 是以 Linux 為基礎的開源作業系統，由 AWS 為特定用途而建置，用於執行容器。

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 執行時間時，沒有容器檔案系統指標
<a name="ContainerInsights-troubleshooting-containerd"></a>

這是已知問題，社群貢獻者正在處理。如需詳細資訊，請參閱 GitHub 上的 [containerd 的硬碟使用量](https://github.com/google/cadvisor/issues/2785)和 [cadvisor for containerd 不支援容器檔案系統指標](https://github.com/aws/amazon-cloudwatch-agent/issues/192)。

## 收集 Prometheus 指標時，CloudWatch 代理程式的未預期日誌量增加
<a name="ContainerInsights-troubleshooting-log-volume-increase"></a>

這是 CloudWatch 代理程式版本 1.247347.6b250880 中推出的迴歸功能。此迴歸功能已在代理程式的更新版本中予以修正。其影響僅限於客戶收集 CloudWatch 代理程式本身的日誌，並且也在使用 Prometheus 的案例。如需詳細資訊，請參閱 GitHub 上的[[prometheus] 代理程式正在列印日誌中的所有湊集指標](https://github.com/aws/amazon-cloudwatch-agent/issues/209)。

## 在 Dockerhub 中找不到版本備註中提到的最新 Docker 影像
<a name="ContainerInsights-troubleshooting-docker-image"></a>

在我們內部開始實際發佈之前，我們在 Github 上更新發佈說明和標籤。在 Github 上增加版本編號後，通常需要 1-2 週的時間才能在登錄檔上查看最新的 Docker 影像。CloudWatch 代理程式容器映像並不會每晚發佈。您可以在下列位置直接從來源建置映像：https：//[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 錯誤
<a name="ContainerInsights-troubleshooting-crashloopbackoff"></a>

若您看到 CloudWatch 代理程式的 `CrashLoopBackOff` 錯誤，請確認您已正確設定您的 IAM 許可。如需詳細資訊，請參閱[在 CloudWatch 中驗證 Container Insights 的先決條件](Container-Insights-prerequisites.md)。

## CloudWatch 代理程式或 Fluentd Pod 卡在擱置中狀態
<a name="ContainerInsights-troubleshooting-pending"></a>

若您的 CloudWatch 代理程式或 Fluentd Pod 卡在 `Pending` 狀態或出現 `FailedScheduling` 錯誤，請根據核心數和代理程式所需的 RAM 數量來判斷您的節點是否具有足夠的運算資源。輸入以下命令來描述 Pod：

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