什么是容器网络日志?

Advanced Container Networking Services Azure Kubernetes 服务 (AKS) 中的容器网络日志可用于查看群集中的每个网络流。 指标会告诉你网络中 发生的情况 (带宽使用情况、错误率)。 日志告诉你 原因:谁发起了连接、使用了哪些协议,以及是允许还是阻止了流量。

这些日志捕获每个网络流的元数据:

  • 源和目标 IP 地址、Pod 名称和服务名称
  • 命名空间、端口和协议
  • 交通方向和策略决策

在此上下文中,可以将网络行为与特定工作负荷相关联,对连接进行故障排除、验证安全策略和执行取证分析。 容器网络日志涵盖第 3 层(IP)、第 4 层(TCP/UDP)和第 7 层(HTTP/gRPC/Kafka)流量。

为了管理数据量和成本,容器网络日志支持 流日志聚合,将类似的流分组到汇总记录中,而不是为每个连接事件存储一条记录。 在减少存储和引入成本的同时,保留所需的操作模式。 有关详细信息,请参阅 流日志聚合。

容器网络日志提供两种模式:

  • 存储的日志 - 使用自定义筛选器和流聚合进行连续收集。 最适合长期监视和分析。
  • 按需日志 - 通过 Hubble CLI 和 Hubble UI 实时捕获。 最适合临时故障排除。

如果需要持久记录进行合规性、趋势分析或自动警报,请使用存储的日志。 实时调试连接或性能问题时,请使用按需日志,以便立即查看实时流量。

存储的日志

每当群集上启用高级容器网络服务时,都会自动启用存储日志模式。 此功能已到位,但在告知 ACNS 捕获内容之前,不会生成日志。

为了开始收集日志,请定义 ContainerNetworkLog 自定义资源,以指定要监控的流量:按命名空间、Pod、服务、协议或监控结果。 应用 CRD 后,Cilium 代理将开始生成与筛选器匹配的流,并将其写入每个节点。 集合保持活动状态,直到删除 CRD 或禁用 ACNS。

由于确切控制通过 CRD 筛选器记录的流量,因此你可以专注于重要的流,并避免收集不必要的数据。 结合 流日志聚合,此方法可预测存储成本并集中分析。

存储日志模式的工作原理

高级容器网络服务将 eBPF 技术与 Cilium 配合使用来捕获每个节点上的网络流。 启用 ACNS 并 ContainerNetworkLog 应用自定义资源后,Cilium 代理将收集与筛选器匹配的流量,并将 JSON 格式 /var/log/acns/hubble/events.log 的日志写入每个主机上。 日志生成完全在群集内部运行,不依赖于Azure Monitor。

对于生产用途,我们建议启用Azure Monitor加载项。 启用后,Container Insights 代理会收集主机本地日志、应用限流限制,并将其发送到 Log Analytics 工作区,在其中您可以使用长期保留、KQL 查询和内置 Azure 门户以及 Grafana 仪表板。 这是最集成的路径,也是客户最应该选择的路径。

如果您的团队已经有了现有的可观测性管道,则可以将相同的主机本地日志转发到任何与 OpenTelemetry 兼容的收集器或日志记录服务,无论是与 Azure Monitor 一同使用还是替代 Azure Monitor。

容器网络日志工作原理图。

有关限流和容器见解的详细信息,请参阅 Container Insights 文档。

通过或不带Azure Monitor使用容器网络日志

可以通过两种方式使用容器网络日志。 正确的选择取决于您是想要集成的Azure原生体验,还是已经拥有并想继续使用的可观测性流水线。

路径 您将获得的内容 何时选择
Azure Monitor加载项(推荐) 容器见解将主机本地日志收集到 Log Analytics 工作区。 可以立即获取开箱即用的长期保留、KQL、内置的 Azure 门户仪表板和托管的 Grafana 仪表板。 你需要在 AKS 上提供最集成的生产就绪体验,且设置最少。
使用自己的管道托管本地文件 ACNS 将 JSON 日志 /var/log/acns/hubble/events.log 写入每个节点上。 将它们转发到任何与 OpenTelemetry 兼容的收集器或日志记录服务——可以与 Azure Monitor 一起使用或替代它。 你已经有一个集中式可观察性平台,并希望网络日志存储在那里。

