📚 课程目录第2章 Log Analytics工作区创建与管理

第2章：Log Analytics 工作区创建与管理

聊到 Azure Monitor，首先得有个「家」——这个家就是 Log Analytics 工作区。说白了，所有日志数据最终都要汇聚到这里。我刚开始接触 Azure 监控时，以为工作区就是个简单的日志桶，往里面倒数据就完事了。结果第一个生产项目就踩了坑。

嗯，咱们今天就把这件事彻底讲清楚。

2.1 什么是 Log Analytics 工作区

Log Analytics 工作区是一个逻辑容器。它用来存储 Azure 资源、虚拟机、容器甚至本地服务器产生的日志和指标数据。每个工作区有自己独立的数据隔离边界、访问控制策略和定价模型。

我个人习惯用一个比喻：你可以把工作区想象成一个「专用的数据仓库」。仓库里有不同的货架，也就是表（Table）。每种日志类型对应一张表，比如 AzureActivity 存活动日志，Perf 存性能指标。查询时用 KQL 语言，从这个仓库里拉数据。

核心角色速览

数据接收器：所有诊断设置、代理、数据收集规则（DCR）的最终目的地
查询引擎：支持 KQL 实时分析、图表展示、告警触发
访问边界：细粒度 RBAC 控制，可以按表、按行甚至按列授权
计费单位：数据摄入量、保留时长都按工作区独立计费

2.2 工作区的创建流程

创建本身不难，但有几个细节你一定要注意。我在项目中见过有人把工作区跟资源组放到不同区域，结果网络延迟高得离谱。

通过 Azure 门户创建

步骤其实不复杂：

登录 portal.azure.com，搜索「Log Analytics 工作区」
点击「创建」，填写订阅、资源组、工作区名称
最关键的是区域选择——一定要靠近你的主要 Azure 资源区域
配置定价层，默认为按量付费
点击「审阅 + 创建」，等几分钟部署完成

提示：创建完成后别急着走。我习惯立刻做三件事：设置每日上限、配置数据保留期、开启基础日志。后面我们会细讲。

通过 PowerShell 或 CLI 创建

自动化场景下，我更推荐 CLI。一个命令就能搞定：

# Azure CLI 示例
az monitor log-analytics workspace create \
  --resource-group rg-monitoring \
  --workspace-name law-prod-001 \
  --location eastus2 \
  --sku PerGB2018

PowerShell 版本类似：

# PowerShell 示例
New-AzOperationalInsightsWorkspace \
  -ResourceGroupName rg-monitoring \
  -Name law-prod-001 \
  -Location eastus2 \
  -Sku PerGB2018

你看看，差别不大。关键是参数里我指定了 PerGB2018 这个 SKU——按每 GB 数据摄入量计费，适合大多数场景。

2.3 数据保留与定价策略

数据保留是这个章节里最容易出问题的地方。我见过一个团队，日志保留设成 90 天，结果一个月账单翻了三倍。

Azure 的保留策略分两层：

保留类型	默认时长	可配置范围	适用场景
交互式保留	30 天	4 - 730 天	日常查询、告警、仪表盘
长期保留	无（关闭）	1 - 2557 天（7 年）	合规审计、历史分析

警告：交互式保留超过 30 天后会额外计费。之前有个客户把所有工作区开到 365 天，「其实」大部分日志根本不会被查。建议根据业务合规需求分层配置——高频查询的日志保留 90 天，归档日志走长期保留，这样能省 30-50% 的成本。

定价模型有两种主流选择：

按量付费 (Pay-as-you-go)：每 GB 数据摄入约 ¥2-5（取决于区域），适合中小规模
容量预留 (Commitment Tier)：承诺每日摄入量（比如 100 GB/天），折扣深度可达 30-60%，适合大规模生产环境

嗯，这里要注意：容量预留是按工作区分开计算的。如果你有 10 个工作区，想要享受折扣，得在每个工作区单独开启预留层级。

2.4 工作区的访问控制

安全不能马虎。Log Analytics 的权限模型比想象中灵活，但配置起来也有讲究。

工作区级 RBAC

直接在 Azure RBAC 层面赋予角色。常用的内置角色有：

Log Analytics 读者：能查询所有表的日志，但不能写入或修改配置
Log Analytics 贡献者：可以读写配置、设置告警、创建查询包
所有者：完全控制，包括删除工作区

表级 RBAC（精细权限）

这才是真正的利器。我曾经遇到一个场景：安全团队需要看到所有安全日志，但开发团队只能看自己服务的性能日志。用表级 RBAC 就能实现：

# 给安全团队赋权，只允许查询 SecurityEvent 表
$tableParams = @{
  ResourceGroupName = "rg-monitoring"
  WorkspaceName     = "law-prod-001"
  TableName         = "SecurityEvent"
  RoleDefinitionName = "Log Analytics 读者"
}

Set-AzOperationalInsightsTable -ResourceGroupName $tableParams.ResourceGroupName `
  -WorkspaceName $tableParams.WorkspaceName `
  -TableName $tableParams.TableName `
  -RetentionInDays 365

你看，核心是通过 Set-AzOperationalInsightsTable 命令给不同的表单独绑定权限。这样团队 A 只能访问 Table A，团队 B 只能访问 Table B，互不干扰。

最佳实践：

使用 Azure AD 条件访问策略做二次验证
为每个应用创建独立的查询包（Query Pack），不共享
定期审计工作区的权限变化，尤其是全局管理员

2.5 多工作区架构设计

单个工作区最多能接收约 500 TB/天的数据。大部分企业不会打到这个天花板，但还是得考虑架构规划。

我通常用两种模型：

集中式模型：所有资源写入同一个工作区。优点是查询简单、跨资源关联分析方便；缺点是权限混杂、数据爆炸后查询性能下降
分散式模型：每个环境（开发/测试/生产）或每个业务线独立建工作区。优点是隔离性好、计费清晰；缺点是跨工作区查询时需要联合查询，稍微麻烦一点

你想想看，哪种更适合你的场景？如果是几十台虚拟机的小规模监控，集中式完全够用。大型企业的话，我建议按业务线拆开——至少把生产环境和非生产环境完全隔离。

2.6 工作区健康检查与迁移

工作区用久了，难免要调整。我遇到过最头疼的问题是：早期创建的工作区区域选错了，后来业务搬到另一个区域，日志延迟高达 10 分钟。

迁移工作区本身没有一键功能。我的做法是：

在新区域创建一个新工作区
把所有虚拟机和 Azure 资源的诊断设置指向新工作区
在数据保留策略里，把旧工作区的数据再保留一段时间（做历史审计用）
等旧工作区没有新数据写入后，逐步降级并最终删除

提示：迁移时可以用 Azure Monitor 的数据导出功能（Export to Storage）把历史数据备份到存储账户。这样旧工作区删除后，你依然能通过 Azure 存储访问历史日志。

2.7 本章知识体系

下面这张图把 Log Analytics 工作区的核心脉络串起来了。你把它存下来，写配置时当个参考图挺好用。

你看看这张图，四个主分支基本覆盖了工作区的全生命周期管理。从创建、定价、权限控制到健康检查，每一步都有陷阱。

好，Log Analytics 工作区这部分我们先到这里。记住一句话：工作区是监控的基础设施，一开始设计好，后面能省很多事。