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

[アーティクル]
10/03/2024

検索ジョブは、対話型と長期保有の両方で 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 で次のようにします。

[Log Analytics ワークスペース] メニューから [ログ] を選びます。
画面の右側にある省略記号メニューを選び、[Search job mode] (検索ジョブモード) をオンに切り替えます。

Azure Monitor Logs Intellisense では、検索ジョブクエリの記述に役立つ検索ジョブモードでの KQL クエリの制限事項がサポートされています。
時刻の選択を使用して、検索ジョブの日付範囲を指定します。
検索ジョブクエリを入力し、[Search Job] (検索ジョブ) ボタンを選びます。

Azure Monitor ログで、結果セットテーブルの名前を入力するためのダイアログが表示され、検索ジョブが課金対象であることが通知されます。
検索ジョブ結果テーブルの名前を入力し、[Run a search job] (検索ジョブの実行) を選びます。

Azure Monitor ログで検索ジョブが実行され、ワークスペースに検索ジョブ結果用の新しいテーブルが作成されます。
新しいテーブルの準備ができたら、[View tablename_SRCH] (tablename_SRCH の表示) を選び、Log Analytics でテーブルを表示します。

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

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

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

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/tables/<TableName>_SRCH?api-version=2021-12-01-preview

要求本文

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

Name	種類	説明
properties.searchResults.query	string	KQL で記述されたデータ取得のためのログクエリ。
properties.searchResults.limit	整数 (integer)	結果セット内のレコードの最大数 (最大 100 万レコード)。 (省略可能)
properties.searchResults.startSearchTime	string	検索する時間範囲の始まり。
properties.searchResults.endSearchTime	string	検索する時間範囲の終わり。

要求のサンプル

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

Request

PUT https://management.azure.com/subscriptions/00000000-0000-0000-0000-00000000000/resourcegroups/testRG/providers/Microsoft.OperationalInsights/workspaces/testWS/tables/Syslog_suspected_SRCH?api-version=2021-12-01-preview

要求本文

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

応答

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

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

例

az monitor log-analytics workspace table search-job create --subscription ContosoSID --resource-group ContosoRG  --workspace-name ContosoWorkspace --name HeartbeatByIp_SRCH --search-query 'Heartbeat | where ComputerIP has "00.000.00.000"' --limit 1500 --start-search-time "2022-01-01T00:00:00.000Z" --end-search-time "2022-01-08T00:00:00.000Z" --no-wait

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

例

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

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

[Log Analytics ワークスペース] メニューから [ログ] を選びます。
すべての検索ジョブ結果テーブルを表示するには、[テーブル] タブで [検索結果] を選びます。

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

検索ジョブの状態と詳細を取得するには、Tables - Get API を呼び出します。

GET https://management.azure.com/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/tables/<TableName>_SRCH?api-version=2021-12-01-preview

テーブルの状態

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

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

要求のサンプル

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

Request

GET https://management.azure.com/subscriptions/00000000-0000-0000-0000-00000000000/resourcegroups/testRG/providers/Microsoft.OperationalInsights/workspaces/testWS/tables/Syslog_SRCH?api-version=2021-12-01-preview

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/00000000-0000-0000-0000-00000000000/resourcegroups/testRG/providers/Microsoft.OperationalInsights/workspaces/testWS/tables/Syslog_SRCH",
    "name": "Syslog_SRCH"
}

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

例

az monitor log-analytics workspace table show --subscription ContosoSID --resource-group ContosoRG --workspace-name ContosoWorkspace --name HeartbeatByIp_SRCH --output table \

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

例

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

Note

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

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

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

制限事項

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

一度に 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 の価格」を参照してください。

次の方法で共有