次の方法で共有


リファレンス ドキュメントの構文規則

[ バージョン ] ドロップダウン リストを使用してサービスを切り替えます。 ナビゲーションの詳細を確認します
適用対象: ✅ Microsoft Fabric ✅ Azure Data Explorer ✅ Azure Monitor ✅ Microsoft Sentinel

この記事では、 Kusto クエリ言語 (KQL)管理コマンド のリファレンス ドキュメントに従う構文規則について説明します。

Kusto クエリ言語の学習を開始するには、全体的なクエリ構造を理解することをお勧めします。 Kusto クエリを見たときに最初に気づくのは、パイプ シンボル (|) の使用です。 Kusto クエリの構造は、データ ソースからデータを取得してから パイプラインを介してデータを渡すことから始まり、各手順で何らかのレベルの処理を行い、次の手順にデータを渡します。 パイプラインの最後に、最終的な結果が得られます。 実際には、これはパイプラインです。

Get Data | Filter | Summarize | Sort | Select

パイプラインにデータを渡すというこの概念により、各ステップでデータの精神的な画像を簡単に作成できるため、直感的な構造が実現します。

これを説明するために、次のクエリを見てみましょう。このクエリでは、Microsoft Entra のサインイン ログを確認します。 各行を読み進める際に、データに何が起こっているかを示すキーワードを確認できます。 各行のコメントとして、パイプラインに関連するステージが含まれています。

クエリ内の任意の行にコメントを追加するには、その前に二重スラッシュ (//) を付けます。

SigninLogs                              // Get data
| evaluate bag_unpack(LocationDetails)  // Ignore this line for now; we'll come back to it at the end.
| where RiskLevelDuringSignIn == 'none' // Filter
   and TimeGenerated >= ago(7d)         // Filter
| summarize Count = count() by city     // Summarize
| sort by Count desc                    // Sort
| take 5                                // Select

すべてのステップの出力は次のステップの入力として機能するため、ステップの順序によってクエリの結果が決定され、そのパフォーマンスに影響を与える可能性があります。 クエリから抜け出す内容に従って手順を並べ替える必要があります。

ヒント

  • データを早期にフィルター処理することをお勧めします。そのため、関連するデータをパイプラインに渡すだけです。 これにより、パフォーマンスが大幅に向上し、集計手順に無関係なデータを誤って含めないようにします。
  • この記事では、留意すべきその他のベスト プラクティスについて説明します。 詳細な一覧については、 クエリのベスト プラクティスを参照してください。

構文表記規則

表記 Description
Block 示されているとおりに正確に入力される文字列リテラル。
Italic 関数またはコマンドの使用時に値を指定するパラメーター。
[ ] 囲まれた項目が省略可能であることを示します。
( ) 囲まれた項目の少なくとも 1 つが必要であることを示します。
|(パイプ) パイプ文字で区切られた項目の 1 つを指定することを示すために、角かっこまたは丸かっこで囲んで使用します。 この形式では、パイプは論理 OR 演算子と同じです。 ブロック (|) 内にある場合、パイプは KQL クエリ構文の一部です。
[, ...] 前のパラメーターをコンマで区切って複数回繰り返すことができることを示します。
; クエリ ステートメントターミネータ。

例示

スカラー関数

この例では、 ハッシュ関数の構文と使用例を示し、その後に各構文コンポーネントがどのように使用例に変換されるかを説明します。

構文

hash( source [,mod])

使用例

hash("World")
  • 関数、 hash、および始めかっこの名前は、次のように正確に入力されます。
  • "World" は、必要な ソース パラメーターの引数として渡されます。
  • mod パラメーターには引数は渡されません。角かっこで示されているように省略可能です。
  • 終わりかっこは、次のように正確に入力されます。

表形式演算子

この例では、 並べ替え演算子の構文と使用例を示し、その後に各構文コンポーネントがどのように使用例に変換されるかを説明します。

構文

T| sort bycolumn [asc | desc] [nulls first | nulls last] [, ...]

使用例

StormEvents
| sort by State asc, StartTime desc
  • StormEvents テーブルは、必要な T パラメーターの引数として渡されます。
  • | sort by は、次のように正確に入力されます。 この場合、パイプ文字は、ブロック テキストで表される 表形式の式ステートメント 構文の一部です。 詳細については、「 クエリ ステートメントとは」を参照してください。
  • State 列は、省略可能な フラグを使用して、必須ascパラメーターの引数として渡されます。
  • コンマの後に、別の引数のセット (省略可能な desc フラグを持つ StartTime 列) が渡されます。 [, ...] 構文は、より多くの引数セットが渡される可能性がありますが、必須でないことを示します。

省略可能なパラメーターの操作

別の省略可能なパラメーターの後に来る省略可能なパラメーターの引数を指定するには、前のパラメーターの引数を指定する必要があります。 この要件は、引数が構文で指定された順序に従う必要があるためです。 パラメーターに渡す特定の値がない場合は、同じ型の空の値を使用します。

シーケンシャル省略可能なパラメーターの例

http_request プラグインの構文を考えてみましょう。

evaluate http_request ( Uri [,RequestHeaders [,Options]] )

RequestHeadersOptions は、 dynamic 型の省略可能なパラメーターです。 Options パラメーターの引数を指定するには、RequestHeaders パラメーターの引数も指定する必要があります。 次の例は、2 番目の省略可能なパラメーター Options に値を指定できるように、最初の省略可能なパラメーター RequestHeaders に空の値を指定する方法を示しています。

evaluate http_request ( "https://contoso.com/", dynamic({}), dynamic({ EmployeeName: Nicole }) )