Docker 容器 CPU 指标详解

以下是10个容器CPU指标，每个指标的含义和作用：

---

1. CPU使用率 (%) cpu_usage

含义：容器当前占用的 CPU 百分比，范围 0~100%。

计算方式：

cpu_usage = (容器CPU增量 / 宿主机CPU增量) × CPU核心数 × 100

作用：

• 实时监控：快速判断容器是否 CPU 繁忙
• 告警触发：超过阈值（如 80%）时告警
• 示例：85.6% 表示该容器快把 CPU 跑满了

---

2. 在线CPU核心数 online_cpus

含义：容器可使用的 CPU 核心数量（不是物理核心，是调度可用的核心数）。

来源：

• cgroup v1: cpuacct.usage_percpu 的长度
• cgroup v2: psutil.cpu_count()

作用：

• 理解使用率：4核容器跑 100% 说明占满了所有授权核心
• 容量规划：判断容器是否应该申请更多核心
• 示例：online_cpus=4 表示该容器可使用4个核心

---

3. CPU使用总时间 (纳秒) cpu_usage_total

含义：容器从启动到当前时刻，累计消耗的 CPU 时间（纳秒）。

来源：

• cgroup v1: cpuacct.usage
• cgroup v2: cpu.stat → usage_usec

作用：

• 计算速率：可以计算某段时间内的平均 CPU 使用率
• 累计统计：分析容器生命周期内的总 CPU 消耗
• 成本核算：按 CPU 消耗计费的依据
• 示例：47,930,796,000 ns = 47.93 秒

---

4. 用户态CPU时间 (纳秒) cpu_usage_user

含义：容器在用户模式（User Mode）下消耗的 CPU 时间。

用户模式：运行应用程序代码（如 Java、Python、MySQL 查询逻辑）

来源：

• cgroup v1: cpuacct.stat → user
• cgroup v2: cpu.stat → user_usec

作用：

• 区分负载类型：用户态高 → 应用层密集计算（正常业务）
• 性能优化：用户态异常高 → 需要优化应用代码
• 示例：24,231,021,000 ns = 24.23 秒

---

5. 内核态CPU时间 (纳秒) cpu_usage_system

含义：容器在内核模式（Kernel Mode）下消耗的 CPU 时间。

内核模式：系统调用、文件 I/O、网络操作、内存管理

来源：

• cgroup v1: cpuacct.stat → system
• cgroup v2: cpu.stat → system_usec

作用：

• 区分负载类型：内核态高 → 大量系统调用（I/O 密集、网络密集）
• 诊断问题：内核态异常高可能意味着频繁系统调用
• 示例：23,699,774,000 ns = 23.70 秒

用户态 vs 内核态对比：

场景	用户态	内核态	说明
正常业务	✅ 高	⚠️ 低	应用在做业务计算
I/O密集	⚠️ 低	✅ 高	大量读写磁盘/网络
异常	❌ 低	❌ 低	CPU 空闲

---

6. 节流周期数 throttled_periods

含义：容器因为超出 CPU 配额（cgroup 限制）而被限制（Throttle）的周期数。

背景：Docker 使用 CFS（完全公平调度器）管理 CPU，每个周期（cpu_period，默认 100ms）检查容器的 CPU 使用是否超过配额（cpu_quota）。

来源：

• cgroup v1: cpu.stat → nr_throttled
• cgroup v2: cpu.stat → nr_throttled

作用：

• 诊断 CPU 瓶颈：该值 > 0 说明容器 CPU 配额不足
• 容量规划：频繁节流说明需要提高 cpu_quota
• 示例：0 表示从未被限流（理想状态）

---

7. 节流总时间 (纳秒) throttled_time

含义：容器因超出 CPU 配额而被限制的总时间。

来源：

• cgroup v1: cpu.stat → throttled_time
• cgroup v2: cpu.stat → throttled_usec

作用：

• 评估影响：节流时间越长，容器性能受影响越大
• 调优参考：结合 throttled_periods 判断严重程度
• 示例：0 表示从未被限流

节流机制图解

