通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

容器见解日志架构

  • 项目

容器见解将其收集的日志数据存储在名为 ContainerLogV2 的表中。 本文介绍此表的架构及其与旧 ContainerLog 表的比较和迁移。

重要

对于 CLI 2.54.0 及更高版本，ContainerLogV2 将通过 ConfigMap 成为默认架构。 对于使用 ARM、Bicep、Terraform、Policy 和门户加入功能通过托管标识身份验证加入容器见解的客户，ContainerLogV2 将是默认引入格式。 ContainerLogV2 可以使用数据收集设置通过 CLI 2.51.0 或更高版本实现显式启用。

将于 2026 年 9 月 30 日停止支持 ContainerLog 表。

比较表

下表突出显示了使用 ContainerLogV2 和 ContainerLog 架构之间的主要区别。

功能差异 ContainerLog ContainerLogV2
架构 ContainerLog 的详细信息。 ContainerLogV2 的详细信息。
下面是其他列：
- ContainerName
- PodName
- PodNamespace
- LogLevel1
- KubernetesMetadata2
登记 只能通过 ConfigMap 进行配置。 可通过 ConfigMap 和 DCR 进行配置。 3
定价 仅与全价分析日志兼容。 除分析日志外，还支持低成本基本日志层。
查询 标准查询需要对库存表执行多次联接操作。 包括其他 Pod 和容器元数据，以降低查询复杂度并减少联接操作。
多行 不支持，多个条目被拆分为多行。 支持多行日志记录，以便为多行输出提供合并的单一条目。

1如果 LogMessage 是有效的 JSON，并且具有一个名为 level 的键，则将使用其值。 否则，我们会使用基于正则表达式的关键字匹配方法从 LogMessage 本身推断 LogLevel。 请注意，由于该值是推断出来的，你可能会看到一些错误分类。

2KubernetesMetadata 是可选的列，可以使用 Kubernetes 元数据功能启用此字段的集合。 此字段的值是 JSON，它包含 podLabels、podAnnotations、podUid、Image、ImageTag 和 Image repo 等字段。

3使用基于服务主体身份验证的群集不支持 DCR 配置。 要使用此体验，请将基于服务主体的群集迁移到托管标识。

注意

如果传入的 LogMessage 不是有效的 JSON，则不支持导出到事件中心和存储帐户。 为了获得最佳性能，建议以 JSON 格式发出容器日志。

评估对现有警报的影响

在启用 ContainerLogsV2 架构之前，应评估是否有依赖于 ContainerLog 表的警报规则。 需要更新所有此类警报才能使用新表。

若要扫描引用 ContainerLog 表的警报，请运行以下 Azure Resource Graph 查询：

resources
| where type in~ ('microsoft.insights/scheduledqueryrules') and ['kind'] !in~ ('LogToMetric')
| extend severity = strcat("Sev", properties["severity"])
| extend enabled = tobool(properties["enabled"])
| where enabled in~ ('true')
| where tolower(properties["targetResourceTypes"]) matches regex 'microsoft.operationalinsights/workspaces($|/.*)?' or tolower(properties["targetResourceType"]) matches regex 'microsoft.operationalinsights/workspaces($|/.*)?' or tolower(properties["scopes"]) matches regex 'providers/microsoft.operationalinsights/workspaces($|/.*)?'
| where properties contains "ContainerLog"
| project id,name,type,properties,enabled,severity,subscriptionId
| order by tolower(name) asc

启用 ContainerLogV2 架构

可以使用群集的数据收集规则 (DCR) 或 ConfigMap 为群集启用 ContainerLogV2 架构。 如果同时启用这两个设置，ConfigMap 优先级更高。 仅当 DCR 和 ConfigMap 都明确设置为关闭时，Stdout 和 stderr 日志才会引入到 ContainerLog 表。

Kubernetes 元数据和日志筛选

Kubernetes 元数据和日志筛选通过更多 Kubernetes 元数据（如 PodLabels、PodAnnotations、PodUid、Image、ImageID、ImageRepo 和 ImageTag）增强了 ContainerLogsV2 架构。 此外，日志筛选功能为工作负载和平台（即系统命名空间）容器提供了筛选功能。 借助这些功能，用户可以获得更丰富的上下文，并改进了工作负载的可见性。

