设计 Azure Monitor 日志 (Log Analytics) 工作区

已完成

Azure Monitor 将日志数据存储在 Azure Monitor 日志 (Log Analytics) 工作区中。 工作区是一种 Azure 资源,用作数据存储的管理边界或地理位置。 工作区也是收集和聚合数据的容器。

尽管可以在 Azure 订阅中部署一个或多个工作区,但你应确保初始部署遵循 Microsoft 指南。 工作区应提供符合组织需求的经济高效、可管理且可缩放的部署。

有关 Azure Monitor 日志工作区的注意事项

查看 Azure Monitor 日志工作区的以下特征,并考虑如何使用它们为 Tailwind Traders 的监视解决方案做出贡献。

  • 在工作区中,可以按照 Microsoft 建议的设计策略授予不同用户访问权限来隔离数据。

  • Azure Monitor 日志工作区中的数据划分为多个表。 每个表存储不同类型的数据,并且根据生成数据的资源具有自己唯一的属性集。 大多数数据源写入其在 Azure Monitor 日志工作区中的专属表。

  • 使用工作区可以根据管理边界或地理位置配置定价层保留数据上限等设置。

  • 使用 Azure 基于角色的访问控制 (Azure RBAC),可以仅向用户和组授予其在工作区中处理监视数据所需的访问级别。 可以使用单个工作区来存储对所有资源启用的收集数据,从而使用户访问控制符合 IT 组织运营模型。

  • 工作区托管在物理群集上。 默认情况下,系统会创建和管理这些群集。 如果系统每天引入超过 500 GB 的数据,则你可以为工作区创建自己的专用群集,以增强控制力和提高引入速率。

使用 Azure Monitor 日志工作区时的注意事项

现在,可以查看在 Tailwind Traders 体系结构中使用 Azure Monitor 日志工作区进行设计的注意事项。

  • 考虑访问控制策略。 计划在 Tailwind Traders 组织中所使用的工作区数量时,请考虑以下潜在要求:

    • 贵组织是否是一家全球性公司? 出于数据主权或合规性原因,是否需要存储在特定区域中的日志数据?
    • 体系结构是否使用 Azure? 是否希望通过让工作区与它所管理的 Azure 资源位于同一区域,避免产生出站数据传输费用?
    • 系统是否支持多个部门或业务组? 每个组应访问自己的数据,不能访问其他组的数据。 此外,在整合部门或业务组视图方面没有业务要求。
  • 考虑部署模型选项。 大多数 IT 组织对其体系结构使用集中式、分散式或混合模型。 考虑这些常见的工作区部署模型,以及如何用于 Tailwind Traders 组织:

    部署 说明
    集中式 所有日志都存储在一个集中工作区,由一个团队负责管理。 Azure Monitor 为每个团队提供差异化的访问权限。 在此方案中,可以轻松管理和搜索各个资源,以及交叉关联日志。 工作区可能会显著增长,具体取决于从订阅中多个资源收集的数据量。 维护对不同用户的访问控制需要额外管理开销。 此模型称为“中心和分支”
    分散式 每个团队有自己的工作区,工作区在由其拥有和管理的资源组中创建。 日志数据按资源隔离。 在此方案中,工作区可以保持安全性,访问控制与资源访问权限保持一致。 但此模块的一个缺点是难以交叉关联日志。 需要广泛了解许多资源的用户无法以有意义的方式分析数据。
    Hybrid 混合方法可能会使安全审核合规性要求变得复杂。 许多组织并行实施这两种部署模型。 混合设计通常会导致复杂、大开销且难以维护的配置,并使日志覆盖范围出现差异。
  • 考虑访问模式。 规划用户如何访问 Azure Monitor 日志工作区并定义用户可访问的数据范围。 Tailwind Traders 用户可通过两种方式访问其数据:

    访问模式 说明
    工作区上下文 用户可以查看其有权访问的工作区中的所有日志。 只能查询该工作区中所有表内的所有数据。 通过在 Azure 门户的 Azure Monitor 菜单中选择“日志”,可以以工作区为范围来访问日志
    资源上下文 用户可以访问特定资源、资源组或订阅的工作区。 通过从 Azure 门户的资源菜单中选择“日志”,用户可以只查看其有权访问的所有表中的资源的日志。 查询范围仅限于与该资源关联的数据。 此模式还支持精细 Azure RBAC。
  • 考虑 Azure RBAC 和工作区。 根据用户工作区关联控制哪些用户可以访问哪些资源。 可以向负责 Azure 虚拟机上托管的 Tailwind Traders 基础结构服务的团队授予访问权限。 可以仅授予团队访问虚拟机生成的日志的权限。 此方法将遵循新的资源-上下文日志模型。 此模型的基础是 Azure 资源发出的每个日志记录。 日志将根据资源转发到与范围和 Azure RBAC 相符的中心工作区。

  • 考虑规模和引入量速率限制。 Azure Monitor 是一种大规模数据服务,每月为成千上万的客户发送数 PB 的数据,该数据量仍在不断增长。 工作区不受其存储空间的限制,可以增长到存储数 PB 的数据。 由于规模的原因,无需拆分工作区。

建议

考虑如何在监视和日志记录解决方案中实现 Azure Monitor 日志工作区和访问控制时,请查看以下建议。 此方案显示了 IT 组织订阅中单一工作区的建议设计。

显示如何设计 Azure Monitor 日志部署的示意图。

工作区不要求数据主权或合规性。 工作区无需映射到部署资源的区域。 组织的安全和 IT 管理团队可以利用与 Azure 访问管理的改进集成以及更安全的访问控制。

所有资源、监视解决方案和见解(例如 Application Insights 和虚拟机见解)都将配置为向 IT 组织的集中式共享工作区转发收集的日志数据。 不同团队维护的支持基础结构和应用的日志数据也会发送到集中式共享工作区。

为每个团队的用户授予其有权访问的资源的日志访问权限。

部署工作区体系结构后,可以使用 Azure Policy 对 Azure 资源强制实施此模型。 你可以定义策略并确保与你的 Azure 资源相符合,以便它们将其所有资源日志发送到特定的工作区。 借助 Azure 虚拟机或虚拟机规模集,可使用评估工作区合规性并报告结果的现有策略,或者自定义策略,以在不合规时进行修正。