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

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

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

必要なアクセス許可

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

注

テナント間検索ジョブはサポートされていません。 Azure Lighthouse の委任されたアクセスは、searchJobs/write アクセス許可を含む委任されたロールが割り当てられている場合でも、検索ジョブ (または復元) ではサポートされていません。

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

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

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

検索ジョブの機能

検索ジョブはデータをスキャンし、その結果をソース データと同じワークスペース内の新しいテーブルに送信します。 検索ジョブが開始されるとすぐに結果テーブルが使用可能になりますが、結果が表示され始めるまでに時間がかかる場合があります。 スキャンされたデータの 価格モデル と、取り込まれた結果のサイズに基づいてコストが発生します。 検索ジョブを実行する前に、ジョブを実行するかどうかを決定するのに役立つコスト見積もりを使用できます。

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

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

列	値
_OriginalType	ソース テーブルの Type 値。
_OriginalItemId	ソース テーブルの _ItemID 値。
_OriginalTimeGenerated	ソース テーブルの TimeGenerated 値。
タイムジェネレイテッド	検索ジョブが実行された時刻。

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

検索ジョブの実行

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

ヒント

検索ジョブの実行に対しては、料金が発生します。 検索ジョブを実行する前に、対話型クエリ モードでクエリを記述して最適化します。 コスト見積もりプレビューを使用して、潜在的なコストを把握します。

ポータル

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

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

2. 検索ジョブ クエリを入力するか、目的のテーブルを選択します。

3. 画面の右側にある省略記号メニューを選択し、[ 検索ジョブ] を選択します。

   

4. または、[ 実行 ] プルダウン メニューを使用して、[ 検索ジョブとして実行] を選択します。

   

5. 時刻の選択を使用して、検索ジョブの日付範囲を指定します。 合計保有期間内の任意の期間を選択します。

   Kusto クエリで時間範囲も指定されている場合は、時間範囲の和集合が検索ジョブに使用されます。

   

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

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

7. 新しいテーブルの準備ができたら、'<searchtablename>_SRCH' を選択して Log Analytics でテーブルを表示します。

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

   

   Azure Monitor ログには、完了時に 検索ジョブが完了 したことを示すメッセージが表示されます。 そのメッセージが表示されるか、進行状況に 100%が表示されると、検索クエリに一致するすべてのレコードで結果テーブルの準備が整いました。

API

検索ジョブを実行するには、Create API の操作を使用します。 この呼び出しには、作成される結果テーブルの名前が含まれています。 結果テーブルの名前は、_SRCH で終わる必要があります。

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/tables/{tablename_SRCH}?api-version={api-version}

要求本文

要求の本文には次の値を含めます。

名前	タイプ	説明
properties.searchResults.query	文字列	KQL で記述されたデータ取得のためのログ クエリ。
プロパティ.検索結果.上限	整数	結果セット内のレコードの最大数(最大 1 億レコード)。 (省略可能)
プロパティ.検索結果.開始検索時間	文字列	検索する時間範囲の始まり。
プロパティ.検索結果.検索終了時間	文字列	検索する時間範囲の終わり。

要求のサンプル

この例では、Syslog_suspected_SRCH という名前のテーブルを作成して、Syslog テーブル内の特定のレコードを検索するクエリの結果を格納します。

依頼

PUT https://management.azure.com/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/ContosoResourceGroup/providers/Microsoft.OperationalInsights/workspaces/ContosoWorkspace/tables/Syslog_suspected_SRCH?api-version={api-version}

要求本文

{
    "properties": { 
        "searchResults": {
                "query": "Syslog | where * has 'suspected.exe'",
                "limit": 1000,
                "startSearchTime": "2025-01-01T00:00:00Z",
                "endSearchTime": "2025-11-30T00:00:00Z"
            }
    }
}

Response

状態コード: 202 受け入れられました。

CLI

検索ジョブを実行するには、 az monitor log-analytics workspace table search-job create コマンドを実行します。 ルの名前は、--name パラメーターを使用して設定し、 _SRCH で終わる必要があります。

例

az monitor log-analytics workspace table search-job create --subscription aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e --resource-group ContosoResourceGroup --workspace-name ContosoWorkspace --name HeartbeatByIp_SRCH --search-query 'Heartbeat | where ComputerIP has "198.51.100.101"' --limit 1500 --start-search-time "2022-01-01T00:00:00.000Z" --end-search-time "2022-01-08T00:00:00.000Z" --no-wait

PowerShell

検索ジョブを実行するには、New-AzOperationalInsightsSearchTable コマンドを実行します。 ルの名前は、TableName パラメーターを使用して設定し、 _SRCH で終わる必要があります。

例

New-AzOperationalInsightsSearchTable -ResourceGroupName ContosoResourceGroup -WorkspaceName ContosoWorkspace -TableName HeartbeatByIp_SRCH -SearchQuery "Heartbeat" -StartSearchTime "01-01-2022 00:00:00" -EndSearchTime "01-01-2022 00:00:00"

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

ポータル

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

2. [テーブル>検索結果] で、検索結果テーブルの上にカーソルを合わせると、進行状況が表示されます。

   検索ジョブの結果テーブルのアイコンには、検索ジョブが完了するまで更新インジケーター アイコンが表示されます。

   

