容器组维度图表

一、概述

容器组维度监控模块聚焦于Kubernetes最小可调度单元的运行状态，深入监控Pod的生命周期阶段（Pending、Running、Terminating）、资源使用率（CPU、内存）、重启次数、就绪与存活状态，并关联其容器日志与事件。该视图是定位应用实例级故障的核心环节，帮助用户快速判断Pod是否健康、资源是否不足或存在异常退出。

二、核心监控指标说明

1. CPU

1.1 CPU使用量

• 指标含义：该指标直接反映Pod内所有容器在单位时间内实际消耗的CPU时间绝对值，通常以CPU核心数×时间为单位（如：核·秒/秒 简化为核，或毫核·毫秒/秒）。它衡量的是Pod对计算资源的绝对消耗量，不依赖于任何配额或限制作为基准。
• 常用单位与计算：
  • 核心数（Cores）：最直观的表示。例如，0.5表示平均消耗了半个CPU核心的计算能力。
  • 毫核（millicores）：Kubernetes资源请求/限制的常用单位。例如，500m等于0.5核心。

1.2 CPU使用率

• 指标含义：该指标反映Pod内所有容器在过去一段时间内（通常为1分钟或5分钟）实际使用的CPU时间占其可分配CPU总量的百分比。它衡量的是Pod对计算资源的实际消耗水平。

• 计算方式：Pod CPU使用率 = (Pod所有容器消耗的CPU时间之和 / 时间窗口) / Pod可分配的CPU核心数 × 100%

  • CPU时间：在Linux中通常以“内核jiffies”或“纳秒”为单位，由cpuacct CGroup驱动提供。

  • 可分配CPU核心数：指Pod的limits.cpu值（单位为核），是Kubernetes调度和资源保障的基础。

1.3 CPU限流比 / CPU节流比率

• 指标含义：该指标衡量Pod内所有容器因达到CPU使用限额而被内核强制限制（Throttled）的时间比例。它直接反映了Pod是否因limits设置过低或突发负载而频繁遭遇CPU资源剥夺，是评估应用性能稳定性的关键指标。

• 计算方式：Pod CPU限流比 = (Pod所有容器被限流的时间之和 / 容器可运行的总时间之和) × 100%

  • 数据来源于CGroup的cpu.stat文件中的throttled_time和nr_periods等字段。

• 监控价值与解读：

  • 核心健康指标：任何非零的限流比都值得关注，意味着应用经历了计划外的停顿。
  • 轻微限流（< 5%）：可能由短暂的CPU峰值引起，需观察是否伴随请求延迟增加。
  • 显著限流（5% - 20%）：表明limits设置可能过于严格，或负载模式存在周期性高峰，这会导致应用平均响应时间（RT）明显升高。
  • 严重限流（> 20%）：意味着Pod大部分时间都在等待CPU，应用性能严重受损，用户体验极差。这是需要立即干预的警报信号。
  • 与CPU使用率的关系：高CPU使用率不一定导致高限流比（如果limits设得很高）。但高限流比一定伴随着Pod试图使用超过limits的CPU。两者结合看：
    • 高使用率 + 高限流比 -> limits是瓶颈，需要调高或优化应用。
    • 低使用率 + 高限流比 -> 可能limits极低，或应用CPU使用模式为“突发短时高峰”，极易触发限流。

2. 内存

2.1 内存使用量

• 指标含义：该指标直接反映Pod内所有容器在某一时刻实际占用的物理内存（RSS）绝对值，通常以字节（Bytes）为单位。它衡量的是Pod对内存资源的绝对消耗量，不依赖于任何配额或限制作为基准。
• 常用单位与计算：
  • 字节（Bytes）：基础单位，适用于精确监控。
  • 兆字节（MiB）：最常用的表示单位。例如，200Mi表示占用约200兆字节内存。
  • 千兆字节（GiB）：适用于内存消耗较大的工作负载。例如，1.5Gi表示占用约1.5千兆字节内存。

2.2 内存使用率

• 指标含义：该指标反映Pod内所有容器在某一时刻实际使用的内存量占其可分配内存上限（limits.memory）的百分比。它衡量的是Pod对内存资源的相对消耗水平。

• 计算方式：Pod内存使用率 = Pod所有容器内存使用量之和 / Pod的内存限制（limits.memory）× 100%

  • 内存使用量：通常指常驻内存集（RSS）。
  • 内存限制：指Pod的limits.memory值，单位为字节，是Kubernetes进行OOM（内存不足）判定的基准。

