View a markdown version of this page

subqueries - Amazon CloudWatch Logs

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

subqueries

サブクエリは、別のクエリへの入力として使用できるネストされた Logs Insights クエリです。サブクエリを使用すると、後続のコマンドで消費される中間結果セットを取得できます。

構文

フィルターのサブクエリ

filter <field> in ( <subquery> )
パラメータ

  • <subquery> – 結果セットを返す有効な Logs Insights クエリ。サブクエリは、外部クエリによって参照されるフィールドを生成する必要があります。

例例 1: ダウンストリームサービスでエラーが発生したリクエストを検索する

この例では、サブクエリを使用して、ダウンストリームサービスでエラーが発生したメインサービスのリクエストを識別する方法を示します。これは、分散システムのカスケード障害のトラブルシューティングに役立ちます。

filter requestId in ( SOURCE '/aws/lambda/database-service' | filter errorType = "DatabaseConnectionTimeout" | fields requestId ) | fields @timestamp, requestId, endpoint, userId, responseTime | sort @timestamp desc

このクエリ:

  1. サブクエリは、接続タイムアウトが発生したデータベースサービスからすべてのrequestId値を検索します。

  2. 外部クエリは、メインサービスのログをフィルタリングして、エラーが発生しやすいリクエスト IDs

  3. 結果には、影響を受けたエンドポイントやユーザーなど、ダウンストリームで失敗したリクエストの完全なコンテキストが表示されます。

このパターンは、ダウンストリーム障害のアップストリームへの影響を理解するのに役立ちます。

例例 2: ターゲット調査のために頻繁に失敗するリクエストを特定する

この例では、集計でサブクエリを使用して、繰り返し失敗するリクエストを検索する方法を示します。多くの場合、一時的なエラーではなく体系的な問題を示します。

filter requestId in ( SOURCE '/aws/lambda/payment-processor' | filter status = "FAILED" | stats count(*) as failureCount by requestId | filter failureCount > 3 | fields requestId ) | fields @timestamp, requestId, customerId, amount, failureReason | sort @timestamp asc

このクエリ:

  1. サブクエリは、失敗した支払い試行を集計し、3 回以上失敗したリクエスト IDsします。

  2. 外部クエリは、問題のあるリクエスト IDs

  3. 再試行の進行状況を示すために結果が時系列的にソートされます

これにより、より詳細な調査が必要な一時的な障害 (単一発生) と永続的な問題 (複数の障害) を区別できます。

行動

  • サブクエリは、外部クエリとは独立して実行されます。

  • 結果は、外部クエリによって消費される前にマテリアライズされます。

  • 外部クエリで使用できるのは、サブクエリで明示的に選択されたフィールドのみです。

注意事項と制限事項

  • サブクエリは、外部クエリによって参照されるフィールドを返す必要があります。

  • ネストされたサブクエリはサポートされていません。

  • サブクエリにより、クエリの実行時間とコストが増加する可能性があります。

  • 相関サブクエリはサポートされていません。

  • 内部クエリの実行は 30 秒に制限されています。

関連コマンド