在 Azure Monitor 中还原日志
还原操作使表中数据的特定时间范围在热缓存中可用于高性能查询。 本文介绍如何还原数据、查询该数据,然后在完成后关闭数据。
权限
若要从长期保留还原数据,需要 Log Analytics 工作区的 Microsoft.OperationalInsights/workspaces/tables/write
和 Microsoft.OperationalInsights/workspaces/restoreLogs/write
权限,例如,由 Log Analytics 参与者内置角色提供的权限。
何时还原日志
使用还原操作查询长期保留中的数据。 如果你在源表上运行的日志查询无法在 10 分钟的日志查询超时内完成,你还可以使用还原操作在任何 Analytics 表的特定时间范围内对任何 Analytics 表运行功能强大的查询。
注意
还原是用于访问长期保留中的数据的一种方法。 使用还原对特定时间范围内的一组数据运行查询。 使用搜索作业根据特定条件访问数据。
还原有什么作用?
还原数据时,可以指定包含要查询的数据的源表以及要创建的新目标表的名称。
还原操作将创建还原表,并分配额外的计算资源,以便使用支持完整 KQL 的高性能查询查询还原的数据。
目标表提供基础源数据的视图,但不会以任何方式影响它。 该表没有保留设置,你必须在不再需要还原的数据时显式消除还原的数据。
还原数据
要从表中还原数据,请调用表 - 创建或更新 API。 目标表的名称必须以 _RST 结尾。
PUT https://management.chinacloudapi.cn/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/tables/{user defined name}_RST?api-version=2021-12-01-preview
请求正文
请求正文必须包含以下值:
名称 | Type | 说明 |
---|---|---|
properties.restoredLogs.sourceTable | string | 包含要还原的数据的表。 |
properties.restoredLogs.startRestoreTime | string | 还原的时间范围的开始时间。 |
properties.restoredLogs.endRestoreTime | string | 还原的时间范围的结束时间。 |
还原表状态
ProvisioningState 属性指示还原表操作的当前状态。 API 会在你启动还原时返回此属性,你可以稍后使用对表执行 GET 操作来检索此属性。 provisioningState 属性具有下列值之一:
值 | 说明 |
---|---|
更新 | 正在执行还原操作。 |
已成功 | 还原操作已完成。 |
正在删除 | 正在删除还原的表。 |
示例请求
此示例将 2020 年 1 月的数据从 Usage 表还原到名为 Usage_RST 的表。
请求
PUT https://management.chinacloudapi.cn/subscriptions/00000000-0000-0000-0000-00000000000/resourcegroups/testRG/providers/Microsoft.OperationalInsights/workspaces/testWS/tables/Usage_RST?api-version=2021-12-01-preview
请求正文:
{
"properties": {
"restoredLogs": {
"startRestoreTime": "2020-01-01T00:00:00Z",
"endRestoreTime": "2020-01-31T00:00:00Z",
"sourceTable": "Usage"
}
}
}
查询还原的数据
还原的日志保留其原始时间戳。 在还原的日志上运行查询时,根据最初生成数据的时间设置查询时间范围。
按以下任一方式设置查询时间范围:
在查询编辑器顶部的“时间范围”下拉列表中选择“自定义”,并设置“从”和“到”值。
或在查询中指定时间范围。 例如:
let startTime =datetime(01/01/2022 8:00:00 PM); let endTime =datetime(01/05/2022 8:00:00 PM); TableName_RST | where TimeGenerated between(startTime .. endTime)
消除还原的数据
为了节省成本,我们建议你删除已还原的表,以便在不再需要时消除已还原数据。
删除还原的表不会删除源表中的数据。
注意
只要基础源数据可用,还原的数据就可用。 从工作区中删除源表或源表的保留期结束时,将从还原的表中消除数据。 但是,如果不显式删除空表,则将保留该空表。
限制
还原存在以下限制。
可以:
还原至少两天的数据。
最多可还原 60 TB。
在工作区中最多能够同时运行两个还原过程。
在给定时间对某个特定表只能运行一个有效的还原。 对已具有活动还原的表执行第二次还原将失败。
每周内,对每个表最多可以执行四次还原。
定价模型
已还原日志的费用取决于恢复的数据量,以及还原处于活动状态的持续时间。 因此,价格单位为每天每 GB。 数据还原按还原处于活动状态的每个 UTC 日计费。
由于还原会为查询还原的数据分配额外的计算资源,因此收费以每次还原最低 2 TB 的还原数据量为准。 如果还原的数据较少,则每天最低需要支付 2 TB 的费用,直至还原被消除。
在还原处于活动状态的第一天和最后一天,仅对还原处于活动状态的一部分计费。
最低费用为 12 小时还原持续时间,即使还原处于活动状态,也不到 12 小时。
有关数据还原价格的详细信息,请参阅“日志”选项卡上 Azure Monitor 定价。
下面是演示数据还原成本计算的一些示例:
如果表每天保留 500 GB,并且从该表还原 10 天的数据,则总还原大小为 5 TB。 每天为此 5 TB 的还原数据付费,直到 消除还原的数据。 每日成本为 5,000 GB,乘以数据还原价格(请参阅 Azure Monitor 定价)。
相反,仅还原 700 GB 的数据,则每天对 2 TB 的最低还原级别计费还原处于活动状态。 每日成本为 2,000 GB,乘以数据还原价格。
如果 5 TB 的数据还原仅在 1 小时内保持活动状态,则最低计费为 12 小时。 此数据还原的成本为 5,000 GB,乘以数据还原价格乘以 0.5 天(最低 12 小时)。
如果 700 GB 的数据还原仅在 1 小时内保持活动状态,则最低计费为 12 小时。 此数据还原的成本为 2,000 GB(最低计费还原大小)乘以数据还原价格乘以 0.5 天(最低 12 小时)。
注意
查询还原的日志是免费的,因为它们是 Analytics 日志。