对于大多数客户,我们建议启用Azure Monitor。 这是在不生成自己的管道的情况下获取保留、查询和仪表板功能的最快方法。

存储日志模式的关键功能

  • 可自定义的筛选器。 定义 ContainerNetworkLog 自定义资源,按命名空间、Pod、服务、端口、协议、判决或流量方向进行筛选。 仅记录匹配的流量,因此你可以精确控制所收集的内容及其成本。

  • 流日志聚合。 类似的流每 30 秒自动分组到汇总记录中,同时减少数据量,同时保留服务通信模式、错误率和安全判决等操作信号。 与目标筛选器配对后,聚合可让你保持广泛的可见性,而无需过多的引入成本。 有关详细信息,请参阅 流日志聚合。

  • 日志存储选项。 ACNS 始终在每个节点上本地写入日志。 在此处,可以选择如何使用它们:

    • 主机本地文件(始终打开): 日志存储在主机 /var/log/acns/hubble节点上。 文件在达到 50 MB 时自动旋转,旧的日志会被覆盖。 直接将其用于短期实时监视,或将文件转发到任何与 OpenTelemetry 兼容的收集器或日志记录服务,以便进行其他日志管理。

    • Azure Monitor(建议):启用Azure Monitor加载项以在Log Analytics工作区中收集和存储日志。 可以通过 Prometheus 的托管服务获得安全、合规的存储,包括长期保留、KQL 查询、异常情况检测、历史分析和警报。 日志生成仍通过 Cilium 代理和 ContainerNetworkLog CRD 运行;而 Azure Monitor 在其上添加了一个使用层。

      该 ContainerNetworkLogs 表默认使用 Analytics 层。 可以切换到 基本 层,降低引入和保留成本,同时保持类似的可观测性体验。 每个层都有一个专用Azure门户仪表板,针对其查询功能进行了优化。 如需了解有关表计划的更多信息,请参阅 Log Analytics 表计划。 若要了解如何设置表计划,请参阅 “设置表计划”。

  • Azure门户中的可视化效果。 直接在Log Analytics中查询和分析日志,或使用内置Azure门户仪表板。 专用仪表板可用于每个表层,因此无论选择哪个层,都能获得相同的可观测性体验。 有关详细信息,请参阅 Azure 门户中的 Visualize 日志。

在 Azure 门户中可视化日志

可以在群集的 Log Analytics 工作区的 Azure 门户中可视化、查询和分析流日志。

Log Analytics 工作区中容器网络日志的屏幕截图。

容器网络日志包括用于可视化流数据的内置Azure门户仪表板。 每个Log Analytics表层都有单独的仪表板:

Dashboard 路径 表格层级
流日志 - 基本层 (ID: 23155) Azure>监控>容器>网络>流日志 - 基本层 基本
流日志 - 分析层 (ID: 23156) Azure>见解>容器>网络>流量日志 - 分析层 分析(默认)

这两个仪表板都显示哪些 AKS 工作负载相互通信,包括网络请求、响应、删除和错误。 使用与为 ContainerNetworkLogs 表配置的表级别匹配的仪表板。

Tip

表 ContainerNetworkLogs 默认为 Analytics 层。 若要降低成本,可以切换到基本层并使用相应的基本层仪表板,而不会丢失可观测性覆盖范围。 有关详细信息,请参阅日志分析表格计划。

