# Container Insights のトラブルシューティング 以下のセクションは、Container Insights で問題が発生している場合に役立ちます。 ## Amazon EKS または Kubernetes でのデプロイに失敗しました エージェントが Kubernetes クラスターに正しくデプロイされない場合は、以下を試してください。 + 次のコマンドを実行して、ポッドのリストを取得します。 ``` 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 マネジメントコンソール に Container Insights メトリクスが表示されない場合は、Container Insights のセットアップが完了していることを確認します。メトリクスは、Container Insights が完全にセットアップされるまで表示されません。詳細については、「[Container Insights の設定](deploy-container-insights.md)」を参照してください。 ## クラスターのアップグレード後に Amazon EKS または Kubernetes でポッドメトリクスが欠けている このセクションは、CloudWatch エージェントをデーモンセットとして新規クラスターまたはアップグレードされたクラスターにデプロイした後に、すべてまたは一部のポッドメトリクスが欠けている場合、またはメッセージ `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 は 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 ランタイムを使用する場合、コンテナファイルシステムのメトリクスがない これは既知の問題であり、コミュニティの貢献者が取り組んでいます。詳細については、[containerd のディスク使用量メトリクス](https://github.com/google/cadvisor/issues/2785)と[コンテナファイルシステムのメトリクスは、GitHub の containerd 用 cadvisor ではサポートされていません](https://github.com/aws/amazon-cloudwatch-agent/issues/192)を参照してください。 ## Prometheus メトリクスを収集するときに CloudWatch エージェントから予期しないログボリュームが増える これは、CloudWatch エージェントのバージョン 1.247347.6b250880 で導入された回帰です。この回帰は、より新しいバージョンのエージェントで既に修正されています。この影響は、お客様が CloudWatch エージェント自体のログを収集し、Prometheus を使用しているシナリオに限定されていました。詳細については、[[prometheus] エージェントが GitHub のログにスクレイプされたメトリクスをすべて出力している](https://github.com/aws/amazon-cloudwatch-agent/issues/209)を参照してください。 ## リリースノートに記載されている最新の Docker イメージが Dockerhub から見つからない 実際のリリースを内部的に開始する前に、Github でリリースノートとタグを更新します。Github でバージョン番号を上げてから、レジストリで最新の Docker イメージが表示されるまで、通常 1～2 週間かかります。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 ポッドが保留状態でスタックする CloudWatch エージェントまたは Fluentd ポッドが `Pending` 状態でスタックしている場合、または、`FailedScheduling` エラーでスタックしている場合は、エージェントに必要なコア数と RAM の量に基づいて、ノードに十分なコンピューティングリソースがあるかどうかを確認します。以下のコマンドを使用して、ポッドを記述します。 ``` kubectl describe pod cloudwatch-agent-85ppg -n amazon-cloudwatch ```