Compartir a través de

容器见解日志架构

  • Artículo

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

比较表

ContainerLogV2 是 CLI 2.54.0 及更高版本的默认架构。 这是使用托管标识身份验证加入容器见解的客户的默认表。 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。 这种推理可能会导致一些错误分类。 LogLevel 是一个具有运行状况值的字符串字段，例如 CRITICAL、ERROR、WARNING、INFO、DEBUG、TRACE 或 UNKNOWN。

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

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

启用 ContainerLogV2 架构

请使用群集的数据收集规则 (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 元数据和日志筛选通过额外的 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 容器。

启用 Kubernetes 元数据

重要

收集 Kubernetes 元数据需要托管标识身份验证和 ContainerLogsV2

请使用具有以下设置的 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 仪表板

重要

如果按照启用对 Kubernetes 群集的监视中的指南启用了 Grafana，则 Grafana 实例应该已经可以访问 Azure Monitor 工作区以获取 Prometheus 指标。 Kubernetes 日志元数据仪表板还需要访问包含日志数据的 Log Analytics 工作区。 请参阅如何修改对 Azure Monitor 的访问权限，获取有关如何向 Grafana 实例授予 Log Analytics 工作区的“监视读取者”角色的指导。

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

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

注意

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

多行日志记录

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

注意

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

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

已禁用多行日志记录

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

已启用多行日志记录

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

Java 堆栈跟踪

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

Python 堆栈跟踪

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

后续步骤