你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

从 HTTP 数据收集器 API 迁移到日志引入 API，以将数据发送到 Azure Monitor 日志

  • 项目

与旧版 HTTP 数据收集器 API 相比，Azure Monitor 日志引入 API 在引入日志和管理表方面提供了更强的处理能力和更大的灵活性。 本文介绍数据收集器 API 与日志引入 API 之间的差异，并提供了有关迁移到新的日志引入 API 的指南和最佳做法。

注意

作为 Microsoft MVP，Morten Waltorp Knudsen 为本文做出了贡献并提供了材料反馈。 有关如何自动进行设置和持续使用日志引入 API 的示例，请查看 Morten 公开提供的 AzLogDcrIngestPS PowerShell 模块。

日志引入 API 的优点

与数据收集器 API 相比，日志引入 API 具有以下优势：

  • 支持转换，让你能够在将数据引入目标表之前对数据进行修改（包括筛选和数据操作）。
  • 让你能够将数据发送到多个目标。
  • 让你能够管理目标表架构（包括列名），并可管理是否在源数据架构更改时向目标表添加新列。

先决条件

本文中描述的迁移过程假定你具有：

所需的权限

操作 所需的权限
创建数据收集终结点。 Microsoft.Insights/dataCollectionEndpoints/write 权限，例如，监视参与者内置角色所提供的权限。
创建或修改数据收集规则。 Microsoft.Insights/DataCollectionRules/Write 权限，例如，监视参与者内置角色所提供的权限。
将使用数据收集器 API 的表转换为数据收集规则和日志引入 API。 Microsoft.OperationalInsights/workspaces/tables/migrate/action 权限，例如，Log Analytics 参与者内置角色所提供的权限。
创建新表或修改表架构。 microsoft.operationalinsights/workspaces/tables/write 权限，例如，Log Analytics 参与者内置角色所提供的权限。
调用日志引入 API。 请参阅分配对 DCR 的权限。

创建日志引入 API 所需的新资源

日志引入 API 要求创建下面两种新的资源类型，HTTP 数据收集器 API 不需要这些资源：

迁移现有自定义表或创建新表

如果你现在已有当前使用数据收集器 API 将数据发送到的表，你可以：

  • 迁移表，以继续使用日志引入 API 将数据引入到相同的表。

  • 维护现有表和数据，并设置一个新表 - 你使用日志引入 API 将数据引入到该新表中。 然后，你可在准备好后删除旧表。

    这是首选选项，尤其是在需要对现有表进行更改时。 如果更改现有数据类型和现有数据收集器 API 自定义表进行多个架构更改，都可能导致错误。

提示

若要确定哪些表使用数据收集器 API，请查看表属性。 使用数据收集器 API 的表的“类型”属性设置为“自定义表(经典)”。 请注意，使用旧版 Log Analytics 代理 (MMA) 引入数据的表的“类型”属性也设置为“自定义表(经典)”。 在转换 MMA 表之前，请务必先从 Log Analytics 代理迁移到 Azure Monitor 代理。 否则，在表转换后，会停止将数据引入到这些表的自定义字段中。

下表总结了对于每个选项，需要注意的事项：

表迁移 并行实现
表和列命名 重用现有表名。
列命名选项：
- 使用新的列名并定义转换，以将传入数据定向到新命名的列。
- 继续使用旧名称。		 随意设置新的表名。
在切换到新表之前，需要调整集成、仪表板和警报。
迁移过程 一次性表迁移。 无法回滚已迁移的表。 可以按表逐步完成迁移。
迁移后 可继续使用 HTTP 数据收集器 API 和现有列（自定义列除外）引入数据。
仅使用日志引入 API 将数据引入新列。		 旧表中的数据在保持期结束之前可用。
首次设置新表或进行架构更改时，数据更改可能需要 10-15 分钟才会开始显示在目标表中。

若要将使用数据收集器 API 的表转换为数据收集规则和日志引入 API，请对表发出此 API 调用：

POST https://management.azure.com/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/tables/{tableName}/migrate?api-version=2021-12-01-preview

此调用是幂等的，因此如果已转换表，则没有任何影响。

API 调用会在表上启用所有基于 DCR 的自定义日志功能。 数据收集器 API 会继续将数据引入到现有列，但不会创建任何新列。 不会继续填充之前定义的任何自定义字段。 要将现有表迁移到使用数据收集规则（但不一定是日志引入 API），另一种方法是对表应用工作区转换。

重要

  • 列名必须以字母开头，最多可包含 45 个字母数字字符和下划线 (_)。
  • _ResourceId、id、_ResourceId、_SubscriptionId、TenantId、Type、UniqueId 和 Title 是保留的列名。
  • 添加到 Azure 表的自定义列必须具有后缀 _CF。
  • 如果更新 Log Analytics 工作区中的表架构，还必须更新数据收集规则中的输入流定义，以将数据引入新的列或修改后的列。

调用日志引入 API

使用日志引入 API，每次调用最多可发送 1 MB 的压缩或未压缩数据。 如果需要发送超过 1 MB 的数据，可并行发送多个调用。 这是数据收集器 API 的一项更改，有了它，每次调用最多可发送 32 MB 的数据。

若要了解如何调用日志引入 API，请参阅日志引入 REST API 调用。

基于对源数据对象的更改修改表架构和数据收集规则

当源数据对象架构发生更改时，数据收集器 API 会自动调整目标表架构，而日志引入 API 则不会。 这可确保不会将新数据收集到不打算创建的列中。

当源数据架构发生更改时，你可以：

  • 修改目标表架构和数据收集规则，使其与源数据架构更改保持一致。
  • 在数据收集规则中定义转换，以将新数据发送到目标表中的现有列。
  • 使目标表和数据收集规则保持不变。 在这种情况下，不会引入新数据。

注意

不能重复使用数据类型与为列定义的原始数据类型不同的列名。

后续步骤