在 Azure Monitor 中还原日志

项目
09/04/2024

还原操作使表中数据的特定时间范围在热缓存中可用于高性能查询。本文介绍如何还原数据、查询该数据，然后在完成后关闭数据。

权限

若要从长期保留还原数据，需要 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"
    }
  }
}

要从表中还原数据，请运行 az monitor log-analytics workspace table restore create 命令。

例如：

az monitor log-analytics workspace table restore create --subscription ContosoSID --resource-group ContosoRG  --workspace-name ContosoWorkspace --name Heartbeat_RST --restore-source-table Heartbeat --start-restore-time "2022-01-01T00:00:00.000Z" --end-restore-time "2022-01-08T00:00:00.000Z" --no-wait

查询还原的数据

还原的日志保留其原始时间戳。在还原的日志上运行查询时，根据最初生成数据的时间设置查询时间范围。

按以下任一方式设置查询时间范围：

在查询编辑器顶部的“时间范围”下拉列表中选择“自定义”，并设置“从”和“到”值。

或

在查询中指定时间范围。例如：

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 日志。

通过