Azure Monitor で検索ジョブを実行する

検索ジョブは、対話型と長期保有の両方で Log Analytics 内の任意のデータに対して実行する非同期クエリであり、ワークスペース内の新しい検索テーブルでの対話型クエリで、クエリ結果を利用できるようにします。 検索ジョブでは、並列処理が使用され、大規模なデータセット全体に対して数時間実行できます。 この記事では、検索ジョブを作成する方法と、結果のデータを照会する方法について説明します。

このビデオでは、検索ジョブを使うべきときと、その方法について説明します。

必要なアクセス許可

アクション 必要なアクセス許可
検索ジョブの実行 たとえば、Log Analytics 共同作成者組み込みロールによって提供される、Log Analytics ワークスペースに対する Microsoft.OperationalInsights/workspaces/tables/write および Microsoft.OperationalInsights/workspaces/searchJobs/write 権限。

Note

Entra ID テナントが Azure Lighthouse を通して管理されている場合でも、テナント間検索ジョブは現在サポートされていません。

検索ジョブを使用する場面

検索ジョブは以下のために使います。

  • 長期保有および Basic と Auxiliary プランのテーブルから、Azure Monitor ログの完全な分析機能を利用できる新しい Analytics テーブルにレコードを取得します。
  • ログ クエリの 10 分のタイムアウトでは十分でない場合に、大量のデータをスキャンします。

検索ジョブの機能

検索ジョブでは、ソース データと同じワークスペース内の新しいテーブルに結果が送られます。 検索ジョブが開始されるとすぐに結果テーブルが使用可能になりますが、結果が表示され始めるまでに時間がかかる場合があります。

検索ジョブの結果テーブルは、Analytics テーブルであり、ログ クエリおよびワークスペース内のテーブルを使用するその他の Azure Monitor 機能で使用できます。 このテーブルでは、ワークスペースに対して設定されたリテンション期間の値が使用されますが、テーブルの作成後に、この値を変更できます。

検索結果テーブルのスキーマは、ソース テーブルのスキーマと指定されたクエリに基づいています。 次のその他の列は、ソース レコードの追跡に役立ちます。

[値]
_OriginalType ソース テーブルの Type 値。
_OriginalItemId ソース テーブルの _ItemID 値。
_OriginalTimeGenerated ソース テーブルの TimeGenerated 値。
TimeGenerated 検索ジョブが実行された時刻。

結果テーブルに対するクエリは、最初の検索ジョブではなく、ログ クエリの監査に表示されます。

検索ジョブの実行

検索ジョブを実行して、大規模なデータセットからワークスペース内の新しい検索結果テーブルにレコードをフェッチします。

ヒント

検索ジョブの実行に対しては、料金が発生します。 そのため、検索ジョブを実行する前に、対話型クエリ モードでクエリを記述して最適化してください。

検索ジョブを実行するには、Azure portal で次のようにします。

  1. [Log Analytics ワークスペース] メニューから [ログ] を選びます。

  2. 画面の右側にある省略記号メニューを選び、[Search job mode] (検索ジョブ モード) をオンに切り替えます。

    [Search job mode] (検索ジョブ モード) スイッチが強調表示されている [ログ] 画面のスクリーンショット。

    Azure Monitor Logs Intellisense では、検索ジョブ クエリの記述に役立つ 検索ジョブ モードでの KQL クエリの制限事項がサポートされています。

  3. 時刻の選択を使用して、検索ジョブの日付範囲を指定します。

  4. 検索ジョブ クエリを入力し、[Search Job] (検索ジョブ) ボタンを選びます。

    Azure Monitor ログで、結果セット テーブルの名前を入力するためのダイアログが表示され、検索ジョブが課金対象であることが通知されます。

    ジョブ検索結果テーブルの名前を指定するための Azure Monitor ログ プロンプトを示すスクリーンショット。

  5. 検索ジョブ結果テーブルの名前を入力し、[Run a search job] (検索ジョブの実行) を選びます。

    Azure Monitor ログで検索ジョブが実行され、ワークスペースに検索ジョブ結果用の新しいテーブルが作成されます。

    検索ジョブが実行中で、検索ジョブ結果テーブルがまもなく利用できるという Azure Monitor ログ メッセージを示すスクリーンショット。

  6. 新しいテーブルの準備ができたら、[View tablename_SRCH] (tablename_SRCH の表示) を選び、Log Analytics でテーブルを表示します。

    検索ジョブ結果テーブルが表示できるという Azure Monitor ログ メッセージを示すスクリーンショット。

    検索ジョブ結果は、新しく作成された検索ジョブ結果テーブルに挿入が開始されると、確認できます。

    データが含まれている検索ジョブ結果テーブルを示すスクリーンショット。

    Azure Monitor ログでは、検索ジョブの最後にメッセージ [検索ジョブが完了しました] が表示されます。 これで、検索クエリに一致するすべてのレコードを含む結果テーブルの準備が整いました。

    [検索ジョブが完了しました] という Azure Monitor ログ メッセージを示すスクリーンショット。

