subquery

必須の引数

compose は、親クエリに返される子クエリの出力を制御します。

•  親クエリに返される子クエリのフィールド。親クエリには複数のフィールドを返すことができます。
•  値が返される形式。指定フィールドの結果は、表形式から標準 DNF 形式に変換されます。

たとえば、subquery が以下の結果を生成した場合:

次のように単一の出力に変換されます。

(( _sourcehost="prod-search-1" AND _sourcecatagory=”stream” AND clientip=”1.1.1.1”) OR (_sourcehost=”prod-remix-1” AND _sourcecatagory=”remix” AND clientip=”10.10.10.10”))

• 結果の列間は AND、行間は OR で連結されます。
• 各行は ( ) で囲まれ、結果全体は別の ( ) で囲まれます。

省略可能な引数

from=(<fromTime>) to=(<toTime>) 子クエリのsubquery には親クエリとは異なる時間範囲を指定できます。デフォルトでは、子クエリは親クエリと同じ時間範囲で実行されます。相対時間と絶対時間のどちらでも指定できます。例とサポートされるフォーマットについては、「異なる時間範囲の subquery」を参照してください。

maxresults=<int>  子クエリから親クエリに返される結果の数を制限できます。パフォーマンスを高めるため、デフォルトでは返される結果を最大 2,500 件に設定してありますが、10,000 件まで増やすことができます。

keywords keyword 句を指定しないと、結果のフィールド名はキーと値のペアとして親に返されるため、クエリが機能するためには親クエリにもこれらのフィールドが存在する必要があります。

keywords を指定すると、キーと値のペアのみから値が返され、キーがフィールド名になります。たとえば、subquery が以下の結果を生成した場合:

次のように単一の出力に変換されます。

((”prod-search-1” AND ”stream” AND ”1.1.1.1”) OR (”prod-remix-1” AND ”remix” AND ”10.10.10.10”))

結果にはキーと値のペアからの値のみが含まれ、キー (フィールド名) は返されません。これは、親クエリの既存の (すでに parse された) フィールドではなくリテラル値と一致させたい場合に便利です。

ステップ 1: 親クエリの作成

ここで作成する親クエリは、特定のユーザがチェックアウトした商品と購入した商品に関する統計情報を提供します。この例では、IP でユーザをトラッキングし、次のクエリを使用してカスタム アプリケーション ログを処理します。

_sourceCategory=reinvent/travel/checkout 243.63.233.30
| json field=_raw "funcName"
| where funcname in ("process_cart","charge")
| if (funcname = "process_cart" , "Checkout", "Purchased") as funcname
| count by funcname

subquery を使用することで、強調表示されている IP アドレスを、子クエリからこの親クエリに検索式のキーワードとして渡すことができます。

ステップ 2: 子クエリの作成

ここで作成する子クエリは、最もアクティブなユーザを特定し、次のように Web サーバ ログの IP アドレスを使用してトラッキングします。

_sourceCategory=reinvent/travel/nginx
      | count by src_ip
      | topk(1,_count)

 このクエリの結果には、親クエリに渡す IP アドレス (243.63.233.30) が含まれています。

ステップ 3: subquery の作成

2 つのクエリを 1 つの subquery として組み合わせて、親クエリで子クエリの結果を利用できるようにします。subquery はいくつかの方法で作成できます。

• 子クエリからの IP アドレスが (最初のパイプ (|) の前にある) 検索式のキーワードとして使用されるように keywords を含めます。
• 結果がキーと値のペアの表形式で返されるように keywords 引数を除外します。返されるフィールド (キー) は、親クエリの結果に存在する必要があります。
• subquery は where または if operator と一緒に使用します。
  • where 句で IP アドレスをフィルタリングするのであれば、IP アドレスの代わりにフィルタ式を動的に生成する subquery を使用できます。
  • IP アドレスを if 条件として使用する場合、if 条件が true または false のどちらになるかに従って値を新しいフィールドに割り当てることができます。

Time range usage examples

相対

[subquery from=(-15m):error
| count by _sourcehost
| topk(1, _count)
| compose _sourceHost]
| count by _sourceHost

絶対
[subquery from=(2018/07/08 23:13:36) to=(2018/07/09 23:13:36):error
| count by _sourcehost
| topk(1, _count)
| compose _sourceHost]
| count by _sourceHost

サポートされる時間形式

相対 

• s - 秒
• m - 分
• h - 時
• d - 日
• w - 週

エポック

