Amazon EKS でのロギングに関する問題をトラブルシューティングする方法を教えてください。

解決策

トラブルシューティングの前に、アプリケーションがログ書き込みを行うことを確認します。

注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、「AWS CLI で発生したエラーのトラブルシューティング」を参照してください。また、AWS CLI の最新バージョンを使用していることを確認してください。

ネットワークが正しく構成されていることを確認する

Amazon Virtual Private Cloud (Amazon VPC) サブネットとセキュリティグループのネットワークが、正しく構成されていることを確認します。次の項目を確認します。

• インターネットゲートウェイを使用する場合は、ゲートウェイがルートテーブルと適切に関連付けられていることを確認します。さらに、送受信ネットワークトラフィックが正しくルーティングされていることを確認します。
• NAT ゲートウェイを使用する場合は、ゲートウェイがパブリックサブネット内で適切に構成されていることを確認します。次に、関連するルートテーブルが適切にルーティングされていることを確認します。
• インターネットアクセスが限定されたプライベートクラスターを使用している場合は、クラスターに com.amazonaws.region.logs VPC インターフェイスエンドポイントが存在し、適切なポリシーがアタッチされていることを確認します。
• サービスアカウントを使用している場合は、AWS Identity and Access Management (IAM) ロールでポッドを構成した可能性があります。アウトバウンドのインターネットアクセスがない場合は、VPC 内で AWS Security Token Service (AWS STS) の VPC エンドポイント (com.amazonaws.region.logs) を使用する必要があります。
• または、プライベート Amazon Elastic Container Registry (Amazon ECR) リポジトリからイメージをプルすることも検討してください。NAT ゲートウェイを使用しておらず、アウトバウンドインターネットアクセスもない場合は、次の VPC エンドポイントと Amazon Simple Storage Service (Amazon S3) ゲートウェイエンドポイントが必要です。
  com.amazonaws.region-code.s3
  com.amazonaws.region-code.ecr.api
  com.amazon.region-code.ecr.dkr
• VPC エンドポイントのセキュリティグループには、ポート 443 からのトラフィックを許可するインバウンドルールが必要です。さらに、ノードのセキュリティグループは VPC エンドポイントへのアウトバウンドトラフィックを許可していることを確認します。

ポッドに十分な権限があることを確認する

使用するポッドがサービスアカウントの IAM ロールを使用する場合は、サービスアカウントに適切な IAM ロールのアノテーションが付与されていることを確認します。次に、クラスターに IAM OpenID Connect (OIDC) プロバイダーを作成したことを確認します。

サービスアカウントの IAM ロールと権限を確認するには、次の手順を実行します。

1. サービスアカウントの IAM ロールを記述し、次のアノテーションが存在することを確認します。次のコマンドを実行します。

   eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/YOUR-ROLE-NAME

   注: YOUR-ROLE-NAME をアカウントの IAM ロール名に置き換えてください。

2. IAM ロールに CloudWatchAgentServerPolicy がアタッチされていることを確認します。または、同じ権限を持つポリシーが存在することを確認します。存在しない場合は、ノードロールに CloudWatchAgentServerPolicy がアタッチされていることを確認します。

Fluent Bit 構成のトラブルシューティング

Fluent Bit ログルーターをインストールした場合は、ポッドが実行中であり、システムはログを Amazon CloudWatch に送信していることを確認します。上記に当てはまらない場合、IAM 権限またはネットワークに問題がある可能性があります。

Fluent Bit のデプロイと構成をトラブルシューティングするには、次の項目を検証します。

Fluent Bit をインストールした名前空間内のポッドを確認するには、次のコマンドを実行します。

kubectl get pods -n NAMESPACE

注: NAMESPACE を名前空間名に置き換えてください。

ノードにテイントが設定されている場合は、ポッドがトレレーションで構成されていることを確認します。

ポッドのステータスが RUNNING 以外の場合は、次のコマンドを実行し、ポッドイベントを確認します。

kubectl describe pod POD_NAME -n NAMESPACE

注: POD_NAME をポッド名に、NAMESPACE を名前空間名に置き換えてください。

ポッドログにエラーがないか確認するには、次のコマンドを実行します。

kubectl logs POD_NAME -n NAMESPACE

注: POD_NAME をポッド名に、NAMESPACE を名前空間名に置き換えてください。

デフォルトでは、Fluent Bit のログレベルは info に設定されています。さらに詳細を取得する場合は、debug に変更します。詳細については、Fluent Bit のウェブサイトで「構成ファイル」を参照してください。