• 监控价值与解读：

  • 核心健康指标：直接关联到OOM Kill风险。
  • 安全范围（< 80%）：通常认为在此范围内运行是安全的，留有缓冲应对突发负载。
  • 预警范围（80% - 90%）：需要关注，可能触发内存压力，影响性能或稳定性。建议考虑优化应用或适当调高limits。
  • 危险范围（> 90%）：OOM Kill风险极高，应用可能随时被终止，需要立即干预。通常伴随节点内存压力增大。
  • 特殊情况：如果内存使用率长期远低于限制（如<50%），则可能存在资源浪费，可考虑适当调低limits以提升集群资源利用率。

2.3 容器内存分配失败次数/秒

• 指标含义：该指标记录Pod内各容器每秒内尝试从系统分配内存但失败（即触发直接内存回收或OOM Killer）的次数。对应Prometheus指标container_memory_failcnt。它是一个累积计数器，计算其变化率（rate()）即可得到每秒的失败次数。

• 监控价值与解读：

  • 关键性能与稳定性指标：任何非零的持续失败率都意味着严重问题，表明容器正在经历内存压力，其性能已经或即将受损。

  • 轻微或偶发失败：可能由短暂的、突发性的内存需求导致，但内核通过紧急回收（直接回收或杀死其他进程）满足了本次分配。这通常会引起应用延迟抖动或性能下降。

  • 持续或高频失败：表明容器的内存需求持续超过其可用物理内存（或CGroup限制），系统在频繁地进行直接内存回收，甚至可能已经触发了针对该容器或其内部进程的OOM Killer。这会导致：

    1. 应用性能严重劣化：频繁的直接内存回收（特别是涉及大量匿名页时）会阻塞进程，导致应用响应时间（RT）急剧上升。

    2. 应用意外终止风险：如果OOM Killer被触发，容器内的关键进程可能被杀死，导致服务中断。

  • 与内存使用率的关系：

    • 内存使用率已接近或达到100%：分配失败是预期结果，应用已处于OOM边缘。
    • 内存使用率未满（如80%）：仍然出现分配失败，可能的原因是：
      1. 内核碎片化导致无法满足大块连续内存的分配请求。
      2. 内存限制可能设置得过低，无法满足应用稳定运行的基本需求。
      3. 应用存在内存使用模式问题（如频繁分配/释放大对象）。

  • 行动建议：

    • 当观察到持续的内存分配失败时，应立即调查。
    • 结合container_memory_cache（页面缓存）、container_memory_swap（交换使用量）等指标，分析内存压力的具体来源。
    • 首要检查并适当增加该容器的limits.memory。
    • 优化应用内存使用，避免内存泄漏或过度的内存消耗模式。
    • 对于关键业务，考虑设置内存最低保证（requests.memory）以避免因节点资源紧张而被驱逐。

3. 磁盘

3.1 卷使用量

• 指标含义：该指标反映Pod挂载的持久卷（PersistentVolume）在某一时刻已使用的存储空间绝对值，通常以字节（Bytes）为单位。它衡量的是Pod对持久化存储资源的实际消耗量。
• 常用单位与计算：
  • 字节（Bytes）：基础单位，适用于精确监控。
  • 千字节（KiB）：适用于小文件存储监控。
  • 兆字节（MiB）：最常用的表示单位。
  • 千兆字节（GiB）：适用于数据库、日志等大容量存储场景。
• 数据来源：
  • 对于持久卷（PV）：通过节点上的存储插件（如CSI）或文件系统工具获取。
  • 对于临时卷：通过节点的本地文件系统监控获取。
• 监控价值：
  • 直接反映应用数据存储的实际占用情况。
  • 用于容量规划和存储成本管理。
  • 可预警存储空间即将耗尽的风险（需结合使用率分析）。
  • 区分不同Pod对共享存储的占用比例。

3.2 卷使用率

• 指标含义：该指标反映Pod挂载的卷在某一时刻已使用的存储空间占其总容量（Capacity）的百分比。它衡量的是Pod对存储资源的相对占用水平。
• 计算方式：卷使用率 = 卷已使用空间 / 卷总容量 × 100%
  • 卷已使用空间：卷上所有文件和元数据占用的实际空间。
  • 卷总容量：卷创建时定义的最大可用空间。
• 监控价值与解读：
  • 核心健康指标：直接关联到存储耗尽风险。
  • 安全范围（< 80%）：在此范围内运行较为安全，留有扩展空间。
  • 预警范围（80% - 90%）：需要关注，应考虑清理旧数据、压缩或扩容。
  • 危险范围（> 90%）：
    • 存储空间即将耗尽，可能导致应用写入失败、数据丢失。
    • 对于数据库等关键应用，可能引发服务中断。
    • 必须立即干预：清理数据或紧急扩容。
  • 特殊情况：
    • 使用率接近100%但写入仍在继续：可能使用了动态扩容功能。
    • 使用率波动剧烈：可能表示应用有大量的临时文件创建和删除。

