検索ジョブは、対話型と長期保有の両方で Log Analytics 内の任意のデータに対して実行する非同期クエリであり、ワークスペース内の新しい検索テーブルでの対話型クエリで、クエリ結果を利用できるようにします。 検索ジョブでは、並列処理が使用され、大規模なデータセット全体に対して数時間実行できます。 この記事では、検索ジョブを作成する方法と、結果のデータを照会する方法について説明します。
このビデオでは、検索ジョブを使うべきときと、その方法について説明します。
必要なアクセス許可
アクション | 必要なアクセス許可 |
---|---|
検索ジョブの実行 | たとえば、Microsoft.OperationalInsights/workspaces/tables/write によって提供される、Log Analytics ワークスペースに対する Microsoft.OperationalInsights/workspaces/searchJobs/write および 権限。 |
注
Entra ID テナントが Azure Lighthouse を介して管理されている場合でも、テナント間検索ジョブは現在サポートされていません。
検索ジョブを使用する場面
検索ジョブは以下のために使います。
- 長期保有および Basic と Auxiliary プランのテーブルから、Azure Monitor ログの完全な分析機能を利用できる新しい Analytics テーブルにレコードを取得します。
- ログ クエリのタイムアウトが 10 分で十分でない場合は、大量のデータをスキャンします。
検索ジョブの機能
検索ジョブでは、ソース データと同じワークスペース内の新しいテーブルに結果が送られます。 検索ジョブが開始されるとすぐに結果テーブルが使用可能になりますが、結果が表示され始めるまでに時間がかかる場合があります。
検索ジョブの結果テーブルは、Analytics テーブルであり、ログ クエリおよびワークスペース内のテーブルを使用するその他の Azure Monitor 機能で使用できます。 このテーブルでは、ワークスペースに対して設定されたリテンション期間の値が使用されますが、テーブルの作成後に、この値を変更できます。
検索結果テーブルのスキーマは、ソース テーブルのスキーマと指定されたクエリに基づいています。 次のその他の列は、ソース レコードの追跡に役立ちます。
列 | [値] |
---|---|
_OriginalType | ソース テーブルの Type 値。 |
_OriginalItemId | ソース テーブルの _ItemID 値。 |
_OriginalTimeGenerated | ソース テーブルの TimeGenerated 値。 |
タイムジェネレイテッド | 検索ジョブが実行された時刻。 |
結果テーブルに対するクエリは、最初の検索ジョブではなく、ログ クエリの監査に表示されます。
検索ジョブの実行
検索ジョブを実行して、大規模なデータセットからワークスペース内の新しい検索結果テーブルにレコードをフェッチします。
ヒント
検索ジョブの実行に対しては、料金が発生します。 そのため、検索ジョブを実行する前に、対話型クエリ モードでクエリを記述して最適化してください。
検索ジョブを実行するには、Azure portal で次のようにします。
[Log Analytics ワークスペース] メニューから [ログ] を選びます。
検索ジョブ クエリを入力するか、目的のテーブルを選択します。
画面の右側にある省略記号メニューを選択し、[ 検索ジョブ] を選択します。
時刻の選択を使用して、検索ジョブの日付範囲を指定します。 最大範囲は 1 年ですが、データ保持期間で許可される任意の 1 年間の期間を指定できます。
Kusto クエリで時間範囲も指定されている場合は、時間範囲の和集合が検索ジョブに使用されます。
検索ジョブ結果テーブルの名前を入力し、[Run a search job] (検索ジョブの実行) を選びます。
Azure Monitor ログで検索ジョブが実行され、ワークスペースに検索ジョブ結果用の新しいテーブルが作成されます。
新しいテーブルの準備ができたら、'<searchtablename>_SRCH' を選択して Log Analytics でテーブルを表示します。
新しく作成された検索ジョブ結果テーブルに挿入が開始されると、検索ジョブ結果を使用できます。
Azure Monitor ログには、完了時に 検索ジョブが完了 したことを示すメッセージが表示されます。 そのメッセージが表示されるか、進行状況に 100%が表示されると、検索クエリに一致するすべてのレコードで結果テーブルの準備が整いました。
検索ジョブの状態と詳細を取得する
検索ジョブのテーブルを削除する
テーブルに対するクエリが完了したら、検索ジョブのテーブルを削除することをお勧めします。 このベスト プラクティスにより、ワークスペースの煩雑さとデータ保持に対する追加料金が削減されます。
制限事項
検索ジョブには次の制限があります。
- 一度に 1 つのテーブルに対してクエリを実行するように最適化されています。
- 検索の日付範囲は最長で 1 年です。
- 実行時間の長い検索は、最長 24 時間でタイムアウトするまでサポートされます。
- レコード セット内の結果は、100 万レコードに制限されます。
- 同時実行は、ワークスペースごとに 5 つの検索ジョブに制限されます。
- ワークスペースあたり 100 個の検索結果テーブルに制限されます。
- 1 つのワークスペースで 1 日に実行できる検索ジョブは 100 回までに制限されます。
レコードの上限に達すると、Azure は "部分的な成功" の状態でジョブを中止し、テーブルにはその時点までに取り込まれたレコードのみが含まれます。
KQL クエリの制限事項
検索ジョブは、特定のテーブル内の大量のデータをスキャンすることを目的としています。 そのため、検索ジョブ クエリは必ずテーブル名から始める必要があります。 分散とセグメント化を使用して非同期実行を有効にするために、クエリでは、演算子を含む KQL のサブセットがサポートされています。
[where](/azure/data-explorer/kusto/query/whereoperator)
[extend](/azure/data-explorer/kusto/query/extendoperator)
[project](/azure/data-explorer/kusto/query/projectoperator)
[project-away](/azure/data-explorer/kusto/query/projectawayoperator)
[project-keep](/azure/data-explorer/kusto/query/project-keep-operator)
[project-rename](/azure/data-explorer/kusto/query/projectrenameoperator)
[project-reorder](/azure/data-explorer/kusto/query/projectreorderoperator)
[parse](/azure/data-explorer/kusto/query/parse-operator)
[parse-where](/azure/data-explorer/kusto/query/parse-where-operator)
これらの演算子内では、すべての関数と 2 項演算子を使用できます。
価格モデル
検索ジョブの料金は以下に基づきます。
検索ジョブの実行:
Analytics プラン: 検索ジョブが長期保有内でスキャンするデータの量。 Analytics テーブル内の対話型保有でのデータのスキャンには料金はかかりません。
Basic または Auxiliaryプラン: 検索ジョブが対話型と長期保有の両方でスキャンするすべてのデータ。
スキャンされるデータは、指定した時間内に、検索ジョブを実行するテーブル内のデータの量として定義されます。 対話型と長期保有について詳しくは、「Log Analytics ワークスペース内のデータ保持を管理する」をご覧ください。
検索ジョブの結果: 検索ジョブで見つかって結果テーブルに取り込まれたデータの量。Analytics テーブルのデータ インジェスト率に基づきます。
たとえば、Basic テーブルを 30 日間検索し、テーブルに 1 日あたり 500 GB のデータが保持される場合、スキャンされたデータ 15,000 GB に対して課金されます。 検索ジョブが 1,000 レコードを返す場合、これら 1,000 レコードの結果テーブルへの取り込みに対して課金されます。
詳細については、「Azure Monitor の価格」を参照してください。