配置 ContainerLogV2 架构

容器洞察将其收集的日志数据存储在 Log Analytics 工作区中的名为 ContainerLogV2 的表中。 本文介绍该表的架构及其配置选项。 本文还将该表与旧版 ContainerLog 表进行了比较，并提供有关如何从中进行迁移的详细信息。

比较表

ContainerLogV2 是 CLI 2.54.0 及更高版本的默认架构。 此架构是使用托管标识身份验证载入容器见解的客户的默认表。 通过 2.51.0 或更高版本的 CLI，使用数据收集设置显式启用 ContainerLogV2。

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

¹ 如果 LogMessage 有效 JSON 且具有命名 level的键，则使用其值。 否则，基于正则表达式的关键字匹配会从 LogMessage 中推断出 LogLevel。 这种推理可能会导致某些错误分类。 LogLevel是一个字符串字段，其值为 ，例如CRITICAL，、ERROR、WARNINGINFO、DEBUG、 TRACE或UNKNOWN。

²KubernetesMetadata 列是一个可选项，可通过 Kubernetes 元数据 启用。 此字段的值为 JSON，其中包含字段 podLabels、podAnnotations、podUid、image、imageID、imageRepo 和 imageTag。

³ DCR 配置需要托管身份验证。

启用 ContainerLogV2 架构

使用集群的日志配置文件或ConfigMap为集群启用ContainerLogV2架构。 如果同时启用这两个设置，ConfigMap 优先级更高。 仅当两者都显式设置为关闭时，才会使用 ContainerLog 该表。

在启用 ContainerLogV2 架构之前，请评估是否有依赖于 ContainerLog 表的任何警报规则。 更新任何此类警报以使用新表。 请运行以下 Azure Resource Graph 查询以扫描引用 ContainerLog 表的警报规则。

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

Kubernetes 元数据和日志筛选

Kubernetes 元数据和日志筛选通过添加额外的 Kubernetes 元数据来扩展 ContainerLogV2 架构。 日志筛选功能为工作负荷容器和平台容器提供筛选功能。 这些功能可提高工作负荷的可见性。

Features

• 增强型 ContainerLogV2 架构 启用 Kubernetes 元数据时， ContainerLogV2 该表包含名为 KubernetesMetadata 的新列。 通过此列，可以使用简单的日志查询更轻松地进行故障排除，并不需要与其他表联接。 此列中的字段包括podLabels、、podAnnotations、podUidimage、imageID和imageRepoimageTag。 若要启用此功能，请参阅 “启用 Kubernetes 元数据”。
• 日志级别 此功能会向LogLevel添加ContainerLogV2列，其可能值为CRITICAL、ERROR、WARNING、INFO、DEBUG、TRACE或UNKNOWN。 此列可帮助你根据严重性级别评估应用程序运行状况。 Grafana 仪表板将一段时间内的日志级别趋势可视化，以快速查明受影响的资源。
• 用于可视化的 Grafana 仪表板 Grafana 仪表板以颜色编码方式可视化日志级别，并提供有关日志量、日志速率和日志记录的洞察。 仪表板按计算机、Pod 和容器细分数据，以便进行有针对性的故障排除。 若要安装仪表板，请参阅 “安装 Grafana 仪表板”。
• 基于注释的工作负载日志筛选 利用 Pod 注释的高效日志筛选。 这样你就可以专注于相关信息，过滤掉无关信息的干扰。 基于标注的筛选功能使你能够通过为 Pod 添加标注来排除特定的 Pod 和容器的日志收集，从而显著降低日志分析成本。 若要详细了解如何配置基于注释的筛选，请参阅基于注释的日志筛选。
• 基于 ConfigMap 的平台日志筛选（系统 Kubernetes 命名空间） 平台日志由系统（或类似受限）命名空间中的容器发出。 默认情况下会排除系统命名空间中的所有容器日志，以最大程度地降低 Log Analytics 工作区中的数据成本。 但是，在特定故障排除方案中，系统容器的容器日志起着重要作用。 一个示例是 coredns 命名空间中的 kube-system 容器。

启用 Kubernetes 元数据

请使用具有以下设置的 ConfigMap 启用 Kubernetes 元数据。 启用 metadata_collection 时，默认收集所有元数据字段。 取消注释 include_fields 以指定要收集的各个字段。

[log_collection_settings.metadata_collection]
    enabled = true
    include_fields = ["podLabels","podAnnotations","podUid","image","imageID","imageRepo","imageTag"]

几分钟后，该 KubernetesMetadata 列将显示在表的任何日志查询 ContainerLogV2 中，如以下屏幕截图所示。

安装 Grafana 仪表板

从 Grafana 库中的 ContainerLogV2 仪表板导入仪表板。 打开仪表板并选择 DataSource、订阅、ResourceGroup、群集、命名空间和标签的值。

多行日志记录

多行日志记录将以前拆分的容器日志拼凑在一起，并将其作为单个条目发送到 ContainerLogV2 表。 使用 ConfigMap 启用多行日志记录，如使用 ConfigMap 配置容器日志集合中所述。

Limitations

• 多行日志记录功能仅用 Java、Python、.NET 和 Go 实现从容器中整合异常堆栈跟踪。 其他多行日志条目（包括自定义异常和任意日志消息）不会合并在一起。
• Python 异常堆栈跟踪在细粒度错误位置跟踪中不支持多行日志记录。 若要使多行日志记录正常工作，需要选择退出此功能，如 Python 文档中所述。
• 默认情况下，容器运行时将日志行截断为 16 KB。 启用多行日志记录时， ContainerLogV2 支持最多 64 KB 的日志行。

Examples

Go 异常堆栈跟踪多行日志记录已禁用

Go 异常堆栈跟踪多行日志记录已启用

屏幕截图显示已启用的多行功能。

Java 堆栈跟踪多行日志记录已启用

Python 堆栈跟踪多行日志记录已启用

后续步骤

• 为 ContainerLogV2 配置 基本日志 。
• 了解如何从 ContainerLogV2 查询数据 。