关键功能

  • 具有 Kubernetes 元数据字段的增强 ContainerLogV2 架构：Kubernetes 日志元数据引入了其他可选元数据字段，这些字段增强了使用简单 Log Analytics 查询时的故障排除体验，并且不需要与其他表联接。 这些字段包括“PodLabels”、“PodAnnotations”、“PodUid”、“ImageID”、“ImageRepo”和“ImageTag”等基本信息。 使此上下文随时可用后，用户可以快速排查和识别问题。

  • 自定义包含列表配置：用户可以通过编辑 configmap 来定制他们要查看的新元数据字段。 请注意，启用 metadata_collection 时会默认收集所有元数据字段，如果要选择特定字段，请取消注释 include_fields 并指定需要收集的字段。

显示元数据字段的屏幕截图。

  • 具有日志级别的增强 ContainerLogV2 架构：用户现在可以基于颜色编码严重性级别（如 CRITICAL、ERROR、WARNING、INFO、DEBUG、TRACE 或 UNKNOWN）评估应用程序运行状况。 它是事件响应和主动监视的关键工具。 通过直观地区分严重性级别，用户可以快速查明受影响的资源。 颜色编码的系统简化了调查过程，用户可以通过选择面板来进一步向下钻取，实现后续调试的探索体验。 但是，请务必注意，此功能仅在使用 Grafana 时适用。 如果使用 Log Analytics 工作区，则 LogLevel 只是 ContainerLogV2 表中的另一列。

  • 基于注释的工作负载日志筛选：利用 Pod 注释的高效日志筛选技术。 用户可以专注于相关信息，而无需筛选噪音。 基于注释的筛选使用户能够通过注释 Pod 来排除某些 Pod 和容器的日志收集，这有助于显著降低日志分析成本。

  • 基于 ConfigMap 的平台日志筛选（系统 Kubernetes 命名空间）：平台日志由系统（或类似受限）命名空间中的容器发出。 默认情况下会排除系统命名空间中的所有容器日志，以最大程度地降低 Log Analytics 成本。 但是，在特定故障排除方案中，系统容器的容器日志起着重要作用。 例如，考虑一下 kube-system 命名空间中的 coredns 容器。 若要仅从 kube-system 中的 coredns 容器收集日志（stdout 和 stderr），可以在 configmap 中启用以下设置。

显示筛选字段的屏幕截图。

  • 用于可视化效果的 Grafana 仪表板：Grafana 仪表板不仅会显示从 CRITICAL 到 UNKNOWN 的日志级别的彩色编码可视化效果，还会深入分析日志量、日志速率、日志记录、日志。 用户可以获取时间敏感的分析、对日志级别趋势的动态见解以及关键的实时监视。 我们还提供了按计算机、Pod 和容器的详细细目，它支持深入分析和精确的故障排除。最后，在新日志表体验中，用户可以通过展开视图查看深度的详细信息，查看每列中的数据，并放大要查看的信息。

下面是展示 Grafana 仪表板的视频：

如何启用 Kubernetes 元数据和日志筛选

先决条件

  1. 迁移到托管标识身份验证。 了解详细信息。

  2. 确保已启用 ContainerLogV2。 托管标识身份验证群集默认启用此架构。 如果没有，请启用 ContainerLogV2 架构。

限制

ContainerLogV2 Grafana 仪表板不支持 ContainerLogV2 表上的基本日志 SKU。

启用 Kubernetes 元数据

  1. 下载 configmap 并将设置从 false 修改为 true，如以下屏幕截图所示。 请注意，默认情况下会收集所有支持的元数据字段。 如果要收集特定字段，请在 include_fields 中指定必填字段。

显示启用元数据字段的屏幕截图。

  1. 应用 ConfigMap。 请参阅配置 configmap，详细了解如何部署和配置 ConfigMap。

  2. 几分钟后，数据应流入具有 Kubernetes 日志元数据的 ContainerLogV2 表，如以下屏幕截图所示。

显示 containerlogv2 的屏幕截图。

加入 Grafana 仪表板体验

  1. 在“见解”选项卡下，选择监视设置并加入到版本 10.3.4+ 的 Grafana 仪表板

显示 grafana 加入的屏幕截图。

  1. 通过检查访问控制 (IAM) 确保你拥有一个 Grafana 管理员/编辑者/读者角色。 否则，请添加这些方法。

