Azure资源日志路由至多个Log Analytics工作区的架构方案咨询

完全不需要依赖额外的自建中间件，按照你的权限隔离要求，优先选运维成本最低的Azure原生能力，具体方案按照优先级排序：

最高效零中间件方案：基于诊断设置的多目的地直连 #

• 核心逻辑：Azure所有支持诊断输出的日志源，本身就支持在配置诊断规则时，同时把同一份日志直写多个目标Log Analytics工作区，全程不需要经过Event Hub、Logstash这类中转组件，完全匹配你之前设计的路由规则
• 对应你的路由规则配置方式：
  • 日志源A的诊断规则中，同时添加「LA工作区A」「LA工作区B」两个作为目的地，日志生成后会自动同步复制到两个工作区
  • 日志源B的诊断规则中，仅添加「LA工作区B」作为目的地，日志仅存储在用户组B可访问的工作区
  • 日志源C的诊断规则中，仅添加「LA工作区A」作为目的地，日志仅存储在用户组A可访问的工作区
• 隔离效果：日志从源头直接写入对应权限边界内的工作区，只需要给每个用户组分配对应工作区的读取权限即可，不存在跨工作区的日志流转链路，从架构层面杜绝越权访问的可能
• 适用覆盖范围：所有Azure平台资源、安装了Log Analytics Agent的服务器/客户端、支持诊断输出的应用服务全场景适配，零额外运维成本，是当前场景下的最优选择

已有Event Hub全局入口的轻量转发方案 #

如果你的日志链路已经固定以Event Hub作为统一入口，不需要部署自建Logstash集群，直接用无服务器能力完成转发：

• 用Azure Function做日志消费端，按照固定的路由映射规则，从Event Hub拉取日志后批量写入对应Log Analytics工作区
• 路由规则可以直接在Function代码中硬编码你需要的分发逻辑，支持按日志源标签、日志内容字段做精准匹配，完全满足分发要求
• 对比自建Logstash的优势：不需要维护服务器、不需要做容量规划、不需要配置进程自愈，Azure自动完成弹性扩缩容，单实例即可支撑TB级每日日志的转发流量，按需计费无固定资源开销

低重复存储的权限隔离替代方案 #

如果部分日志给多个组共用，不想在多个工作区重复存储产生额外存储成本，可以调整架构：

• 所有公共日志统一存入一个中心LA工作区，给每个用户组创建独立的日志视图，把组内有权限查看的日志整合到视图中，按照最小权限给用户组分配对应视图的读取权限
• 注意：这个方案的隔离强度低于独立工作区存储，因为权限边界在同一个工作区内部，仅适合对数据隔离要求没有达到物理隔离级别的场景

落地避坑提示 #

• 不要为了统一入口强行将所有日志灌入Event Hub，除非你确实需要在传输链路做全局日志脱敏、格式转换、全链路审计，直连多目的地的方案日志延迟最低、故障点最少
• 叠加Azure Sentinel的独立工作区，不需要重复配置日志采集规则，只要确认对应工作区内存在需要的日志类型，直接在Sentinel中启用对应数据连接器即可
• 权限配置严格遵循最小原则：每个用户组仅分配对应LA工作区的Log Analytics Reader权限，禁止给组内账号开放其他工作区的访问权限，从授权层面杜绝越权风险

内容的提问来源于stack exchange，提问作者user13109871