翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
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
このクエリ:
-
サブクエリは、接続タイムアウトが発生したデータベースサービスからすべての
requestId値を検索します。 -
外部クエリは、メインサービスのログをフィルタリングして、エラーが発生しやすいリクエスト IDs
-
結果には、影響を受けたエンドポイントやユーザーなど、ダウンストリームで失敗したリクエストの完全なコンテキストが表示されます。
このパターンは、ダウンストリーム障害のアップストリームへの影響を理解するのに役立ちます。
例例 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
このクエリ:
-
サブクエリは、失敗した支払い試行を集計し、3 回以上失敗したリクエスト IDsします。
-
外部クエリは、問題のあるリクエスト IDs
-
再試行の進行状況を示すために結果が時系列的にソートされます
これにより、より詳細な調査が必要な一時的な障害 (単一発生) と永続的な問題 (複数の障害) を区別できます。
行動
-
サブクエリは、外部クエリとは独立して実行されます。
-
結果は、外部クエリによって消費される前にマテリアライズされます。
-
外部クエリで使用できるのは、サブクエリで明示的に選択されたフィールドのみです。
注意事項と制限事項
-
サブクエリは、外部クエリによって参照されるフィールドを返す必要があります。
-
ネストされたサブクエリはサポートされていません。
-
サブクエリにより、クエリの実行時間とコストが増加する可能性があります。
-
相関サブクエリはサポートされていません。
-
内部クエリの実行は 30 秒に制限されています。