本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
針對容器洞見進行故障診斷
若您在使用容器洞見時發生問題,下列各節可協助您。
在 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 授權模式。容器洞見需要使用此模式。如需詳細資訊,請參閱在 CloudWatch 中驗證 Container Insights 的先決條件。
在 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",
指標沒有出現在主控台
如果您在 中看不到任何 Container Insights 指標 AWS Management Console,請確定您已完成 Container Insights 的設定。在完整設定容器洞見前指標都不會出現。如需詳細資訊,請參閱設定 Container Insights。
升級叢集後,Amazon EKS 或 Kubernetes 上的 Pod 指標遺失
如果您將 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 指標
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 執行時間時,沒有容器檔案系統指標
這是已知問題,社群貢獻者正在處理。如需詳細資訊,請參閱 GitHub 上的 containerd 的硬碟使用量
收集 Prometheus 指標時,CloudWatch 代理程式的未預期日誌量增加
這是 CloudWatch 代理程式版本 1.247347.6b250880 中推出的迴歸功能。此迴歸功能已在代理程式的更新版本中予以修正。其影響僅限於客戶收集 CloudWatch 代理程式本身的日誌,並且也在使用 Prometheus 的案例。如需詳細資訊,請參閱 GitHub 上的[prometheus] 代理程式正在列印日誌中的所有湊集指標
在 Dockerhub 中找不到版本備註中提到的最新 Docker 影像
在我們內部開始實際發佈之前,我們在 Github 上更新發佈說明和標籤。在 Github 上增加版本編號後,通常需要 1-2 週的時間才能在登錄檔上查看最新的 Docker 影像。CloudWatch 代理程式容器映像並不會每晚發佈。您可以從來源直接建置映像,位置如下:https://https://github.com/aws/amazon-cloudwatch-agent/tree/main/amazon-cloudwatch-container-insights/cloudwatch-agent-dockerfile
CloudWatch 代理程式上的 CrashLoopBackoff 錯誤
若您看到 CloudWatch 代理程式的 CrashLoopBackOff
錯誤,請確認您已正確設定您的 IAM 許可。如需詳細資訊,請參閱在 CloudWatch 中驗證 Container Insights 的先決條件。
CloudWatch 代理程式或 Fluentd Pod 卡在擱置中狀態
若您的 CloudWatch 代理程式或 Fluentd Pod 卡在 Pending
狀態或出現 FailedScheduling
錯誤,請根據核心數和代理程式所需的 RAM 數量來判斷您的節點是否具有足夠的運算資源。輸入以下命令來描述 Pod:
kubectl describe pod cloudwatch-agent-85ppg -n amazon-cloudwatch