如何以AWS风格查询Azure容器应用JSON格式日志？

提问背景 #

我正在尝试查询Node.js HTTP服务器输出的Azure容器应用JSON格式日志，当前使用的查询语句如下：

ContainerAppConsoleLogs_CL
| where Log_msg_s == "request completed"
and Log_req_url_s has "/my/path"
and Log_req_method_s has "GET"

遇到以下问题：

1. 不喜欢JSON字段被转换为带前缀的列，想知道如果日志包含多样对象，Azure最多可创建多少列？
2. 如何用类似AWS CloudWatch的风格查询？即保留@containerName这类平台列，直接以msg = 'request completed' and req.url = 'xxx'的方式查询日志内容。
3. 如何像AWS那样以标准格式化方式查看JSON日志？当前嵌套路径生成冗长列，还有大量无关Azure列（已知可投影字段，但无法解决根本问题）。
   附加问题：我的ContainerAppConsoleLogs表没有日志，这是为什么？它和带_CL后缀的表有什么区别？

解答 #

1. JSON字段转前缀列的最大数量限制 #

Azure Log Analytics的自定义日志表（带_CL后缀）默认最多支持500列。如果日志中的JSON字段数量超过这个限制，超出的字段会被丢弃，不会生成对应的列。如果日志结构多变，建议不要依赖自动拆分列，而是保留原始JSON字符串进行查询。

2. 类似CloudWatch风格的查询方式 #

可以先把原始的JSON日志内容解析为动态对象，然后直接引用JSON内的字段，同时保留平台自带的列。具体操作：

• 定位存储原始JSON的列（通常是RawData或Log_s，取决于日志配置）
• 使用parse_json()函数将其转换为动态类型，通过点符号直接访问嵌套字段
• 平台自带的@containerName等元数据列可直接在查询中使用

示例查询：

ContainerAppConsoleLogs_CL
| extend logData = parse_json(RawData)  // 替换为实际存储原始JSON的列名
| where logData.msg == "request completed"
  and logData.req.url has "/my/path"
  and logData.req.method == "GET"
| project @containerName, logData  // 保留需要的平台列和解析后的JSON对象

如果日志是通过容器stdout输出的，原始JSON可能在Log_s列，替换为parse_json(Log_s)即可。

3. 格式化查看JSON日志 #

要实现类似CloudWatch的标准JSON视图，有两种实用方式：

• 保留原始JSON折叠显示：查询时直接投影原始JSON列（如RawData或Log_s），Log Analytics会自动将JSON内容渲染为可折叠的结构化视图，点击即可展开查看嵌套字段，避免生成大量冗余列。
• 解析为动态对象查看：用parse_json()将JSON转为动态类型，投影该动态列，结果会以树状结构展示JSON内容，和CloudWatch的格式化视图一致。

示例查询（保留原始JSON并展示）：

ContainerAppConsoleLogs_CL
| where parse_json(RawData).msg == "request completed"
| project @containerName, RawData  // 只保留关键平台列和原始JSON日志

在结果中点击RawData列的内容，就能展开查看结构化的JSON，无需面对冗长的拆分列。

附加问题：ContainerAppConsoleLogs与ContainerAppConsoleLogs_CL的差异及无日志原因 #

两者的核心区别

• ContainerAppConsoleLogs：Azure容器应用的内置托管日志表，由Azure自动管理，存储容器的标准stdout/stderr日志，字段结构固定，包含Log（原始日志内容）、ContainerName、PodName等预定义元数据列。
• ContainerAppConsoleLogs_CL：自定义日志表，通常是配置Diagnostic Settings时选择了自定义解析，或日志被自动拆分为前缀列生成的，会将JSON字段自动拆分为Log_xxx_s这类命名的列。

ContainerAppConsoleLogs无日志的常见原因

• 诊断设置未配置：需确保容器应用的Diagnostic Settings中，已将ConsoleLogs类别发送到目标Log Analytics工作区，且目标表选择ContainerAppConsoleLogs而非自定义表。
• 日志传输延迟：Azure日志从容器到Log Analytics存在几分钟的传输延迟，等待一段时间后再检查。
• 日志过滤规则：如果配置了日志过滤规则，可能过滤掉了目标日志内容。
• 权限不足：当前查询账号没有ContainerAppConsoleLogs表的读取权限，检查IAM权限配置。

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