検索ジョブの状態と詳細を取得する

  1. [Log Analytics ワークスペース] メニューから [ログ] を選びます。

  2. すべての検索ジョブ結果テーブルを表示するには、[テーブル] タブで [検索結果] を選びます。

    検索ジョブ結果テーブルのアイコンは、検索ジョブが完了するまで更新中であることを示します。

    Azure portal の [ログ] 画面の [テーブル] タブを示すスクリーンショット。[検索結果] の下に検索結果テーブルが一覧表示されています。

検索ジョブのテーブルを削除する

テーブルに対するクエリが完了したら、検索ジョブのテーブルを削除することをお勧めします。 これにより、ワークスペースが整理され、データ保有に対する追加料金が削減されます。

制限事項

検索ジョブには次の制限があります。

  • 一度に 1 つのテーブルに対してクエリを実行するように最適化されています。
  • 検索の日付範囲は最長で 1 年です。
  • 実行時間の長い検索は、最長 24 時間でタイムアウトするまでサポートされます。
  • レコード セット内の結果は、100 万レコードに制限されます。
  • 同時実行は、ワークスペースごとに 5 つの検索ジョブに制限されます。
  • ワークスペースあたり 100 個の検索結果テーブルに制限されます。
  • 1 つのワークスペースで 1 日に実行できる検索ジョブは 100 回までに制限されます。

レコードの上限に達すると、Azure は "部分的な成功" の状態でジョブを中止し、テーブルにはその時点までに取り込まれたレコードのみが含まれます。

KQL クエリの制限事項

検索ジョブは、特定のテーブル内の大量のデータをスキャンすることを目的としています。 そのため、検索ジョブ クエリは必ずテーブル名から始める必要があります。 分散とセグメント化を使用して非同期実行を有効にするために、クエリでは、演算子を含む KQL のサブセットがサポートされています。

これらの演算子内では、すべての関数と 2 項演算子を使用できます。

価格モデル

検索ジョブの料金は以下に基づきます。

  • 検索ジョブの実行:

    • Analytics プラン: 検索ジョブが長期保有内でスキャンするデータの量。 Analytics テーブル内の対話型保有でのデータのスキャンには料金はかかりません。
    • Basic または Auxiliaryプラン: 検索ジョブが対話型と長期保有の両方でスキャンするすべてのデータ。

    対話型と長期保有について詳しくは、「Log Analytics ワークスペース内のデータ保持を管理する」をご覧ください。

  • 検索ジョブの結果: 検索ジョブで見つかって結果テーブルに取り込まれたデータの量。Analytics テーブルのデータ インジェスト率に基づきます。

たとえば、Basic テーブルを 30 日間検索し、テーブルに 1 日あたり 500 GB のデータが保持される場合、スキャンされたデータ 15,000 GB に対して課金されます。 検索ジョブが 1,000 レコードを返す場合、これら 1,000 レコードの結果テーブルへの取り込みに対して課金されます。

詳細については、「Azure Monitor の価格」を参照してください。

次のステップ