Azure门户仪表板具有以下主要组件:

  • 网络运行状况概述。 顶部部分显示摘要指标(总流日志、唯一请求、已删除的请求和转发的请求),以便快速发现异常。 统计信息按协议细分:DNS 删除的请求、HTTP 2xx 响应、第 4 层请求和响应速率以及删除计数。 服务依赖项图显示哪些服务相互通信,从而更轻松地识别瓶颈和意外流量路径。

    流日志统计信息和服务依赖项图的屏幕截图。

  • 流日志和错误日志。 仪表板将流日志与错误日志分隔为不同的视图,因此你可以专注于错误,而无需筛选正常流量。 使用内置筛选器按协议、命名空间或判决缩小结果范围。 例如,若要排查 DNS 解析失败问题,请按 DNS 协议筛选错误日志。

    流日志和错误日志的屏幕截图。

    每个日志条目都包含标签、时间戳和源/目标详细信息,以帮助在调查期间查明特定事件。

    Azure 门户仪表板中可用筛选器的屏幕截图。

  • 排名靠前的命名空间、工作负载和 DNS 错误。 本部分显示最活跃的命名空间、最高的流量工作负载、端口使用情况和最常见的 DNS 错误。 使用它来确定哪些工作负载生成最多的流量、发现丢弃的请求,以及比较协议分布(例如 TCP 与 UDP)。 此处的异常模式(例如意外高峰或不熟悉的目标)可能表示配置错误或安全问题。

    顶部命名空间和 Pod 指标的屏幕截图。

流日志聚合

网络流量快速累积。 具有 200 个微服务的群集每 30 秒可以生成数十万条流记录。 存储所有原始数据的成本很高。

例如,假设 client-1 和 client-2 都通过 TCP 与 server pod 通信。 在 30 秒的窗口中,节点上的原始流记录如下所示:

来源 源端口 目的地 目标端口 协议 Flag
client-1 12345 服务器 80 TCP SYN
服务器 80 client-1 12345 TCP SYN-ACK
client-1 12345 服务器 80 TCP ACK
client-1 12345 服务器 80 TCP PSH
服务器 80 client-1 12345 TCP ACK
client-2 23456 服务器 80 TCP SYN
服务器 80 client-2 23456 TCP SYN-ACK
client-2 23456 服务器 80 TCP ACK
client-2 23456 服务器 80 TCP PSH
服务器 80 client-2 23456 TCP ACK

通过聚合,这 10 条记录变为两条:

来源 源端口 目的地 目标端口 协议 发送的数据流 收到的流
client-1 12345 服务器 80 TCP 4 6
client-2 23456 服务器 80 TCP 4 6

流日志聚合通过将类似的流分组到汇总的记录中来解决此问题。 在每个 30 秒的时间窗口中,具有相同聚合键域的流合并为单个记录,并计数出所表示的流数量。

以下字段构成聚合键:

领域 说明
verdict 转发、丢弃或错误
is_reply 流是请求(“false”)还是响应(“true”)
drop_reason_desc 数据包被丢弃的原因
source.namespace 源 Pod 命名空间
destination.namespace 目标 Pod 命名空间
source.workloads 源工作负荷(部署、StatefulSet 或 DaemonSet)
destination.workloads 目标工作负载(Deployment、StatefulSet 或 DaemonSet)
source.identity 源安全标识(始终显示为后备)
destination.identity 目标安全标识(始终作为后备选项存在)
l4.TCP.destination_port TCP 目标端口
l4.UDP.destination_port UDP 目标端口
l7.http.code HTTP 响应代码(200、404、500 等)
l7.dns.rcode DNS 响应代码(NOERROR、NXDOMAIN 等)
IP.ipVersion IPv4 或 IPv6
IP.encrypted 流是否加密(WireGuard/IPsec)
source.cluster_name 源群集名称
destination.cluster_name 目标群集名称

在30秒的时间窗口内,匹配所有这些字段的流将被合并为一条记录。 这会保留您所需的信号(哪些服务进行通信、通信频率、出现哪些错误、是否允许或阻止流量),同时大幅削减数据量。 与可能随机丢弃数据流并错过稀有安全事件的采样不同,聚合会完整保留模式信息的100%。

