4. Log Analytics工作区设计
Log Analytics 工作区是 Azure 可观测性体系的数据中枢。它既是 Azure Monitor 日志的存储与查询引擎，也是跨资源、跨订阅、跨区域日志集中管理的边界。工作区设计得好，后续的告警、仪表板、工作簿、Sentinel 接入都会顺畅；设计得差，往往在半年后表现为查询变慢、成本失控、权限混乱、数据割裂。本节围绕四个核心维度展开：数据保留、访问控制、成本优化、跨资源查询与集中管理。
一、工作区是数据边界，不是简单的容器
一个 Log Analytics 工作区在物理上对应一个独立的日志存储与索引单元，拥有自己的保留策略、定价层、访问控制模型和查询端点。所有写入其中的日志表（如 Heartbeat、Perf、ContainerLogV2、AzureActivity、AppTraces）共享同一套保留与计费规则，但可以按表设置差异化保留。理解这一点是设计的前提：工作区决定了“数据放在哪里、留多久、谁能看、花多少钱”。
常见的设计误区是“每个资源建一个工作区”。这会导致查询需要跨多个工作区拼接，告警规则数量膨胀，权限难以统一。更合理的做法是按管理边界、合规要求、成本归属和查询范围来划分工作区，通常 1～5 个即可覆盖大多数企业场景。
二、数据保留：交互保留与长期保留分层
Log Analytics 的保留分为两层：交互保留（Interactive Retention）默认 30 天，可配置 30～730 天，此期间数据可被任意查询，按分析日志计费；长期保留（Long-term Retention）可延长至最多 12 年，数据进入低成本存储，查询需使用 search 或 restore 作业，按搜索计费。设计时应按表的查询频率分层：高频排障表（如 ContainerLogV2、AppExceptions）保留 30～90 天；合规审计表（如 AzureActivity、SecurityEvent）交互保留 90 天、长期保留 1～7 年；低价值指标表（如 Perf 的部分计数器）可缩短交互保留以控成本。
保留策略可按表设置，示例配置如下：
# 按表设置保留（示例参数，非实测结果）
AzureActivity : interactive=90d, total=2555d (7年)
SecurityEvent : interactive=90d, total=2555d
ContainerLogV2 : interactive=30d, total=90d
AppTraces : interactive=30d, total=90d
Perf : interactive=30d, total=30d
Heartbeat : interactive=30d, total=30d判断保留是否合理，可以观察两个信号：一是过去 90 天内被查询的表与时间范围分布，二是长期保留数据的实际检索频率。若某表长期保留但一年未被 search 过，应考虑降级或归档到 Storage Account。
三、访问控制：工作区级与表级 RBAC
Log Analytics 的访问控制有两层：工作区级 RBAC（如 Log Analytics Reader、Log Analytics Contributor）和表级 RBAC（通过 Azure 自定义角色限定到具体表，如仅允许读取 SecurityEvent）。表级 RBAC 是实现“同一工作区、不同团队看不同数据”的关键手段，避免为隔离权限而拆分工作区。
典型设计：平台团队拥有 Log Analytics Contributor，可管理保留与数据源；安全团队通过自定义角色仅能读取 SecurityEvent、SigninLogs；应用团队仅能读取自己命名空间对应的 ContainerLogV2 与 AppTraces。资源上下文查询（Resource-context）则允许拥有某资源读取权限的用户直接查看该资源日志，无需工作区权限，适合开发人员自助排障。
四、成本优化：从数据摄入到查询的全链路
Log Analytics 成本主要由三部分构成：数据摄入（按 GB）、交互保留（按 GB·天）、查询（分析查询通常包含在摄入中，search/restore 单独计费）。优化应从源头开始：
- 摄入前过滤：使用数据收集规则（DCR）过滤无用日志，例如丢弃 Debug 级别 AppTraces、排除高频低价值 Perf 计数器。
- 表计划选择：对仅用于审计、极少查询的表使用基本日志（Basic Logs），摄入成本显著降低，但仅支持有限查询；对高频分析表使用分析日志（Analytics Logs）。
- 保留分层：交互保留只保留排障窗口，长期保留交给低成本层。
- 查询治理：限制仪表板刷新频率，避免大范围 search 作业，使用 summarize 与时间范围裁剪。
一个可执行的成本检查清单如下：
| 检查项 | 判断依据 | 动作 |
|---|---|---|
| DCR 是否过滤 | 是否存在 Debug/Verbose 日志 | 添加 where 过滤 |
| 表计划是否匹配 | 该表近 30 天查询次数 | 低频表转 Basic Logs |
| 交互保留是否过长 | 查询时间范围分布 | 缩短至 30～90 天 |
| 是否存在重复采集 | 同一数据多表写入 | 合并数据源 |
| 仪表板刷新频率 | 是否低于 5 分钟 | 调整为 15 分钟以上 |
五、跨资源查询与集中管理
跨资源查询有两种主要方式：跨工作区查询（workspace() 函数）和跨资源查询（union 多个资源或使用 Azure Resource Graph 补充元数据）。当工作区按区域或业务线拆分时，可用 workspace("id").Table 在单个查询中合并结果。跨订阅场景下，需确保查询身份对目标工作区有读取权限。
集中管理的核心是“数据源统一接入、查询统一入口、权限统一模型”。建议使用数据收集规则（DCR）作为统一接入层，将 VM、容器、应用、平台诊断日志汇聚到指定工作区；使用 Azure Monitor 的查询包（Query Pack）沉淀标准查询；使用工作簿（Workbook）作为统一可视化入口。下图展示了工作区设计中数据流、保留分层与访问控制的关系。
图中左侧是数据源，经 DCR 过滤与转换后写入工作区；工作区内按表计划与保留分层组织；右侧是访问控制模型；下方是成本优化链路与跨资源查询能力。四者共同构成工作区设计的完整视图。
六、设计决策的落地顺序
实际落地时，建议按以下顺序推进：先确定工作区数量与归属（按管理边界与合规要求），再定义每张表的保留策略与表计划，然后配置 DCR 过滤与转换，接着建立表级 RBAC 与资源上下文权限，最后用 Usage 表与查询日志持续验证成本与访问是否符合预期。每一步都应留下可复查的配置记录，避免后续变更时失去依据。
总结来看，Log Analytics 工作区设计的本质是在“集中管理”与“边界隔离”之间找到平衡：用尽量少的工作区承载尽量多的数据，用表级 RBAC 和保留分层实现精细控制，用 DCR 和查询治理控制成本，用跨工作区查询保持全局视野。掌握这四点，后续的告警、仪表板与 Sentinel 接入都会建立在一个稳定、可扩展的基础之上。