在 Azure Monitor 中运行搜索作业

在 Log Analytics 中对任何数据运行的搜索作业（包括在分析和长期保留中）是一种异步查询，使得查询结果在工作区中新建的搜索表上可用于交互式查询。搜索作业采用并行处理，可在大型数据集上运行数小时。本文介绍如何创建搜索作业以及如何查询其结果数据。

所需的权限

操作	所需的权限
运行搜索任务	对 Log Analytics 工作区具有 `Microsoft.OperationalInsights/workspaces/tables/write` 和 `Microsoft.OperationalInsights/workspaces/searchJobs/write` 权限，例如，Log Analytics 参与者内置角色所提供的权限。

注意

不支持跨租户搜索作业。即使分配了包含 searchJobs/write 权限的委派角色，Azure Lighthouse 也不支持搜索作业（或还原）的委派访问。

何时使用搜索任务

搜索作业可用于：

从长期保留以及启用了基本日志或辅助日志的表中检索记录，并将其导入新的“分析日志”表中，以便利用 Azure Monitor Logs 的完整分析功能。
如果 10 分钟的日志查询超时时间不够，则可扫描大量数据。

搜索作业有什么作用？

搜索作业会扫描数据并将其结果发送到与源数据相同的工作区中的新表。搜索作业开始后，结果表即告可用，但结果可能需要一段时间才能开始显示。根据扫描数据的定价模型和引入结果的大小产生成本。在运行搜索作业之前，可以使用成本估算来确定是否运行作业。

搜索作业结果表是一个分析日志表，可用于日志查询以及其他使用工作区中表的 Azure Monitor 功能。该表使用为工作区设置的保留值，但你可以在创建表后修改此值。

搜索结果表架构基于源表架构和指定的查询。以下其他列可帮助你跟踪源记录：

列	值
_OriginalType	源表中的 Type 值。
_OriginalItemId	源表中的 _ItemID 值。
_OriginalTimeGenerated	源表中的 TimeGenerated 值。
TimeGenerated	搜索作业运行时间。

对结果表的查询显示在日志查询审核中，但不显示在初始搜索作业中。

运行搜索任务

运行搜索作业，以将大型数据集中的记录提取到工作区中的新搜索结果表中。

提示

运行搜索作业会产生费用。在运行搜索作业之前，在交互式查询模式下编写和优化查询。使用成本估算预览了解潜在成本。

若要运行搜索作业，请在 Azure 门户中执行以下操作：

在“Log Analytics 工作区”菜单中，选择“日志”。
输入搜索作业查询条件，或选择所需的表。
选择屏幕右侧的省略号菜单，然后选择 “搜索作业”。
或者使用“运行”下拉菜单，然后选择“以搜索作业运行”。
使用时间选取器指定搜索作业日期范围。选择总保留期内的任意时间段。

如果你的 Kusto 查询还指定了时间范围，则使用时间范围的合并来进行搜索作业。
请输入搜索作业结果表的名称，然后选择“运行搜索作业”。

Azure Monitor 日志运行搜索作业，并在工作区中为搜索作业结果创建新表。
新表准备就绪后，选择 “<查看”searchtablename>_SRCH“ 以查看 Log Analytics 中的表。

搜索作业结果在开始流入新创建的搜索作业结果表时可用。

Azure Monitor 日志显示搜索作业已完成时，会出现已完成消息。当你看到该消息或进度显示为 100%时，结果表格已经准备好，包含与搜索查询匹配的所有记录。

以下 Azure CLI 示例中使用了 az monitor log-analytics workspace table search-job create 命令。它通过运行搜索作业创建Log Analytics工作区搜索结果表。使用 --name 参数设置的结果表的名称必须以结尾 _SRCH。

# Set variables
resourceGroupName="<ResourceGroupName>"
workspaceName="<WorkspaceName>"
tableName="<TableName>_SRCH"
searchQuery='Heartbeat | where ComputerIP has "198.51.100.101"'
limit=1500
startSearchTime="2026-01-01T00:00:00.000Z"
endSearchTime="2026-01-08T00:00:00.000Z"

# Create the Log Analytics workspace search results table
az monitor log-analytics workspace table search-job create \
  --resource-group "$resourceGroupName" \
  --workspace-name "$workspaceName" \
  --name "$tableName" \
  --search-query "$searchQuery" \
  --limit "$limit" \
  --start-search-time "$startSearchTime" \
  --end-search-time "$endSearchTime" \
  --no-wait

注意

Azure CLI命令使用当前 CLI 上下文中的Azure 资源管理器终结点，因此无需在命令语法中指定 management.chinacloudapi.cn。

