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 に必要です。詳細については、「前提条件を確認する」を参照してください。

Amazon ECS 上の削除および再作成されたクラスターへの Container Insights のデプロイ

Container Insights が有効になっていない既存の Amazon ECS クラスターを削除し、同じ名前で再作成した場合、再作成時にこの新しいクラスターで Container Insights を有効にすることはできません。再作成して有効にするには、次のコマンドを入力します。

aws ecs update-cluster-settings --cluster myCICluster --settings name=containerInsights,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 の設定」を参照してください。

クラスターのアップグレード後に 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 のディスク使用量メトリクスとコンテナファイルシステムのメトリクスは、GitHub の containerd 用 cadvisor ではサポートされていませんを参照してください。

Prometheus メトリクスを収集するときに CloudWatch エージェントから予期しないログボリュームが増える

これは、CloudWatch エージェントのバージョン 1.247347.6b250880 で導入された回帰です。この回帰は、より新しいバージョンのエージェントで既に修正されています。この影響は、お客様が CloudWatch エージェント自体のログを収集し、Prometheus を使用しているシナリオに限定されていました。詳細については、[prometheus] エージェントが GitHub のログにスクレイプされたメトリクスをすべて出力しているを参照してください。

リリースノートに記載されている最新の Docker イメージが Dockerhub から見つからない

実際のリリースを内部的に開始する前に、Github でリリースノートとタグを更新します。Github でバージョン番号を上げてから、レジストリで最新の Docker イメージが表示されるまで、通常 1～2 週間かかります。CloudWatch エージェントコンテナイメージは夜間にリリースされません。次の場所 (https://github.com/aws/amazon-cloudwatch-agent/tree/main/amazon-cloudwatch-container-insights/cloudwatch-agent-dockerfile) にあるソースから直接イメージを作成できます。

CloudWatch エージェントの CrashLoopBackoff エラー

CloudWatch エージェントの CrashLoopBackOff のエラーが表示された場合は、IAM アクセス許可が正しく設定されていることを確認してください。詳細については、「前提条件を確認する」を参照してください。

CloudWatch エージェントまたは Fluentd ポッドが保留状態でスタックする

CloudWatch エージェントまたは Fluentd ポッドが Pending 状態でスタックしている場合、または、FailedScheduling エラーでスタックしている場合は、エージェントに必要なコア数と RAM の量に基づいて、ノードに十分なコンピューティングリソースがあるかどうかを確認します。以下のコマンドを使用して、ポッドを記述します。

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