在 Azure Monitor 中创建和管理数据收集规则的最佳做法
数据收集规则 (DCR) 确定如何收集和处理发送到 Azure 的遥测数据。 某些数据收集规则将由 Azure Monitor 创建和管理，而你可以创建其他规则来自定义数据收集以满足你的要求。 本文讨论创建自己的 DCR 时应应用的一些最佳做法。
创建 DCR 时，需要考虑以下方面：
- 将收集的数据类型，也称为数据源类型（性能、事件）
- DCR 将与之关联的目标虚拟机
- 收集的数据的目标
考虑到所有这些因素对于良好的 DCR 组织至关重要。 上述所有要点都会对 DCR 管理工作以及配置传输和处理的资源消耗产生影响。
鉴于本机粒度允许给定的 DCR 与多个目标虚拟机相关联（反之亦然），因此每个虚拟机使用更少的数据源，保持 DCR 尽可能简单非常重要。 保持每个数据源中收集的项列表精益且面向可观测性范围也很重要。
若要阐明可观测性范围的含义，请将其视为收集数据的首选逻辑边界。 例如，可能的范围可以是运行特定应用程序所需的软件（例如，“SQL Servers”）的一组虚拟机，或者 IT 管理员使用的基本操作系统计数器或事件集。 还可以创建专用于不同环境（“开发”、“测试”、“生产”）的类似范围，进一步提升专业化。
事实上，创建包含所有数据源、集合项和目标的单个 DCR 来实现可观测性并不理想，也不建议这样做。 下表提供了一些建议，有助于更好地计划 DCR 的创建和维护：
| 类别 | 最佳做法 | 说明 | 影响区域 |
|---|---|---|---|
| 数据收集 | 定义可观测性范围 | 定义可观测性范围是简化和实现成功的 DCR 管理和组织可观测性范围的关键。 它将有助于阐明收集需求的含义，以及应从哪个目标虚拟机执行收集。 如前所述，可观测性范围可以是一组运行特定应用程序通用软件的虚拟机、一组 IT 部门的通用信息，等等。例如，收集基本的操作系统性能计数器（例如 CPU 使用率、可用内存和可用磁盘空间）可视为中央 IT 管理的范围。 | 没有明确定义的范围不会带来清晰的理解，也无法进行适当的管理。 |
| 创建特定于可观测性范围的 DCR | 要想维护轻松，关键在于基于可观测性范围创建单独的 DCR。 这样，你便可轻松地将 DCR 关联到相关的目标虚拟机。 | 为什么要创建单个 DCR 来收集操作系统性能计数器以及 Web 服务器计数器和数据库计数器？ 此方法不仅会强制每个关联的虚拟机传输、处理和执行超出范围的配置，而且还在需要更新 DCR 配置时需要花费更多精力。 请考虑管理包含不必要的条目的模板；这种情况不太理想，并留有出错的余地。 | |
| 在定义的可观测性范围内创建特定于数据源类型的 DCR | 为性能和事件创建单独的 DCR 将有助于根据目标计算机管理配置和具有粒度的关联。 例如，创建 DCR 来收集事件和性能计数器可能会导致方法不理想。 在某些情况下，给定的一台计算机（或一组计算机）没有在 DCR 中配置事件日志或性能计数器。 在这种情况下，将根据安装的软件强制虚拟机处理和执行不必要的配置。 | 如果使用相同的 DCR，则将根据安装的软件强制每个关联的虚拟机传输、处理和执行可能不适用的配置。 过多的计算资源消耗和处理配置错误可能会导致 Azure Monitor 代理 (AMA) 变得无响应。 此外，收集不必要的数据会增加数据引入成本。 | |
| 数据目标 | 基于目标创建不同的 DCR | DCR 能够同时将数据发送到多个不同的目标，例如 Azure Monitor 指标和 Azure Monitor 日志。 使用特定于目标的 DCR 有助于管理数据主权或法律要求。 由于表现为合规可能只需将数据发送到在允许的区域中创建的允许存储库，因此使用不同的 DCR 可以实现更精细的目标 | 不基于数据目标分离 DCR 可能会导致不符合数据处理、隐私和访问要求，并可能导致不必要的数据收集，而产生意外成本。 |
上述原则为创建自己的 DCR 管理方法提供了基础，该方法用于平衡可维护性、易用性、粒度和服务限制。 DCR 还需要共享治理，以最大程度地减少孤岛创建工作和不必要的工作重复。