还原操作使表中数据的特定时间范围在热缓存中可用于高性能查询。 你指定源表和时间范围后,Azure Monitor 会创建一个以 _RST 结尾的目标表,你可以对还原的数据运行完整的 KQL 查询。 完成后,删除该还原项即可停止计费。
还原是访问 长期保留中的数据的一种方法。 使用还原功能对特定时间范围内的数据执行完整的 Kusto 查询语言(KQL)查询。 使用 搜索作业,根据特定条件访问数据。 此外,当日志查询无法在 10 分钟的超时时间内完成时,还可以使用还原操作针对任意 Analytics 表运行查询。
先决条件
若要从长期保留中还原数据,您需要具有对 Log Analytics 工作区的Microsoft.OperationalInsights/workspaces/tables/write和Microsoft.OperationalInsights/workspaces/restoreLogs/write权限。
Log Analytics参与者内置角色提供这些权限。
具有 辅助表计划的表 不支持数据还原。 使用 搜索作业 从辅助表中检索处于长期保留中的数据。
注意
Azure Lighthouse不支持对还原作业或搜索作业的委派访问权限,即使委派角色包含restoreLogs/write权限也是如此。
恢复数据
还原数据时,请指定源表和新目标表的名称。 目标表名称必须以 _RST. 结尾。 还原操作创建此表,并使用支持完整 KQL 的高性能查询为查询还原的数据分配额外的计算资源。 目标表提供基础源数据的视图,但不会影响它。
以 ISO 8601 格式指定开始和结束时间作为 UTC 字符串,例如 2026-01-01T00:00:00Z。 在源表的保留数据中选择满足 还原约束的范围。
Important
还原开始时即开始计费,并持续到你删除已还原的数据为止。 查询完成后立即关闭还原操作。 有关成本详细信息,请参阅 还原定价。
以下Azure CLI示例使用az monitor log-analytics workspace table restore create命令。 它将源表中的数据时间范围还原到新的目标表中。 使用 --name 参数设置的目标表的名称必须以结尾 _RST。
# Set variables
resourceGroupName="<ResourceGroupName>"
workspaceName="<WorkspaceName>"
tableName="<TableName>_RST"
sourceTable="<SourceTableName>"
startRestoreTime="<StartRestoreTime>"
endRestoreTime="<EndRestoreTime>"
# Create the Log Analytics workspace restore logs table
az monitor log-analytics workspace table restore create \
--resource-group "$resourceGroupName" \
--workspace-name "$workspaceName" \
--name "$tableName" \
--restore-source-table "$sourceTable" \
--start-restore-time "$startRestoreTime" \
--end-restore-time "$endRestoreTime" \
--no-wait
注意
Azure CLI命令使用当前 CLI 上下文中的Azure 资源管理器终结点,因此无需在命令语法中指定 management.chinacloudapi.cn。
以下Azure PowerShell示例使用 New-AzOperationalInsightsRestoreTable cmdlet。 它将源表中的数据时间范围还原到新的目标表中。 使用 -TableName 参数设置的目标表的名称必须以结尾 _RST。
# Set variables
$resourceGroupName = "<ResourceGroupName>"
$workspaceName = "<WorkspaceName>"
$tableName = "<TableName>_RST"
$sourceTable = "<SourceTableName>"
$startRestoreTime = "<StartRestoreTime>"
$endRestoreTime = "<EndRestoreTime>"
# Define parameters for New-AzOperationalInsightsRestoreTable
$newAzOperationalInsightsRestoreTableParams = @{
ResourceGroupName = $resourceGroupName
WorkspaceName = $workspaceName
TableName = $tableName
SourceTable = $sourceTable
StartRestoreTime = $startRestoreTime
EndRestoreTime = $endRestoreTime
}
# Create the Log Analytics workspace restore logs table
New-AzOperationalInsightsRestoreTable @newAzOperationalInsightsRestoreTableParams
注意
Azure PowerShell cmdlet 使用当前 Az 上下文中的Azure 资源管理器终结点,因此无需在 cmdlet 语法中指定management.chinacloudapi.cn。
以下 REST 示例使用 Tables - Create Or Update REST API 操作。 它将源表中的数据时间范围还原到新的目标表中。 目标表的名称必须以 _RST 结尾。
在请求正文中包含以下值:
| 名称 |
类型 |
说明 |
properties.restoredLogs.sourceTable |
字符串 |
包含要还原的数据的表。 |
properties.restoredLogs.startRestoreTime |
string (date-time) |
要还原的时间范围的开始时间,以 UTC 为单位。 |
properties.restoredLogs.endRestoreTime |
string (date-time) |
要还原的时间范围的结束时间,以 UTC 为单位。 |
恢复表状态
该 provisioningState 属性指示还原表操作的当前状态。 API 在启动还原时返回此属性,稍后使用 GET 表上的操作检索此属性。 该 provisioningState 属性具有以下值之一:
| 值 |
说明 |
| 正在更新 |
正在更新表架构;表已锁定以供更改。 |
| 进行中 |
表架构稳定,但表数据仍在更新。 |
| 成功 |
还原操作已完成。 |
| 正在删除 |
正在删除已还原的表。 |
示例请求
本示例将所选源表和时间范围还原到新 _RST 表中。
PUT https://management.chinacloudapi.cn/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/tables/{tableName}_RST?api-version={apiVersion}
Authorization: Bearer {accessToken}
Content-Type: application/json
{
"properties": {
"restoredLogs": {
"sourceTable": "<SourceTableName>",
"startRestoreTime": "<StartRestoreTime>",
"endRestoreTime": "<EndRestoreTime>"
}
}
}
响应
状态代码: 202 Accepted 用于异步还原。 API 还记录了已完成操作的 200 OK。 在查询还原的数据之前,请检查表的 provisioningState。
注意
Bicep 部署是创建或更新操作,而不是局部 PATCH 操作。 使用新的 _RST 表名称;不要在正在进行的还原操作期间重新部署。 父工作区属于现有资源,不会重新部署。
以下Bicep示例使用Microsoft.OperationalInsights/workspaces/tables资源类型。 它会为所选源表和时间范围创建还原表。
param workspaceName string = '<WorkspaceName>'
param tableName string = '<TableName>_RST'
param sourceTable string = '<SourceTableName>'
param startRestoreTime string = '<StartRestoreTime>'
param endRestoreTime string = '<EndRestoreTime>'
resource logAnalyticsWorkspace 'Microsoft.OperationalInsights/workspaces@<ApiVersion>' existing = {
name: workspaceName
}
resource restoredTable 'Microsoft.OperationalInsights/workspaces/tables@<ApiVersion>' = {
parent: logAnalyticsWorkspace
name: tableName
properties: {
restoredLogs: {
sourceTable: sourceTable
startRestoreTime: startRestoreTime
endRestoreTime: endRestoreTime
}
}
}
注意
ARM 模板部署是创建或更新操作,而不是部分 PATCH 操作。 使用新的 _RST 表名称;不要在正在进行的还原操作期间重新部署。 此模板不会重新部署父工作区。
以下 ARM 模板示例使用 Microsoft.OperationalInsights/workspaces/tables 资源类型。 它会为所选源表和时间范围创建还原表。
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"workspaceName": {
"type": "string",
"defaultValue": "<WorkspaceName>"
},
"tableName": {
"type": "string",
"defaultValue": "<TableName>_RST"
},
"sourceTable": {
"type": "string",
"defaultValue": "<SourceTableName>"
},
"startRestoreTime": {
"type": "string",
"defaultValue": "<StartRestoreTime>"
},
"endRestoreTime": {
"type": "string",
"defaultValue": "<EndRestoreTime>"
}
},
"resources": [
{
"type": "Microsoft.OperationalInsights/workspaces/tables",
"apiVersion": "<ApiVersion>",
"name": "[format('{0}/{1}', parameters('workspaceName'), parameters('tableName'))]",
"properties": {
"restoredLogs": {
"sourceTable": "[parameters('sourceTable')]",
"startRestoreTime": "[parameters('startRestoreTime')]",
"endRestoreTime": "[parameters('endRestoreTime')]"
}
}
}
]
}
对于异步还原,请使用 Get-AzOperationalInsightsTable、Tables - Get 或 az monitor log-analytics workspace table show 检索目标表。 等到provisioningState变为Succeeded后再查询。
查询还原的数据
在 Azure Monitor 中查询已还原的表时,请使用目标表名称(以 _RST 结尾)。 还原的日志保留其原始时间戳,而不是还原操作的时间。 根据最初生成数据的时间设置查询时间范围。
按以下任一方式设置查询时间范围:
忽略已还原的数据
弃用已恢复的数据意味着删除目标 _RST 表以停止恢复计费。
不再需要还原的表时,请将其删除 。
删除还原的表不会删除源表中的数据。
注意
只要基础源数据可用,还原的数据就可用。 当您从工作区中删除源表,或者源表的保留期结束时,数据会从还原的表中删除。 但是,空表仍会一直保留,直到你明确将其删除。
还原注意事项
Azure Monitor中的还原操作具有以下约束:
-
支持的表套餐:Analytics 和 Basic。 不支持 辅助计划 。
-
最小时间范围:每次恢复至少需要两天的数据。
-
最大数据量:每次还原最多 60 TB。
-
并发还原:每个工作区最多同时执行两个还原过程。
-
每个表只能有一个正在进行的还原操作:如果某个表已存在正在进行的还原操作,则对该表运行第二次还原会失败。
-
每周限制:每个表每周最多 4 次还原。
恢复定价
还原日志的成本取决于还原的数据量以及还原处于活动状态的持续时间。 还原处于活动状态的每个 UTC 日内,价格为 每 GB 每天。
密钥定价规则:
-
最小数据量:每次恢复 2 TB。 如果恢复的数据量不足 2 TB,仍按 2 TB 收费。
-
最短持续时间:12 小时。 如果还原处于活动状态的时间不足 12 小时,仍将按 12 小时(0.5 天)收费。
-
部分日计费:在第一天和最后一天,仅对还原处于活动状态的一天部分进行计费。
-
无查询费用:由于还原的表使用 Analytics 计划,查询还原的数据没有额外费用。
有关定价详细信息,请参阅Azure Monitor定价的“日志”选项卡。
成本示例
| 情景 |
已还原的数据 |
Duration |
每日计费量 |
计算 |
| 大规模恢复,持续多天 |
5 TB(500 GB/天× 10 天) |
直至关闭 |
5,000 GB |
5,000 GB × 每 GB/天的价格 × 活跃天数 |
| 小规模恢复,持续多天 |
700 GB |
直至关闭 |
2,000 GB (最小值) |
2,000 GB × 每 GB/天的价格 × 活跃天数 |
| 大型恢复,1 小时 |
5 TB(兆字节) |
1 小时 |
5,000 GB |
5,000 GB × 每 GB/天的价格 × 0.5 天(至少 12 小时) |
| 小型恢复,1 小时 |
700 GB |
1 小时 |
2,000 GB (最小值) |
2,000 GB × 每 GB/天价格 × 0.5 天(至少 12 小时) |
相关内容