Fluent Bit ConfigMap の構成を確認するには、次のコマンドを実行します。

kubectl get cm CONFIGMAP_NAME -n NAMESPACE -o yaml

注: CONFIGMAP_NAME を ConfigMap 名に、NAMESPACE を名前空間名に置き換えてください。

ノードロールまたはサービスアカウントに関連付けられたロールには、設定した宛先に対応する、適切な IAM 権限が付与されていることを確認します。

CloudWatch Agent のトラブルシューティング

ノードの IAM ロールには、必要な権限が付与されていることを確認します。サービスアカウントロールが含まれる IAM ロールを使用する場合は、OIDC プロバイダー、IAM ロール、およびポリシーが作成済みであることを確認します。サービスアカウントは、適切な IAM ロールで適切にアノテーションされていることを確認します。

cloudwatch-agent DaemonSet のポッドが正常に実行されていることを確認します。ノードにテイントが設定されている場合は、ポッドがトレレーションで構成されていることを確認します。ポッドのリストを取得するには、次のコマンドを実行します。

kubectl logs POD_NAME -n amazon-cloudwatch

注: POD_NAME を実際のポッド名に置き換えてください。

ポッドのステータスが RUNNING 以外の場合は、ポッドイベントを確認します。次のコマンドを実行します。

kubectl describe pod POD_NAME -n amazon-cloudwatch

注: POD_NAME を実際のポッド名に置き換えてください。

ConfigMap でクラスター名が正しく設定されていることを確認します。ログでポッドを見つけるには、次のコマンドを実行します。

kubectl logs POD_NAME -n amazon-cloudwatch

注: POD_NAME を実際のポッド名に置き換えてください。

DaemonSet でパブリックイメージを使用する場合は、ノードがインターネットにアクセスできることを確認します。プライベートリポジトリのイメージを使用する場合は、必要なトラフィックが許可されていることを確認します。

Fargate クラスターのロギングに関するトラブルシューティング

注: AWS Fargate のロギングでは、ConfigMaps の動的構成はサポートされません。変更は既存のポッドには適用されないため、ConfigMap の変更は新しいポッドにのみ適用されます。

aws-observability: enabled ラベルが付与された aws-observability という名前空間が作成済みであることを確認するには、次のコマンドを実行します。

kubectl get ns aws-observability -o yaml

Fargate プロファイルのポッド実行ロールには、適切な IAM ポリシーが指定されていることを確認します。たとえば、CloudWatch にログを送信する意図がある場合は、ポッド実行ロールに次の権限が含まれることを確認します。

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": [
            "logs:CreateLogStream",
            "logs:CreateLogGroup",
            "logs:DescribeLogStreams",
            "logs:PutLogEvents",
            "logs:PutRetentionPolicy"
        ],
        "Resource": "*"
    }]
}

aws-observability 名前空間に ConfigMap が正しく作成されたことを確認します。ConfigMap は、Fargate がフィールドの検証に使用するルールと整合していることを確認します。

Fluent Bit プロセスログが欠落している場合は、ConfigMap に flb_log_cw: "true" を設定したかどうかを確認します。

Amazon EKS の CloudWatch Observability アドオンに関するトラブルシューティング

Amazon EKS の CloudWatch Observability アドオンがサービスアカウントの IAM ロールを使用する場合は、クラスターに OIDC プロバイダーが作成済みであることを確認します。次に、サービスアカウントが適切なロールで構成されていることを確認します。ロールには、CloudWatchAgentServerPolicy ポリシーがアタッチされている必要があります。

AWS マネジメントコンソールを使用してマネージドアドオンをインストールした場合は、コンソールでポッドとアドオンのステータスがアクティブと表示されることを確認します。アドオンが failed ステータスの場合は、障害の原因を確認します。同様に、Helm を使用してアドオンをインストールした場合は、Helm のインストールが正常に行われたかどうかを確認します。

既存のリソースで障害が発生した場合は、アドオンに必要なコンポーネントを過去にインストール済みである可能性があります。CloudWatch エージェントを以前にインストールした場合は、アドオンをインストールする前にクラスターから削除します。また、アドオンのインストール前に、本来の CloudWatch エージェントに行ったすべてのカスタマイズや変更のバックアップを作成する必要があります。アドオンまたは Helm チャートのインストールまたは更新が完了した後は、カスタマイズを再度適用できます。

関連情報

Amazon ECS または Amazon EKS のコンテナログが欠落している場合のトラブルシューティング方法を教えてください

Amazon EKS クラスターで Container Insights メトリクスを有効化する方法を教えてください