CPU时间线（每个周期 = 100ms）
├─────────────────────────────────────────┤
│  容器使用 80ms  │  空闲 20ms   │  配额 60ms  │
│  ✅ 未节流     │              │  ❌ 节流 40ms │
└─────────────────────────────────────────┘

当容器使用的 CPU 超过配额时，多余的请求被"节流"（排队等待）

---

8. CPU配额 (微秒) cpu_quota

含义：容器在每个 CFS 周期内允许使用的 CPU 时间上限（微秒）。

默认值：无限制（-1）

来源：

• cgroup v1: cpu.cfs_quota_us
• cgroup v2: cpu.max

作用：

• 资源限制：限制容器最大 CPU 使用
• 示例：cpu_quota = 50000 us（50ms），周期 cpu_period = 100000 us（100ms）→ 最多使用 50% CPU

---

9. CPU周期 (微秒) cpu_period

含义：CFS 调度器的周期长度（微秒），默认 100000 us = 100ms。

来源：

• cgroup v1: cpu.cfs_period_us
• cgroup v2: cpu.max

作用：

• 配额计算：cpu_usage_limit = cpu_quota / cpu_period
• 示例：cpu_quota = 200000，cpu_period = 100000 → 200% CPU（2个核心）

---

10. CPU份额 cpu_shares

含义：容器在 CPU 资源竞争中的权重（相对优先级）。范围 2~262144，默认 1024。

来源：

• cgroup v1: cpu.shares
• cgroup v2: cpu.weight（映射关系：1-10000）

作用：

• 相对优先级：权重越高，在 CPU 竞争中获得更多时间片
• 示例：容器A权重 2048，容器B权重 1024 → A 获得的 CPU 时间是 B 的 2 倍

---

指标关系图

┌─────────────────────────────────────────────────────────────────────┐
│                         容器 CPU 指标全景图                        │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │                    资源限制                                  │   │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐ │   │
│  │  │ cpu_quota   │  │ cpu_period  │  │    cpu_shares       │ │   │
│  │  │ 最大使用上限 │  │ 调度周期    │  │    相对权重         │ │   │
│  │  └─────────────┘  └─────────────┘  └─────────────────────┘ │   │
│  └─────────────────────────────────────────────────────────────┘   │
│                               ↓                                    │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │                  实际使用                                    │   │
│  │  ┌─────────────┐  ┌─────────────────────────────────────┐  │   │
│  │  │ cpu_usage   │  │   cpu_usage_total                   │  │   │
│  │  │  实时使用率  │  │   (user + system) 累计              │  │   │
│  │  └─────────────┘  │   ├─ cpu_usage_user (用户态)        │  │   │
│  │                    │   └─ cpu_usage_system (内核态)      │  │   │
│  │                    └─────────────────────────────────────┘  │   │
│  └─────────────────────────────────────────────────────────────┘   │
│                               ↓                                    │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │                   限制效果                                   │   │
│  │  ┌─────────────┐  ┌─────────────────────────────────────┐  │   │
│  │  │throttled_   │  │   throttled_time                    │  │   │
│  │  │ periods     │  │   节流时间                          │  │   │
│  │  │ 节流周期数   │  │                                    │  │   │
│  │  └─────────────┘  └─────────────────────────────────────┘  │   │
│  └─────────────────────────────────────────────────────────────┘   │
│                                                                     │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │                  环境信息                                    │   │
│  │              online_cpus (可用核心数)                        │   │
│  └─────────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────────┘

---

实用场景

1. 判断容器是否需要扩容

如果：cpu_usage > 80% 且 throttled_periods > 0
结论：容器 CPU 资源不足，需要增加 cpu_quota 或核心数

2. 判断是应用问题还是资源问题

如果：cpu_usage_user 很高
→ 应用层密集计算，优化应用代码

如果：cpu_usage_system 很高
→ 系统调用频繁，检查 I/O 或网络

3. 容器优先级调优

如果：多个容器共享 CPU，重要容器权重低
→ 增加重要容器的 cpu_shares

4. 成本优化

如果：容器 cpu_usage 长期低于 20%，且无节流
→ 可以降低 cpu_quota 节省资源