CloudWatch のサブスクリプションフィルターによるログ配信の失敗をトラブルシューティングする方法を教えてください。

所要時間3分

Amazon CloudWatch のサブスクリプションフィルターによるログ配信の失敗をトラブルシューティングしたいです。

簡単な説明

ストリーミングを開始する際、CloudWatch Logs のメトリクスをチェックして、フィルターパターンが正しく、受信ログイベントと一致していることを確認します。トラブルシューティングのうえで、確認すべき最も一般的なメトリクスを次に示します。

ForwardedBytes: サブスクリプションの宛先に転送されたログイベントの量 (圧縮バイト単位)。
ForwardedLogEvents: サブスクリプションの宛先に転送されたログイベントの数。
DeliveryErrors: サブスクリプションの宛先にデータを転送したときに CloudWatch Logs がエラーを受け取ったログイベントの数。
DeliveryThrottling: サブスクリプションの宛先にデータを転送したときに CloudWatch Logs がスロットリングされたことを示すログイベントの数。

注: 宛先側のサービスがスロットリングやサービスエラーなどの再試行可能なエラーを受け取った場合、CloudWatch Logs は 24 時間、データの送信を試みます。AccessDenied エラーや ResourceNotFound エラーなど、エラーが再試行可能なものではない場合、CloudWatch Logs はそれ以上の配信を試みません。

解決策

使用する宛先側サービスに基づくサブスクリプションフィルターを使用して、失敗したログ配信をトラブルシューティングします。

Amazon Kinesis Data Streams

Amazon Kinesis Data Streams へのサブスクリプションフィルターによるログ配信の失敗をトラブルシューティングするには、次のタスクを実行します。

Kinesis データストリームがアクティブな状態であることを確認します。状態を確認するには、Kinesis コンソールまたは DescribeStream API 呼び出しを使用します。
CloudWatch ロググループと Kinesis データストリームが同じ AWS リージョンにあることを確認します。

サブスクリプションフィルターにリンクされている AWS Identity and Access Management (IAM) ロールを確認します。CloudWatch Logs に、ストリームにデータを保存するために必要なアクセス許可があることを確認します。ロールアクセス許可ポリシーの例を次に示します。
注: お使いのものでそれぞれ、example-region をリージョンに、example-account-id を AWS アカウント ID に、example-stream-name をストリームの名前に置き換えます。

{  
  "Statement": [{  
    "Effect": "Allow",  
    "Action": "kinesis:PutRecord",  
    "Resource": "arn:aws:kinesis:example-region:example-account-id:stream/example-stream-name"  
  }]  
}

IAM ロールに適切な信頼ポリシーが設定されていることを確認します。信頼ポリシーの例を次に示します。
注: お使いのものでそれぞれ、example-region をリージョンに、example-account-id をアカウント ID に置き換えます。

{  
  "Statement": {  
    "Effect": "Allow",  
    "Principal": {  
      "Service": "logs.region.amazonaws.com"  
    },  
    "Action": "sts:AssumeRole",  
    "Condition": {  
      "StringLike": {  
        "aws:SourceArn": "arn:aws:logs:example-region:example-account-id:*"  
      }  
    }  
  }  
}

専用の Kinesis データストリームがある場合は、ストリームメトリクスをチェックし、機能していることを確認します。詳細については、「Amazon CloudWatch で Amazon Kinesis データストリームサービスを監視する」を参照してください。
クロスアカウントロギングで問題が発生した場合は、「CloudWatch のクロスアカウントロギングの問題をトラブルシューティングする方法を教えてください」を参照してください。

Amazon Data Firehose

Amazon Data Firehose へのサブスクリプションフィルターによるログ配信の失敗をトラブルシューティングするには、次のタスクを実行します。

Firehose ストリームがアクティブな状態であることを確認します。ステータスを確認するには、Kinesis コンソールまたは DescribeDeliveryStream API コールを使用します。データ変換機能を使用する場合は、指定した AWS Lambda 関数が存在することを確認してください。
Firehose メトリクスをチェックして、データが Firehose にストリーミングされていることを確認します。IncomingBytes、IncomingRecords、DataReadFromKinesisStream.Bytes、DataReadFromKinesisStream.Records などのメトリクスを確認します。
Firehose がデータを受信していない場合は、API レベルの CloudWatch メトリクスを確認します。問題はアップストリームから発生している場合があります。PutRecord や PutRecordBatch などの API は Firehose にデータを送信するため、正しく呼び出す必要があります。