以下Azure PowerShell示例使用 New-AzOperationalInsightsSearchTable cmdlet。它通过运行搜索作业创建Log Analytics工作区搜索结果表。使用 -TableName 参数设置的结果表的名称必须以结尾 _SRCH。

# Set variables
$resourceGroupName = "<ResourceGroupName>"
$workspaceName = "<WorkspaceName>"
$tableName = "<TableName>_SRCH"
$searchQuery = 'Heartbeat | where ComputerIP has "198.51.100.101"'
$limit = 1500
$startSearchTime = "2026-01-01T00:00:00.000Z"
$endSearchTime = "2026-01-08T00:00:00.000Z"

# Create the Log Analytics workspace search results table
$newAzOperationalInsightsSearchTableParams = @{
    ResourceGroupName = $resourceGroupName
    WorkspaceName     = $workspaceName
    TableName         = $tableName
    SearchQuery       = $searchQuery
    Limit             = $limit
    StartSearchTime   = $startSearchTime
    EndSearchTime     = $endSearchTime
}

New-AzOperationalInsightsSearchTable @newAzOperationalInsightsSearchTableParams

注意

Azure PowerShell cmdlet 使用当前 Az 上下文中的Azure 资源管理器终结点，因此无需在 cmdlet 语法中指定management.chinacloudapi.cn。

以下 REST 示例使用表 - 创建或更新 REST API 操作。调用包括要创建的结果表的名称。结果表的名称必须以 _SRCH 结尾。

在请求正文中包含以下值：

名称	类型	说明
属性.搜索结果.查询	字符串	用 KQL 编写的日志查询以检索数据。
属性.搜索结果.限制	整数	结果集中的最大记录数，最多 1 亿条记录。 (可选)
属性.搜索结果.开始搜索时间	字符串	搜索时间范围的开始时间。
属性.搜索结果.结束搜索时间	字符串	搜索的时间范围的结束时间。

示例请求：

此示例通过运行一个搜索作业，在 Heartbeat 表中搜索具有特定计算机 IP 地址的记录，从而创建一个搜索结果表。

PUT https://management.chinacloudapi.cn/subscriptions/{SubscriptionId}/resourceGroups/{ResourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{WorkspaceName}/tables/{TableName}_SRCH?api-version=2025-07-01
Authorization: Bearer {AccessToken}
Content-Type: application/json

{
  "properties": {
    "searchResults": {
      "query": "Heartbeat | where ComputerIP has \"198.51.100.101\"",
      "limit": 1500,
      "startSearchTime": "2026-01-01T00:00:00.000Z",
      "endSearchTime": "2026-01-08T00:00:00.000Z"
    }
  }
}

响应：

状态代码：202 已接受。

获取搜索工作状态和详细信息

在“Log Analytics 工作区”菜单中，选择“日志”。
在“表搜索结果”>中，将鼠标悬停在搜索结果表上以查看进度。

搜索作业结果表中的图标会显示更新指示器图标，直到搜索作业完成。

以下 Azure CLI 示例使用 az monitor log-analytics workspace table show 命令。它检索搜索作业表的状态和详细信息。

# Set variables
resourceGroupName="<ResourceGroupName>"
workspaceName="<WorkspaceName>"
tableName="<TableName>_SRCH"

# Get the status and details of the search job table
az monitor log-analytics workspace table show \
  --resource-group "$resourceGroupName" \
  --workspace-name "$workspaceName" \
  --name "$tableName" \
  --output table

注意

Azure CLI命令使用当前 CLI 上下文中的Azure 资源管理器终结点，因此无需在命令语法中指定 management.chinacloudapi.cn。

以下Azure PowerShell示例使用 Get-AzOperationalInsightsTable cmdlet。它检索搜索作业表的状态和详细信息。

# Set variables
$resourceGroupName = "<ResourceGroupName>"
$workspaceName = "<WorkspaceName>"
$tableName = "<TableName>_SRCH"

# Get the status and details of the search job table
$getAzOperationalInsightsTableParams = @{
    ResourceGroupName = $resourceGroupName
    WorkspaceName     = $workspaceName
    TableName         = $tableName
}

Get-AzOperationalInsightsTable @getAzOperationalInsightsTableParams

如果未提供 -TableName，该 cmdlet 将列出与工作区关联的所有表。

注意

Azure PowerShell cmdlet 使用当前 Az 上下文中的Azure 资源管理器终结点，因此无需在 cmdlet 语法中指定management.chinacloudapi.cn。

以下 REST 示例使用表 - 获取 REST API 操作。它检索搜索作业表的状态和详细信息。

每个搜索作业表都有一个名为的属性，该属性 provisioningState可以具有以下值之一：

