容器见解日志架构

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

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

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

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

² KubernetesMetadata 是一个可选列，通过 Kubernetes 元数据启用。 该字段的值为 JSON，包含字段 podLabels、podAnnotations、podUid、Image、ImageTag 和 Image repo。

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

请使用群集的数据收集规则 (DCR) 或 ConfigMap 为群集启用 ContainerLogV2 架构。 如果同时启用这两个设置，ConfigMap 优先级更高。 只有在 DCR 和 ConfigMap 都显式设置为关闭时，才使用 ContainerLog 表。

在启用 ContainerLogsV2 架构之前，应评估是否有依赖于 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 元数据扩展了 ContainerLogsV2 架构。 日志筛选功能为工作负荷容器和平台容器提供筛选功能。 这些功能为你提供了更丰富的上下文，并提高了对工作负荷的可见性。

• 增强的 ContainerLogV2 架构 启用 Kubernetes 日志元数据后，它会向 ContainerLogV2 添加一个名为 KubernetesMetadata 的列，该列可通过简单的日志查询增强故障排除功能，无需与其他表联接。 此列中的字段包括：PodLabels、PodAnnotations、PodUid、Image、ImageID、ImageRepo、ImageTag。 这些字段增强了使用日志查询的故障排除体验，无需与其他表联接。 若要详细了解如何启用 Kubernetes 元数据功能，请参阅下文。
• 日志级别 此功能向 ContainerLogV2 添加一个 LogLevel 列，其可能值为 critical、error、warning、info、debug、trace 或 unknown。 这有助于你根据严重性级别评估应用程序运行状况。 添加 Grafana 仪表板，可以直观地看到随时间变化的日志级别趋势，快速找出受影响的资源。
• 用于可视化的 Grafana 仪表板 Grafana 仪表板以颜色编码的方式可视化日志级别，还可用于深入了解“日志量”、“日志速率”、“日志记录”、“日志”。 你可以获取时间敏感的分析、对日志级别趋势的动态见解以及关键的实时监视。 仪表板还提供了按计算机、Pod 和容器的详细细目，支持深入分析和精确的故障排除。 若要详细了解如何安装 Grafana 仪表板，请参阅下文。
• 基于注释的工作负荷日志筛选 利用 Pod 注释的高效日志筛选。 这样你就可以专注于相关信息，无需筛选噪音。 基于注释的筛选使你能够通过注释 Pod 来排除某些 Pod 和容器的日志收集，这有助于显著降低日志分析成本。 若要详细了解如何配置基于注释的筛选，请参阅基于注释的日志筛选。
• 基于 ConfigMap 的平台日志筛选（系统 Kubernetes 命名空间） 平台日志由系统（或类似受限）命名空间中的容器发出。 默认情况下会排除系统命名空间中的所有容器日志，以最大程度地降低 Log Analytics 工作区中的数据成本。 但是，在特定故障排除方案中，系统容器的容器日志起着重要作用。 一个示例是 kube-system 命名空间中的 coredns 容器。

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

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

几分钟后，KubernetesMetadata 列应包含在针对 ContainerLogV2 表的任何日志查询中，如下所示。

从 ContainerLogV2 仪表板处的 Grafana 库导入仪表板。 然后就可以打开仪表板并选择“DataSource”、“订阅”、“ResourceGroup”、“群集”、“命名空间”和“标签”的值。

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

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

已禁用多行日志记录

已启用多行日志记录

Java 堆栈跟踪

Python 堆栈跟踪

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