エラーログをチェックし、配信が失敗した理由の詳細を確認します。関連する IAM ポリシーに logs:PutLogEvents アクセス許可があることを確認してください。logs:PutLogEvents アクセス許可のある IAM ポリシーの例を次に示します。
注: お使いのものでそれぞれ、example-region をリージョンに、example-account-id をアカウント ID に置き換えます。

{  
    "Sid": "",  
    "Effect": "Allow",  
    "Action": [  
        "logs:PutLogEvents"  
    ],  
    "Resource": [  
        "arn:aws:logs:example-region:example-account-id:log-group:/aws/kinesisfirehose/Delivery_Stream:log-stream:*",  
        "arn:aws:logs:example-region:example-account-id:log-group:%FIREHOSE_POLICY_TEMPLATE_PLACEHOLDER%:log-stream:*"  
    ]  
}

Firehose ストリームにリンクされている IAM ロールに、CloudWatch Logs にデータを保管するための適切なアクセス許可があることを確認します。アクセス許可ポリシーの例を次に示します。
注: お使いのものでそれぞれ、example-region をリージョンに、example-account-id をアカウント ID に、example-stream-name をストリームの名前に置き換えます。

{  
  "Statement": [{  
    "Effect": "Allow",  
    "Action": "firehose:PutRecord",  
    "Resource": "arn:aws:firehose:example-region:example-account-id:deliverystream/example-stream-name"  
  }]  
}

{  
  "Statement": {  
    "Effect": "Allow",  
    "Principal": { "Service": "logs.amazonaws.com" },  
    "Action": "sts:AssumeRole",  
    "Condition": {   
         "StringLike": {   
             "aws:SourceArn": "arn:aws:example-region:example-account-id:*"  
         }   
     }  
  }  
}

クロスアカウントロギングで問題が発生した場合は、「CloudWatch のクロスアカウントロギングの問題をトラブルシューティングする方法を教えてください」を参照してください。
複数の宛先に関連する問題については、「Amazon Data Firehose のトラブルシューティング」を参照してください。

Lambda

Lambda へのサブスクリプションフィルターによるログ配信の失敗をトラブルシューティングするには、次のタスクを実行します。

Lambda 関数に、CloudWatch Logs に関数を実行するためのアクセス許可を付与するのに必要なリソースベースのポリシーがあることを確認します。ポリシーステートメントの例を次に示します。
注: example-region、example-account-id、example-lambda-function、example-log-name は、それぞれお使いのリージョン、アカウント ID、Lambda 関数、ログの名前で置き換えます。

"Statement": [  
    {  
      "Sid": "",  
      "Effect": "Allow",  
      "Principal": {  
        "Service": "logs.amazonaws.com"  
      },  
      "Action": "lambda:InvokeFunction",  
      "Resource": "arn:aws:lambda:example-region:example-account-id:function:example-lambda-function",  
      "Condition": {  
        "StringEquals": {  
          "AWS:SourceAccount": "example-account-id"  
        },  
        "ArnLike": {  
          "AWS:SourceArn": "arn:aws:logs:example-region:example-account-id:log-group:example-log-name:*"  
        }  
      }  
    }  
  ]

Lambda 関数に、次のロールポリシーを含む lambda.amazonaws.com との信頼関係を持つ IAM ロールがあることを確認します。

"Statement": [  
    {  
        "Effect": "Allow",  
        "Principal": {  
        "Service": "lambda.amazonaws.com"  
        },  
        "Action": "sts:AssumeRole"  
    }  
]

OpenSearch Service

Amazon OpenSearch Service へのサブスクリプションフィルターによるログ配信の失敗をトラブルシューティングするには、次のタスクを実行します。

Lambda 関数に、次のロールポリシーを含む lambda.amazonaws.com との信頼関係を持つ IAM ロールがあることを確認します。
注: お使いのものでそれぞれ、example-region をリージョンに、example-account-id をアカウント ID に、example-target-domain ターゲットドメインの名前に置き換えます。

{"Version": "2012-10-17",  
  "Statement": [  
    {  
      "Action": [  
        "es:*"  
      ],  
      "Effect": "Allow",  
      "Resource": "arn:aws:es:example-region:exampleaccount-id:domain/example-target-domain/*"  
    }  
  ]  
}

クロスアカウントロギングで問題が発生した場合は、「CloudWatch のクロスアカウントロギングの問題をトラブルシューティングする方法を教えてください」を参照してください。
OpenSearch Service サブスクリプションフィルターによる CloudWatch Logs の問題をトラブルシューティングするには、「CloudWatch ログをトラブルシューティングし、OpenSearch Service ドメインにストリーミングする方法を教えてください」を参照してください。