Get-AzLog中非本地化OperationName失效，是否需改用本地化值？

问题根源推测 #

• Az模块版本变更：Get-AzLog所属的Az.Resources模块在版本更新后，可能调整了OperationName的属性结构，原本的嵌套value字段路径发生变化，或默认返回本地化字符串而非资源提供方标准操作名称。
• 上下文语言设置影响：当PowerShell会话或Azure上下文的语言配置改变时，OperationName会优先返回对应语言的本地化文本，导致原有的非本地化值过滤失效。

排查验证步骤 #

1. 确认OperationName的实际结构
   输出单个事件的OperationName完整结构，明确属性字段：

   Get-AzLog -MaxEvents 1 | Select-Object OperationName | ConvertTo-Json -Depth 10
   

   通过JSON输出可以清晰看到是否存在Value（非本地化）和LocalizedValue（本地化）两个子属性，避免路径访问错误。

2. 强制设置上下文语言为英文
   手动指定Azure上下文语言为英文，强制返回非本地化操作名称：

   Set-AzContext -Subscription "<你的订阅ID>" -Language en-us
   Get-AzLog | Where-Object {$_.OperationName.Value -eq "Microsoft.Sql/servers/databases/delete"}
   

3. 核对Az模块版本
   对比之前正常运行时的模块版本，排查是否因版本更新导致属性变更：

   Get-Module -ListAvailable Az.Resources
   

   若版本差异明显，可尝试回退至原可用版本，或查阅Az.Resources官方版本变更日志确认结构调整。

实用解决方案 #

• 兼容式过滤：同时判断本地化和非本地化值，适配不同场景：

  Get-AzLog | Where-Object {
      $_.OperationName.Value -eq "Microsoft.Sql/servers/databases/delete" -or
      $_.OperationName.LocalizedValue -eq "Delete SQL database"
  }
  

• 服务器端过滤（推荐）：使用-Filter参数直接在Azure服务器端过滤，效率更高且不受本地化影响：

  Get-AzLog -Filter "operationName eq 'Microsoft.Sql/servers/databases/delete'"
  

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