CloudWatch コンソールを使用して Kinesis のサブスクリプションフィルターを作成、設定、トラブルシューティングするにはどうすればよいですか?
CloudWatch コンソールを使用して Amazon CloudWatch Logsを Amazon Kinesis にストリーミングするためのサブスクリプションフィルターを作成したいと思います。どうすればよいですか?
簡単な説明
CloudWatch ログは、ほぼリアルタイムで同じアカウントに送信することも、クロスアカウントの Kinesis または Amazon Kinesis Data Firehose の送信先に送信することもできます。これは、サブスクリプションフィルターを使用して行うことができます。CloudWatch Logs コンソールでは、送信先とセットアップの設定がサポートされています。
フィルターパターン構文を使用してサブスクリプションフィルターを構成する方法については、フィルターとパターンの構文 を参照してください。
解決方法
同じアカウントまたは現在のアカウントの Kinesis データストリームのサブスクリプション設定
**注:**CloudWatch ロググループのリージョンと Kinesis の送信先リージョンは同じである必要があります。
サブスクリプションを作成する前に、次の操作を行います。
- まだ Kinesis ストリーム作成していない場合は、Kinesis ストリーム を作成します。
- 次の信頼ポリシーとアクセス権限を持つ AWS 識別およびアクセス管理 (IAM) ロールを作成します。
カスタム IAM ロール とロールポリシーを作成するには、次の手順を実行します。
1. 管理者権限を持つユーザーで IAM コンソールを開きます。
2. ナビゲーションペインで、[Policies] を選択します。
3. コンテンツペインで、ポリシーの作成 を選択します。
4. 次の JSON ポリシードキュメントをコピーして JSON タブに貼り付けます。
ロール権限
{ "Statement": [{ "Effect": "Allow", "Action": "kinesis:PutRecord", "Resource": "arn:aws:kinesis:<REGION>:<ACCOUNT_ID>:stream/<STREAM_NAME>" }] }
5. IAM コンソール を開きます。
6. コンソールのナビゲーションペインで、役割 を選択してから、役割の作成 を選択します。
7. カスタム信頼ポリシー の役割の種類を選択します。
8. カスタムの信頼ポリシー セクションで、ロールのカスタム信頼ポリシーを入力するか貼り付けます。詳細については、IAM ポリシーの作成 を参照してください。
9. [次へ] を選択します。
10. 前のステップで作成したカスタム IAM ポリシーを選択します。
11. 次へ、ロールの作成 を選択します。
信頼ポリシー
{ "Statement": { "Effect": "Allow", "Principal": { "Service": "logs.region.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringLike": { "aws:SourceArn": "arn:aws:logs:<REGION>:<ACCOUNT_ID>:*" } } } }
Kinesis ストリームと IAM ロールを作成したら、サブスクリプションフィルターを作成できます。
1. CloudWatch コンソールを開きます。
2. ロググループ を選択します。
3. アクション - サブスクリプションフィルター を選択します。
4. 送信先を設定するには、Kinesis サブスクリプションフィルタの作成 を選択します。
5. 現在のアカウント を選択します。
6. ドロップダウンリストから Kinesis データストリームを選択します。
7. 前に作成した IAM ロールを選択します。
8. 配布方法 を確認します。
ログストリーム別: ダウンストリームコンシューマーがログストリームごとにログイベントを集計できるが、効率が低下する可能性があることを確認します。この方法では、より多くのシャードが必要になるため、ストリーミングコストが高くなる可能性もあります。
ランダム - Kinesis ストリームシャード全体に負荷を分散しますが、ダウンストリームコンシューマーはログイベントをログストリームごとに集約できません。
9. ログ形式とフィルターを設定します。
ログ形式を選択します。形式は、Amazon VPC フローログ、AWS CloudTrail、または Amazon VPC、CloudTrail、または Lambda によって発行されたログの AWS Lambda になります。または、受信するログイベントに応じて、JSON、スペース区切り、その他 を選択できます。
サブスクリプションフィルターパターン セクションで フィルターパターンを定義します。
サブスクリプションフィルタの名前を入力します。
10. 既存のログイベントデータを使用してパターンを検証します。
11. 確認後、ストリーミングのスタート を選択します。
12. (オプション) ログイベントのフローを検証して、データストリームが機能することを確認します。
クロスアカウントの Kinesis データストリーム送信先の設定
注: AWS Command Line Interface (AWS CLI) コマンドの実行中にエラーが発生した場合は、AWS CLI の最新バージョンを使用していることを確認してください。
CloudWatch Logs イベントは、さまざまな AWS アカウントおよびリージョンの Kinesis データストリームに配信できます。そのためには、次の例に示すように、AWS リージョンを指定しながら、サブスクリプションを使用したクロスアカウントログデータ共有をセットアップします。
注: この例では、us-east-1 リージョンの CloudWatch ログは、us-west-2 にある別の AWS ユーザーの Kinesis データストリームに配信されます。ログデータ受信者の AWS アカウント ID は 222222222222 で、ログデータ送信者の AWS アカウント ID は 111111111111 です。
受信者アカウント 222222222222 に宛先データストリームを作成する
1. IAM ロールと信頼ポリシーを使用して、データ受信者アカウントの Kinesis で宛先データストリームを作成します。
2. create-stream コマンドを使用して、データストリームを作成します。必ず —region を指定してください。例えば、このコマンドにより、次のように、us-west-2 にデータストリーム YourStreamName が作成されます。
aws kinesis create-stream --stream-name "YourStreamName" --shard-count 1 --region us-west-2
3. describe-stream コマンドを使用して、StreamDescription.StreamStatus プロパティを確認します。必ず —region を指定してください。例えば、このコマンドにより、次のように、us-west-2 で YourStreamName ストリームをチェックします。
aws kinesis describe-stream --stream-name "YourStreamName" --region us-west-2
4. put-destination コマンドを使用して CloudWatch ログの送信先を作成します。—role-arn の —region をソース CloudWatch ログと同じリージョンに設定します。たとえば、us-east-1 の受信者アカウント 222222222222 にログ宛先を作成する受信者/送信先アカウント 222222222222 で次のコマンドを実行する必要があります。
aws logs put-destination \ --destination-name "testDestination" \ --target-arn "arn:aws:kinesis:us-west-2:222222222222:stream/YourStreamName" \ --role-arn "arn:aws:iam::222222222222:role/YourIAMRoleName" --region us-east-1
ソースアカウント 111111111111でサブスクリプションフィルターを作成します。
サブスクリプションフィルタを作成するには、次の手順を実行します。
1. ロググループを選択します。
2. アクション - サブスクリプションフィルター を選択します
3. 宛先を選択するには、次のオプションから選択します。
Kinesis サブスクリプションフィルタの作成: Kinesis データストリーム送信先のサブスクリプションフィルタを作成します
4. 宛先はクロスアカウントであるため、別のアカウント を選択します。
5. クロスアカウントの Kinesis または Kinesis Firehose 送信先の場合は、宛先 ARN を指定します。
6. 配布方法 を選択します。
ログストリーム別: ダウンストリームコンシューマーがログストリームごとにログイベントを集計できるが、効率が低下する可能性があることを確認します。この方法では、より多くのシャードが必要になるため、ストリーミングコストが高くなる可能性もあります。
ランダム - Kinesis ストリームシャード全体に負荷を分散しますが、ダウンストリームコンシューマーはログイベントをログストリームごとに集約できません。
7. ログ形式とフィルターを設定します。
ログ形式を選択します。形式は、Amazon VPC フローログ、CloudTrail、または Amazon VPC、CloudTrail、または Lambda によって発行されるログの AWS Lambda になります。または、受信するログイベントに応じて、JSON、スペース区切り、その他を選択できます。
サブスクリプションフィルターパターン セクションで フィルターパターンを定義します。
サブスクリプションフィルタの名前を入力します。
8. 既存のログイベントデータを使用してパターンを検証します。
9. 確認後、ストリーミングのスタート を選択します。
10. (オプション) ログイベントのフローを検証して、データストリームが機能することを確認します。
トラブルシューティング
- Kinesis ストリームが アクティブ 状態で、Kinesis コンソールで表示できることを確認します。または、DescribeStream API コール を使用することもできます。
- CloudWatch ロググループと Kinesis データストリームリージョンが同じであることを確認します。
- logs.yourregion.amazonaws.com に対する信頼アクセス権限を持ち、 kinesis: putrecords のアクセス権限を許可する IAM ロールがあることを確認します。
- IAM ポリシーのリージョンとリソースが正しいことを確認します。
- Kinesis データストリームのサブスクリプションフィルターを設定するときに、Kinesis Firehose を選択していないことを確認します。
- ストリーミングを開始したら、サブスクリプションフィルタのメトリクスによって、フィルタパターンが有効で、受信ログイベントと一致していることが確認されていることを確認します。これを行うには、以下のメトリクスを確認します。ForwardedBytes: サブスクリプションの宛先に転送されたログイベントのボリューム (圧縮バイト単位)。ForwardedLogEvents: サブスクリプションの宛先に転送されたログイベントの数。
- ログイベントを宛先にストリーミングするときにエラーがないことを確認するには、次のメトリクスを確認します。DeliveryErrors: サブスクリプション送信先にデータを転送するときに CloudWatch Logs がエラーを受信したログイベントの数。DeliveryThrottling: サブスクリプション送信先にデータを転送するときに CloudWatch Logs がスロットリングされたことを示すログイベントの数。
- 専用の Kinesis ストリームがある場合は、ストリームのメトリクスを確認して機能を確認します。
- クロスアカウントログのトラブルシューティングについては、「CloudWatch クロスアカウントセットアップのトラブルシューティング」を参照してください。
関連するコンテンツ
- 質問済み 1ヶ月前lg...
- 質問済み 7ヶ月前lg...
- AWS公式更新しました 2年前