显示 grafana 角色的屏幕截图。

  1. 确保 Grafana 实例有权访问 Azure Logs Analytics (LA) 工作区。 如果它没有访问权限，则需要授予 Grafana 实例对 LA 工作区的监视读者角色访问权限。

显示 grafana 的屏幕截图。

  1. 导航到 Grafana 工作区并从 Grafana 库导入 ContainerLogV2 仪表板。

  2. 选择 DataSource、订阅、ResourceGroup、群集、命名空间和标签的信息。 然后，仪表板将按以下屏幕截图所示进行填充。

显示 grafana 仪表板的屏幕截图。

注意

最初加载 Grafana 仪表板时，可能会由于尚未选择变量而引发一些错误。 若要防止这种情况重复出现，请在选择一组变量后保存仪表板，以便它在首次打开时变为默认值。

启用基于注释的筛选

按照下面提到的步骤启用基于注释的筛选。 发布了相关筛选文档后，请在此处找到链接。

  1. 下载 configmap 并将设置从 false 修改为 true，如以下屏幕截图所示。

显示注释的屏幕截图。

  1. 应用 ConfigMap。 请参阅配置 configmap，详细了解如何部署和配置 ConfigMap。

  2. 在工作负载 Pod 规范上添加所需的注释。下表突出显示了各种可能的 Pod 注释和对它们的作用的说明。

注释 说明
fluentbit.io/exclude: "true" 排除 Pod 中所有容器上的 stdout 和 stderr 流
fluentbit.io/exclude_stdout: "true" 仅排除 Pod 中所有容器上的 stdout 流
fluentbit.io/exclude_stderr: "true" 仅排除 Pod 中所有容器上的 stderr 流
fluentbit.io/exclude_container1: "true" 仅针对 Pod 中的 container1 排除 stdout 和 stderr 流
fluentbit.io/exclude_stdout_container1: "true" 仅针对 pod 中 container1 排除 stdout

注意

这些注释是基于 fluent bit 的。 如果将你自己的基于 fluent-bit 的日志收集解决方案与 Kubernetes 插件筛选器和基于注释的排除结合使用，它将停止从 Container Insights 和你的解决方案收集日志。

下面是 Pod 规范中 fluentbit.io/exclude: "true" 注释的示例：

apiVersion: v1 
kind: Pod 
metadata: 
 name: apache-logs 
 labels: 
  app: apache-logs 
 annotations: 
  fluentbit.io/exclude: "true" 
spec: 
 containers: 
 - name: apache 
  image: edsiper/apache_logs

基于 ConfigMap 的平台日志筛选（系统 Kubernetes 命名空间）

  1. 下载 configmap 并修改与 collect_system_pod_logs 和 exclude_namespaces 相关的设置。

例如，若要在 kube-system 命名空间中收集 coredns 容器的 stdout 和 stderr 日志，请确保 kube-system 命名空间不在 exclude_namespaces 中，而且此功能仅限于以下系统命名空间：kube-system、gatekeeper-system、calico-system、azure-arc、kube-public 和 kube-node-lease 命名空间。

显示筛选字段的屏幕截图。

  1. 应用 ConfigMap。 请参阅配置 configmap，详细了解如何部署和配置 ConfigMap。

容器见解中的多行日志记录

启用多行日志记录后，以前拆分的容器日志将拼接在一起，并作为单个条目发送到 ContainerLogV2 表。 如果拼接的日志行大于 64 KB，则会由于 Log Analytics 工作区限制而被截断。 此功能还支持 .NET、Go、Python 和 Java 堆栈跟踪，这些跟踪在 ContainerLogV2 表中显示为单个条目。 使用 ConfigMap 启用多行日志记录，如使用 ConfigMap 在容器见解中配置数据收集中所述。

注意

configmap 现在具有语言规范选项，其中客户只能选择他们感兴趣的语言。 可以通过在 configmap 的 stacktrace_languages 选项中编辑语言来启用此功能。

以下屏幕截图显示了 Go 异常堆栈跟踪的多行日志记录：

已禁用多行日志记录

屏幕截图显示禁用的多行日志记录。

已启用多行日志记录

屏幕截图显示启用的多行日志记录。

Java 堆栈跟踪

显示为 Java 启用多行的屏幕截图。

Python 堆栈跟踪

显示为 Python 启用多行的屏幕截图。

后续步骤