API

Get API の操作を使用して、検索ジョブの状態と詳細を確認します。

GET https://management.azure.com/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/tables/{tableName_SRCH}?api-version={api-version}

テーブルの状態

各検索ジョブのテーブルには provisioningState というプロパティがあり、次のいずれかの値が含まれています。

ステータス	説明
更新中	テーブルとそのスキーマを事前設定しています。
進行中	検索ジョブが実行中で、データをフェッチしています。
成功	検索ジョブが完了しました。
削除中	検索ジョブのテーブルを削除しています。

要求のサンプル

この例では、前の例の検索ジョブのテーブルの状態を取得します。

依頼

GET https://management.azure.com/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/ContosoResourceGroup/providers/Microsoft.OperationalInsights/workspaces/ContosoWorkspace/tables/Syslog_SRCH?api-version={api-version}

Response

{
        "properties": {
        "retentionInDays": 30,
        "totalRetentionInDays": 30,
        "archiveRetentionInDays": 0,
        "plan": "Analytics",
        "lastPlanModifiedDate": "Mon, 01 Nov 2021 16:38:01 GMT",
        "schema": {
            "name": "Syslog_SRCH",
            "tableType": "SearchResults",
            "description": "This table was created using a Search Job with the following query: 'Syslog | where * has 'suspected.exe'.'",
            "columns": [...],
            "standardColumns": [...],
            "solutions": [
                "LogManagement"
            ],
            "searchResults": {
                "query": "Syslog | where * has 'suspected.exe'",
                "limit": 1000,
                "startSearchTime": "Wed, 01 Jan 2020 00:00:00 GMT",
                "endSearchTime": "Fri, 31 Jan 2020 00:00:00 GMT",
                "sourceTable": "Syslog"
            }
        },
        "provisioningState": "Succeeded"
    },
    "id": "subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/ContosoResourceGroup/providers/Microsoft.OperationalInsights/workspaces/ContosoWorkspace/tables/Syslog_SRCH",
    "name": "Syslog_SRCH"
}

CLI

検索ジョブテーブルの状態と詳細を確認するには、 az monitor log-analytics workspace table show コマンドを実行します。

例

az monitor log-analytics workspace table show --subscription aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e --resource-group ContosoResourceGroup --workspace-name ContosoWorkspace --name HeartbeatByIp_SRCH --output table \

PowerShell

検索ジョブ テーブルの状態と詳細を確認するには、Get-AzOperationalInsightsTable コマンドを実行します。

例

Get-AzOperationalInsightsTable -ResourceGroupName "ContosoResourceGroup" -WorkspaceName "ContosoWorkspace" -tableName "HeartbeatByIp_SRCH"

注

"-TableName" が指定されていない場合、コマンドはワークスペースに関連付けられているすべてのテーブルを一覧表示します。

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

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

考慮事項

検索ジョブには、次の考慮事項が適用されます。

• 一度に 1 つのテーブルに対してクエリを実行するように最適化
• 検索の日付範囲は、合計保有期間内の任意の期間です
• 最長 24 時間のタイムアウトまで実行時間の長い検索をサポート
• レコード セット内の結果は 1 億件に制限されます。制限を超えた場合、Azure Monitor は 部分的な成功の状態でジョブを中止し、テーブルにはその時点まで取り込まれたレコードのみが含まれます
• 同時実行は、ワークスペースごとに 10 個の検索ジョブに制限されます。
• ワークスペースあたり 200 個の検索結果テーブルに制限
• ワークスペースあたり 1 日あたり 200 件の検索ジョブの実行に制限
• テナント間検索ジョブはサポートされていません
• 委任に適切な searchJobs/write アクセス許可が含まれている場合でも、Azure Lighthouse の委任されたアクセスは検索ジョブでサポートされていません。エラー メッセージで失敗します。
  ユーザー managing-tenant-userId< には、スコープ >delegated-workspace-resourceID におけるアクション Microsoft.OperationalInsights/workspaces/searchJobs/write へのアクセス権がありません。<>

KQL クエリに関する考慮事項

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

• where
• extend
• project
• project-away
• project-keep
• project-rename
• project-reorder
• parse
• parse-where

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

高度なテキストの一致はパフォーマンスに大きな影響を与えるので、 contains 文字列演算子は検索ジョブでの使用をブロックされます。 代わりに、 has 文字列演算子を使用します。 パフォーマンスに関する考慮事項の詳細については、「 Azure Monitor でのログ クエリの最適化」を参照してください。

価格モデル

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

• 検索ジョブの実行:

  • Analytics プラン: 検索ジョブが長期保有内でスキャンするデータの量。 Analytics テーブルの分析リテンション期間にあるデータのスキャンには料金はかかりません。

  • Basic または Auxiliaryプラン: 検索ジョブが長期保有でスキャンするすべてのデータ。

    スキャンされるデータは、指定した時間内に、検索ジョブを実行するテーブル内のデータの量として定義されます。 分析と長期的なリテンション期間の詳細については、「 Log Analytics ワークスペースでのデータ保持の管理」を参照してください。

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

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

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

関連コンテンツ

• Log Analytics ワークスペースでのデータ保有期間の管理の詳細について説明します。
• 基本および補助テーブルのクエリを直接実行する方法について理解する。