3.3 磁盘读速率

• 指标含义：该指标反映Pod内所有容器在单位时间内从挂载卷读取的数据量，通常以字节/秒（B/s）为单位。它衡量的是Pod对存储的读取访问强度。

• 常用单位：

  • 字节/秒（B/s）：基础单位。
  • 千字节/秒（KiB/s）：适用于一般文件操作。
  • 兆字节/秒（MiB/s）：适用于大数据处理、数据库查询等场景。

• 监控价值与解读：

  • 性能分析：高读速率可能表示：
    • 应用正在处理大量数据（如数据分析任务）。
    • 数据库正在进行全表扫描或复杂查询。
    • 缓存未命中，大量请求回源到持久化存储。
  • 瓶颈识别：
    • 如果读速率持续接近存储设备的IOPS或带宽上限，可能成为性能瓶颈。
    • 结合CPU使用率分析：高读速率 + 高CPU等待IO时间（%iowait）表明存储IO是瓶颈。
  • 异常检测：
    • 读速率异常飙升：可能遭受恶意扫描或应用逻辑错误。
    • 读速率为零或极低但应用应活跃：可能存储挂载异常或应用故障。
  • 优化指导：
    • 对于读密集型应用，可考虑使用更高性能的存储类型（如SSD）。
    • 引入缓存层（如Redis）减少对持久化存储的直接读取。

3.4 磁盘写速率

• 指标含义：该指标反映Pod内所有容器在单位时间内向挂载卷写入的数据量，通常以字节/秒（B/s）为单位。它衡量的是Pod对存储的写入访问强度。
• 常用单位：
  • 字节/秒（B/s）：基础单位。
  • 千字节/秒（KiB/s）：适用于日志写入、事务处理。
  • 兆字节/秒（MiB/s）：适用于数据备份、大数据写入等场景。
• 监控价值与解读：
  • 性能与稳定性分析：
    • 高写速率：可能表示应用正在大量写入日志、进行数据导入或执行频繁的事务提交。
    • 写速率突增：可能触发存储性能瓶颈，影响应用响应时间。
  • 持久化与数据安全：
    • 持续的高写速率会加速存储介质磨损（特别是SSD）。
    • 结合卷使用率监控：高写速率会快速消耗可用空间。
  • 异常检测：
    • 写速率异常高且无相应业务背景：可能遭遇攻击（如日志注入）或应用bug（如无限循环写文件）。
    • 写速率为零但应用应正常写入：可能磁盘已满、权限问题或应用故障。
  • 优化与容灾：
    • 对于写密集型应用，选择高IOPS、高吞吐的存储类型。
    • 实施写入缓冲、批量提交等优化策略。
    • 确保有足够的存储空间缓冲和监控告警，避免因写满导致服务中断。
  • 与读速率的综合分析：
    • 读写均衡型：数据库等OLTP应用通常读写速率都较高。
    • 写密集型：日志采集、数据备份应用通常写速率远高于读速率。
    • 读密集型：内容服务、缓存服务通常读速率远高于写速率。

4. 网络

4.1 网络接收速率

• 指标含义：该指标反映Pod内所有容器在单位时间内从网络接口接收到的数据量，通常以字节/秒（B/s）为单位。它衡量的是Pod入方向网络流量的强度。
• 常用单位：
  • 字节/秒（B/s）：基础单位。
  • 千字节/秒（KiB/s）：适用于一般网络应用。
  • 兆字节/秒（MiB/s）：适用于视频流、大文件传输等高带宽场景。
  • 千兆字节/秒（GiB/s）：适用于高性能计算、大数据传输场景。
• 监控价值与解读：
  • 业务流量监控：
    • 反映服务的请求负载：HTTP服务器、API网关的接收速率与请求量正相关。
    • 数据摄入速率：对于数据采集、消息队列消费者等应用，接收速率反映数据处理能力。
  • 性能瓶颈识别：
    • 持续高接收速率可能接近网络带宽上限，导致延迟增加。
    • 结合CPU使用率：高接收速率 + 高CPU中断处理时间表明网络处理成为瓶颈。
  • 异常检测：
    • 突增式接收速率：可能遭受DDoS攻击、数据风暴或配置错误导致的流量重定向。
    • 接收速率归零但服务应活跃：可能网络策略（NetworkPolicy）阻断、服务端点异常或应用故障。
    • 接收速率周期性波动：反映业务访问模式（如日间高峰、夜间低谷）。
  • 容量规划：
    • 长期趋势分析用于网络带宽扩容决策。
    • 结合副本数评估水平扩展需求。

4.2 网络发送速率