要点:

  • 默认情况下启用和配置聚合。 这样可减少日志存储和引入成本,而无需进行任何手动优化。
  • 可以通过includeFilters在ContainerNetworkLog CRD 中控制捕获的流量。
  • 较窄的筛选器(特定命名空间或服务对)通常可实现更好的压缩,因为捕获的流更相似。
  • 聚合日志跳过高基数和每流属性(例如,单个时间戳、Pod IP、HTTP URL、DNS 查询名称),以最大程度地减少引入量和存储成本。 它们专为高级问题检测而设计。 使用按需日志进行细粒度流分析和调查。

注释

实际存储减少因筛选器配置、工作负荷多样性和流量模式而异。

按需日志

按需日志允许实时捕获和检查流日志,而无需事先配置或永久性存储。 主动排查连接或性能问题并需要即时可见性时,请使用按需日志。

ACNS 提供两种按需捕获工具。 若要设置任一工具,请参阅 “配置按需日志”模式。

Hubble CLI

通过 Hubble CLI,可以直接从终端查询、筛选和分析流日志。 当你需要细粒度筛选器(例如,在进行中的调试会话期间按命名空间、Pod 标签或决策隔离流量)时,它特别有用。

Hubble CLI 的屏幕截图。

Hubble 用户界面

Hubble UI 提供服务到服务通信的图形视图。 如果想要直观跟踪流量路径、识别哪些服务正在通信,并在不编写 CLI 命令的情况下发现异常,则非常适合此情况。

Hubble UI 的屏幕截图。

按需日志的主要优势

  • 无需事先配置。 在不定义自定义资源或设置存储的情况下立即开始捕获流。
  • 实时可见性。 检查实时流量,并在出现问题时查看数据包元数据。
  • 快速故障排除。 通过 Hubble CLI 以交互方式筛选流,或在 Hubble UI 中直观地查看服务映射。
  • 开销较低。 无需持久性存储,因此临时调查无需持续成本。

有关存储日志的建议

  1. 先使用广泛筛选标准,然后逐渐缩小范围。 首次启用流日志时,请使用宽筛选器捕获密钥命名空间中的流量。 运行配置几天,并在Log Analytics中查看收集的数据。 查看数据量、成本以及捕获的流是否符合实际需求。 然后收紧你的 includeFilters,专注于高价值流量,消除杂音。

  2. 首先使用预生成的仪表板。 内置Azure门户仪表板涵盖常见用例,例如服务通信模式、错误率和 DNS 故障。 从那里开始。 仅在需要获取预生成仪表板未提供的可见性时,才添加自定义面板或 Log Analytics 查询。

  3. 定期查看。 随着工作负荷和流量模式的变化,筛选器可能需要更新。 定期检查数据量和流覆盖率,确保仍以合理的成本捕获正确的流量。

局限性

数据平面和功能要求:

  • 存储日志模式仅适用于 Cilium 数据平面。
  • 仅当启用第 7 层策略支持时,才会捕获第 7 层流日志。 有关详细信息,请参阅 配置第 7 层策略。
  • 仅当应用 Cilium 完全限定域名(FQDN)网络策略时,才会捕获 DNS 流和指标。 有关详细信息,请参阅 配置 FQDN 策略。

聚合权衡:

  • 流日志聚合不会保留单个流时间戳、每个 pod 的 IP 地址或 HTTP URL 和 DNS 查询名称等高基数字段。 使用按需日志对每个流进行分析。

存储和平台:

  • 每个节点的 /var/log/acns/hubble/ 主机本地文件上限为 50 MB,并自动轮换。 如果需要长期保留,请启用Azure Monitor(建议)或将文件转发到自己的日志记录服务。
  • 不支持辅助日志表计划。

Pricing

Important

高级容器网络服务是一项付费服务。

有关定价的详细信息,请参阅高级容器网络服务 - 定价。