01/01/1970 00:00:00.000 UTC からのミリ秒数で指定するタイムスタンプ

絶対時間

ISO 8601 形式をサポートします。 

• yyyy-MM-dd HH:mm:ss.SSS
• yyyy-MM-dd HH:mm:ss
• yyyy-MM-dd HH:mm
• yyyy-MM-dd
• MM-dd HH:mm:ss.SSS
• MM-dd HH:mm:ss
• MM-dd HH:mm
• MM-dd
• yyyy/MM/dd HH:mm:ss.SSS
• yyyy/MM/dd HH:mm:ss
• yyyy/MM/dd HH:mm
• yyyy/MM/dd
• MM/dd HH:mm:ss.SSS
• MM/dd HH:mm:ss
• MM/dd HH:mm
• MM/dd

subquery によるアラートの改善

一般に、アラートを構築する場合には、複雑な計算を実行して、何か悪いことが起きたときにだけアラートが発動することを保証しなければなりません。これらの複雑な計算は、アラートの発動にのみ必要であり、アラートから返される実際の結果では必要ありません。

subquery を使用しなければ、この詳細レベルでのアラートは不可能でしたが、subquery によって簡単に実現できるようになりました。たとえば、インデックスのデプロイ時の問題が発生するたびにアラートを発動したいとします。まず、リトライ回数が _count > 3 になった後でも特定のインデックスがデプロイされていないかどうかを見ます。もし該当のインデックスがあれば、subquery はそのインデックスに関する有益な情報 (デプロイ先のホストなど) を送信します。

_sourceCategory=search "error while retrying to deploy index"
| parse \",name=*-*\" as cus, index | where [subquery: _sourceCategory=search "error while retrying to deploy index" !info
         | parse ",indexName='*-*'" as cus, index         | count by index // Ignore cases where retry might have happened.
         | where _count > 3
         | compose by index]
| count by _sourceHost, cus, index

subquery による悪意のあるアクティビティのチェック

次の検索によってセキュリティ アナリストは、Amazon GuardDuty や CrowdStrike Threat フィードによってフラグが立てられた悪意のある IP アドレスに関連したログをトラッキングできます。この subquery は、脅威と見なした IP アドレスを src_ip に格納して親クエリに返します。親クエリは src_ip フィールドが存在することを期待するため、keywords オプションは使用していません。結果には、subquery から脅威と見なされて返された src_ip 値を含む、ウェブログ sourceCategory からのログが含まれます。

_sourceCategory=weblogs
[subquery:_sourceCategory="Labs/SecDemo/guardduty" "EC2 Instance" "communicating on an unusual server port 22"
| json field=_raw "service.action.networkConnectionAction.remoteIpDetails" as remoteIpDetails
| json field=_raw "service.action.networkConnectionAction.connectionDirection" as connectionDirection
| where connectionDirection = "OUTBOUND"
| json field=remoteipdetails "ipAddressV4" as src_ip
| lookup type, actor, raw, threatlevel from sumo://threat/cs on src_ip=threat
| where threatlevel = "high"
| compose src_ip]

save と lookup を使用する場合の子クエリからのデータの参照

異なる Source からのデータを相関させたり、子クエリからのデータを compose で渡すことなくさらに集計したりする場合は、結果を制限するクエリの範囲が適用されるため、save および lookup operator を使用して、親クエリで必要なデータを取得できます。

このクエリは、特定のセッションを識別して、異なるデータ ソースからのステータス メッセージに相関させます。

_sourceCategory=katta
 [subquery:(_sourceCategory=stream explainJSONPlan.ETT) error
      | where !(statusmessage="Finished successfully" or statusmessage="Query canceled" or isNull(statusMessage))
      | count by sessionId, statusMessage
      | fields -_count
      | save /explainPlan/neededSessions
      | compose sessionId keywords]
| parse "[sessionId=*]" as sessionId
| lookup statusMessage from /explainPlan/neededSessions on sessionid=sessionid

このクエリは、トランザクション エラーを特定して、別のデータ ソースからの発送情報に相関させます。

[subquery: _source=sourceA and ("Transaction Error")
| parse "message=* )" as MsgTxt
| parse "transaction *\\\"" as trans_id
| save /transactions/errors
| compose trans_id keywords 
] 
_source=sourceB
| parse "name: SHIPPER_ID\n value: *\n}" as shipper_id
| parse "transaction *\\\"" as trans_id
| lookup MsgTxt from /transactions/errors on trans_id=trans_id
| count by shipper_id