• 指标含义：该指标反映Pod内所有容器在单位时间内从网络接口发送出的数据量，通常以字节/秒（B/s）为单位。它衡量的是Pod出方向网络流量的强度。
• 常用单位：同网络接收速率（B/s、KiB/s、MiB/s、GiB/s）。
• 监控价值与解读：
  • 业务响应监控：
    • 反映服务的响应数据量：API响应、文件下载、视频流发送。
    • 数据同步速率：数据库主从同步、跨区域数据复制。
  • 性能与成本分析：
    • 出站流量成本：在公有云环境中，出站流量通常产生费用，需要监控控制。
    • 响应效率：高发送速率可能意味着响应体过大，需考虑数据压缩或分页。
  • 异常检测：
    • 发送速率异常高：可能遭受数据窃取、配置错误导致的数据泄露，或应用bug导致无限循环响应。
    • 发送速率突降：可能下游服务故障、网络分区或应用处理能力下降。
    • 不对称流量模式：发送速率远高于接收速率（如视频流服务器）；接收速率远高于发送速率（如数据处理服务）。
  • 服务质量评估：
    • 结合响应时间（RT）：高发送速率应伴随合理的响应时间，若RT增加则需优化网络或应用。
    • 对于CDN、代理等服务，发送速率是核心性能指标。

4.3 接收丢包速率

• 指标含义：该指标反映Pod内所有容器在单位时间内接收方向丢失的网络数据包数量，通常以包/秒（packets/s）或丢包率（%）表示。它衡量的是入方向网络传输的可靠性。
• 计算方式：
  • 丢包速率：接收丢包数/秒 = Δ接收丢包计数 / 时间间隔
  • 丢包率：接收丢包率 = 接收丢包数 / (接收成功数 + 接收丢包数) × 100%
• 监控价值与解读：
  • 网络质量关键指标：任何持续的非零丢包率都表示网络存在问题。
  • 轻微丢包（< 0.1%）：
    • 可能由网络轻微拥塞、物理链路正常波动引起。
    • 对于TCP应用，会触发重传，轻微增加延迟，通常可容忍。
    • 对于UDP实时应用（音视频），可能导致卡顿、花屏。
  • 中度丢包（0.1% - 1%）：
    • 表明网络存在明显拥塞或链路质量问题。
    • TCP连接吞吐量显著下降，延迟明显增加。
    • 需要调查网络设备（交换机、路由器）、CNI插件或节点负载。
  • 严重丢包（> 1%）：
    • 网络严重拥塞、硬件故障或配置错误。
    • 导致服务严重降级甚至不可用。
    • 必须立即干预：检查网络设备、带宽使用、防火墙规则等。
  • 特殊场景解读：
    • 突发性丢包：可能由网络瞬间拥塞、广播风暴或安全设备拦截引起。
    • 持续性丢包但带宽使用率低：可能物理链路故障、网卡驱动问题或MTU不匹配。
    • 特定目标丢包：可能网络策略（NetworkPolicy/ACL）限制或对端服务问题。

4.4 发送丢包速率

• 指标含义：该指标反映Pod内所有容器在单位时间内发送方向丢失的网络数据包数量，通常以包/秒（packets/s）或丢包率（%）表示。它衡量的是出方向网络传输的可靠性。
• 计算方式：
  • 丢包速率：发送丢包数/秒 = Δ发送丢包计数 / 时间间隔
  • 丢包率：发送丢包率 = 发送丢包数 / (发送成功数 + 发送丢包数) × 100%
• 监控价值与解读：
  • 发送缓冲区与拥塞指标：
    • 发送丢包通常因为发送缓冲区溢出，表明：
      1. 应用发送速率超过网络接口处理能力。
      2. 对端接收太慢（流量控制）。
      3. 网络路径拥塞。
    • 对于TCP，发送缓冲区满会导致应用write()调用阻塞。
  • 严重性分级：
    • 偶发送丢包：可能由瞬间流量突发引起，TCP会通过拥塞控制调整。
    • 持续发送丢包：表明持续拥塞，需要立即调查：
      • 检查对端服务状态和接收能力。
      • 检查网络路径带宽和延迟。
      • 调整应用发送节奏或缓冲区大小。
  • 与接收丢包的关联分析：
    • 本Pod发送丢包 + 对端Pod接收丢包：网络路径中间环节问题。
    • 本Pod发送丢包但对端无接收丢包：可能本机网卡、驱动或CNI问题。
    • 本Pod接收丢包但对端无发送丢包：可能本机处理能力不足或缓冲区设置不当。
  • 对应用的影响：
    • TCP应用：丢包触发重传和拥塞窗口减小，降低吞吐量，增加延迟。
    • UDP应用：数据永久丢失，需应用层处理可靠性（如有需要）。
    • 实时音视频：丢包导致卡顿、音画不同步，用户体验差。