状态	说明
正在更新	填充表及其架构。
进行中	搜索作业正在运行，正在获取数据。
成功	搜索作业已完成。
正在删除	删除搜索作业表。

示例请求：

本示例检索上一示例中搜索作业的表状态。

GET https://management.chinacloudapi.cn/subscriptions/{SubscriptionId}/resourceGroups/{ResourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{WorkspaceName}/tables/{TableName}_SRCH?api-version=2025-07-01
Authorization: Bearer {AccessToken}
Content-Type: application/json

响应：

{
  "properties": {
    "retentionInDays": 30,
    "totalRetentionInDays": 30,
    "archiveRetentionInDays": 0,
    "plan": "Analytics",
    "lastPlanModifiedDate": "Mon, 01 Nov 2021 16:38:01 GMT",
    "schema": {
      "name": "<TableName>_SRCH",
      "tableType": "SearchResults",
      "description": "This table was created using a Search Job with the following query: 'Heartbeat | where ComputerIP has \"198.51.100.101\"'.",
      "columns": [],
      "standardColumns": [],
      "solutions": [
        "LogManagement"
      ],
      "searchResults": {
        "query": "Heartbeat | where ComputerIP has \"198.51.100.101\"",
        "limit": 1500,
        "startSearchTime": "Thu, 01 Jan 2026 00:00:00 GMT",
        "endSearchTime": "Thu, 08 Jan 2026 00:00:00 GMT",
        "sourceTable": "Heartbeat"
      }
    },
    "provisioningState": "Succeeded"
  },
  "id": "subscriptions/<SubscriptionId>/resourceGroups/<ResourceGroupName>/providers/Microsoft.OperationalInsights/workspaces/<WorkspaceName>/tables/<TableName>_SRCH",
  "name": "<TableName>_SRCH"
}

删除搜索任务表

查询完该表后，删除搜索作业表此最佳做法可减少工作区混乱和数据保留的额外费用。

注意事项

搜索作业受以下注意事项的约束：

针对一次查询一个表进行优化
搜索日期范围是总保留期内的任何时间段
支持长时间运行的搜索，最多 24 小时超时
结果限制为记录集中最多 1 亿条记录 - 如果超出限制，Azure Monitor 会将作业中止，状态为部分成功，而表格仅包含到达该点时已摄取的记录。
每个工作区的并发执行限制为 10 个搜索作业。
每个工作区最多可显示 200 个搜索结果表。
每个工作区每天只能执行 200 个搜索作业
不支持跨租户搜索作业
即使 Azure Lighthouse 委托访问中包含适当的 searchJobs/write 权限，搜索作业仍然不支持这种访问，将失败并显示错误消息：

用户 managing-tenant-userId< 在作用域 >delegated-workspace-resourceID 上没有执行 Microsoft.OperationalInsights/workspaces/searchJobs/write 操作的访问权限<>。

KQL 查询注意事项

搜索作业会扫描特定表中的大量数据，因此搜索作业查询必须始终以表名称开头。若要通过分布和分段启用异步执行，查询支持 KQL 的子集，包括以下表格运算符：

这些运算符中的所有函数和二进制运算符都可用。

contains字符串运算符被阻止在搜索作业中使用，因为高级文本匹配对性能有重大影响。请改用 has 字符串运算符。有关性能注意事项的详细信息，请参阅 Azure Monitor 中的优化日志查询。

定价模型

搜索作业的费用基于以下因素：

搜索作业执行情况
- 分析日志 - 搜索作业扫描的长期保留数据量。
  
  注意
  
  对于分析日志，扫描分析保留中的数据不收取任何费用。
- 基本方案或辅助方案 - 搜索作业在查询时间范围内扫描的所有数据。
扫描的数据定义为在指定的时间范围内运行搜索作业的表中的数据量。有关分析和长期保留的详细信息，请参阅在 Log Analytics 工作区中管理数据保留。
搜索作业结果 - 搜索作业根据分析日志的数据引入率在结果表中查找到并引入的数据量。

定价示例

如果对包含分析日志的表进行搜索需要 60 天，并且表每天引入 500 GB 的数据，但表的分析保留期设置为 30 天，则针对 15,000 GB 的扫描数据（仅长期保留 30 天的数据）收费。在分析保留期内扫描 30 天的数据无需付费。如果搜索作业返回 1,000 条记录，则需要支付将这 1,000 条记录引入结果表中的费用。

如果对包含基本日志或辅助日志的表进行搜索需要 60 天，并且该表每天引入 500 GB 的数据，则针对扫描的数据收取 30,000 GB 的费用。如果搜索作业返回 1,000 条记录，则需要支付将这 1,000 条记录引入结果表中的费用。

有关详细信息，请参阅 Azure Monitor 定价。

Last updated on 2026-07-17