Share via


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

検索ジョブは、詳細な分析のために、ワークスペース内の新しい検索テーブルにレコードをフェッチする非同期クエリです。 検索ジョブでは、並列処理が使用され、大規模なデータセット全体に対して数時間実行できます。 この記事では、検索ジョブを作成する方法と、結果のデータを照会する方法について説明します。

アクセス許可

検索ジョブを実行するには、Log Analytics ワークスペースに対する Microsoft.OperationalInsights/workspaces/tables/write および Microsoft.OperationalInsights/workspaces/searchJobs/write のアクセス許可が必要です。これらは、たとえば 組み込みの Log 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 項演算子を使用できます。

価格モデル

検索ジョブの料金は、次の条件に基づいています。

  • 検索ジョブの実行 - 検索ジョブでスキャンするデータの量。
  • 検索ジョブの結果 - 検索ジョブで見つかって結果テーブルに取り込まれたデータの量。通常のログ データ インジェスト価格に基づきます。

たとえば、テーブルで 1 日あたり 500 GB が保持される場合、検索を 30 日間使用すると、スキャンされた 15,000 GB のデータに対して課金されます。 検索ジョブで検索クエリに一致する 1,000 個のレコードが検出された場合、これらの 1,000 件のレコードを結果テーブルに取り込むことに対して課金されます。

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

次のステップ