Log Analytics Pricing tier 与订阅计费模式不匹配

2026-10-24技术老齐

结论

将 Log Analytics 工作区的计费层从旧版按 GB 计费层改为当前订阅支持的 PerGB2018，同时确保部署模板中声明的 SKU 与工作区实际使用的 SKU 一致。Upgrade Readiness solution 与工作区的计费模型无关，安装它无法解决这个问题。

如果工作区已经使用 PerGB2018，问题通常出在部署模板上。模板可能仍然使用 Standalone、PerNode 或其他旧 SKU。此时需要修改模板，或者避免在部署解决方案时重复声明工作区。

原因

Log Analytics 调整过计费模型，部分旧工作区仍在使用以下 SKU：

Standalone：旧版按 GB 计费
PerNode：旧版按节点计费
Free、Standard、Premium：历史计费层

新计费模型通常使用：

PerGB2018：按数据引入量计费
CapacityReservation：容量预留

Azure 门户显示的“Per GB”不一定能清楚区分旧版 Standalone 与新版 PerGB2018。如果订阅不允许使用旧计费模型，但 ARM 模板或现有工作区仍声明旧 SKU，资源提供程序会返回：

Pricing tier doesn't match the subscription's billing model.

Upgrade Readiness、Update Management 等 solution 是工作区内的功能资源，无法修改工作区 SKU。因此，先安装这些 solution 并不能解决计费层冲突。

解决步骤

1. 查看工作区的实际 SKU

使用 Azure CLI 查询，不要只看门户中的显示名称：

az monitor log-analytics workspace show \
  --resource-group <resource-group> \
  --workspace-name <workspace-name> \
  --query "{name:name, sku:sku.name, location:location}" \
  --output table

如果返回 Standalone、PerNode 或其他旧计费层，需要确认订阅是否仍允许使用该计费模型。

2. 将工作区切换为 `PerGB2018`

az monitor log-analytics workspace update \
  --resource-group <resource-group> \
  --workspace-name <workspace-name> \
  --sku PerGB2018

也可以在 Azure 门户中打开 Log Analytics workspace，在“使用情况和估算成本”或“定价层”页面选择当前的按量计费层。门户入口名称可能会随界面更新而变化。

修改完成后，再次查询 SKU，确认结果为：

PerGB2018

3. 修正部署模板中的 SKU

如果 ARM 模板会创建或更新工作区，应将 SKU 设置为与订阅计费模型匹配的值：

{
  "type": "Microsoft.OperationalInsights/workspaces",
  "apiVersion": "2022-10-01",
  "name": "[parameters('workspaceName')]",
  "location": "[parameters('location')]",
  "properties": {
    "retentionInDays": 30
  },
  "sku": {
    "name": "PerGB2018"
  }
}

对应的 Bicep 示例：

resource workspace 'Microsoft.OperationalInsights/workspaces@2022-10-01' = {
  name: workspaceName
  location: location
  properties: {
    retentionInDays: 30
  }
  sku: {
    name: 'PerGB2018'
  }
}

如果工作区已经存在，模板只是用来部署 Automation solution，最好通过参数引用现有工作区，不要再用旧 SKU 声明或更新工作区。例如：

resource workspace 'Microsoft.OperationalInsights/workspaces@2022-10-01' existing = {
  name: workspaceName
}

然后让 solution 依赖或引用这个现有资源。

4. 检查 Automation Account 的关联配置

计费层错误解决后，如果部署仍然失败，再检查以下项目：

Automation Account 与 Log Analytics workspace 是否处于受支持的区域组合。
执行部署的身份是否拥有工作区和 Automation Account 的写入权限。
模板中的 workspace resource ID 和 Automation Account resource ID 是否正确。
solution 资源是否错误依赖了另一个同名工作区。
模板是否通过嵌套部署重新创建工作区，并传入旧 SKU。

可以先查看部署失败详情，确认当前失败的资源：

az deployment group operation list \
  --resource-group <resource-group> \
  --name <deployment-name> \
  --query "[?properties.provisioningState=='Failed'].properties.statusMessage" \
  --output json

已经使用 `PerGB2018` 时怎么办

如果查询结果已经是 PerGB2018，无需反复切换计费层。此时应重点检查部署模板：

搜索 Standalone、PerNode、PerGB 等 SKU 值。
检查参数文件是否覆盖了模板的默认值。
查看嵌套模板或 Marketplace solution 是否重复声明了工作区。
对现有工作区使用 existing 引用，或将模板中的 SKU 改为 PerGB2018。
通常不需要删除失败的部署记录，修正模板后重新部署即可。

注意事项

切换计费层可能会改变日志引入、数据保留及相关功能的收费方式。在生产环境中操作前，应先检查订阅报价、工作区数据量和当前保留期。

旧计费层能否切换以及切换后能否恢复，取决于订阅类型和 Azure 当时采用的计费策略，不能假定所有订阅都支持相同的操作路径。

如果 Azure 拒绝更新 SKU，并明确提示订阅不具备该计费层资格，应通过 Azure 支持确认订阅使用的计费模型，不要尝试安装其他 solution 来绕过校验。