🟡 容器层：盒子视角

💡 一句话理解

把每个服务想成一个行李箱：箱子大小是限额（cgroup 圈出来的），行李是 working_set（真正摊在地板上、想扔也扔不掉的那部分内存）。内核是个不讲情面的站务员——行李顶到箱子口，直接把整个箱子扔下车（OOM kill，SIGKILL），不打招呼、不留遗言。这张盘干的事就三件：盯着每个箱子「装了多少 vs 箱子多大」「有没有被扔下车」「还在不在车上」。

先记住一个现状：这张盘依赖 cAdvisor（抄表员）采集容器指标，当前未部署，所以整盘暂时没数据——盘子没坏，是抄表员没上岗；部署后面板自动生效。

🧩 费曼拆解 讲给完全没接触过的小白

五个箱子、两节车厢。四两的全部家当装在 5 个容器里：frontend（静态页面，1G）、backend（主服务，10G）、biz（业务后端，3G）、rag（检索，2G）、review（审阅，2G）。两台 4C 宿主机（车厢）各跑一套——所以任何一个服务都该有两份，坏一份还有一份。每个箱子的空间是 cgroup 圈死的：箱子有多大，行李就只能装多少，超了执行家法。

三个必须分清的口径。第一，「装了多少」只认 working_set（内核 OOM 的判定口径）——Linux 会把最近读过的文件缓存在内存里凑数，usage_bytes 把这些可回收的也算进去，所以虚高；working_set 是减掉「随时能扔的杂物」后的真占用。第二，「重启几次」不是数事件，是看启动时间戳在窗口内变了几次（changes(container_start_time_seconds[1h])）。第三，「被枪毙几次」看 container_oom_events_total，出现即排查。

点名器与挤占。k6 是点名器：两台机器各 1 个容器，每个 service 应该数出 2——1 黄（单机在撑，冗余没了）、0 红（服务整体不可用）。另外别忘了 CPU：两台机器各只有 4 个核，两个重容器合计超过 4 核就会互相挤占，触发 CPU 节流，接口延迟莫名其妙升高——查慢问题时先来这里排除，再去看代码。

🧠 必知必会 看懂本课全部面板的地基

cgroup 限额

容器 = 被 Linux 配额管家（cgroup）圈起来的进程：内存给你划多大、CPU 给你划几核，超线就执行家法（OOM kill / CPU 节流）。两台 4C 宿主机各跑一套 5 个盒子。

# 部署后每个 service 的限额（应数出 10G/3G/2G/2G/1G ×两台）
sum by (service) (container_spec_memory_limit_bytes)

working_set 口径

容器内存的「真占用」——内核 memcg 的 OOM 判定口径。usage_bytes 含可回收 page cache 会虚高，判「会不会被杀」只认 working_set。

# 实际装了多少 vs 箱子多大（k1 的两条线）
container_memory_working_set_bytes
  vs container_spec_memory_limit_bytes

memcg OOM

working_set 顶到限额，内核直接 SIGKILL——无法捕获、无法优雅退出，日志里往往什么都没来得及写。rag 被 LibreOffice 大文件 OOM 杀过（有前科），是头号盯防对象。

# OOM 实锤（出现即排查；cAdvisor 版本不支持时此指标无数据）
increase(container_oom_events_total[1h]) > 0

重启次数口径

重启次数 = 启动时间戳在窗口内变了几次（changes），不是数「重启事件」。发布引起的重启属预期，只看发布窗口外的重启。

# 1h 内重启几次（k5 左线）
changes(container_start_time_seconds[1h]) by (service)

点名器

两台机器各 1 个容器，每个 service 预期数出 2：2=全绿；1=单机在撑（冗余没了，黄）；0=服务整体不可用（红）。

# 各服务存活实例数（k6 口径）
count by (service) (container_start_time_seconds{service=~"siliang-.*"})

CPU 节流

两台宿主机各 4C：两个重容器合计 > 4 核 = 互相挤占 → CPU 节流 → 接口延迟莫名升高。查慢问题时先来这里排除，再去看代码。

# 每个容器用了几个核（user+system 速率求和，k3 口径）
sum by (service) (rate(container_cpu_user_seconds_total[5m])
  + rate(container_cpu_system_seconds_total[5m]))

cAdvisor 未部署

容器指标全靠 cAdvisor 采集；它没上岗，整盘没数据——是采集侧缺勤，不是仪表盘坏了。部署后建议给每台机器的 target 打 machine 标签再接入下钻。

# 验证：指标查不到 = 采集侧没上岗
# container_memory_working_set_bytes → 空结果

网络收发大头

容器网络流量的大头是外部搬运：COS 上传下载、LLM 流量、SSE 下行全在里面。它回答「盒子在跟外面搬多少货」，不是业务 QPS。

# 收（↓）+ 发（↑）字节速率（k4 口径）
rate(container_network_receive_bytes_total[5m])
  + rate(container_network_transmit_bytes_total[5m])

📋 逐面板精讲 7 张图一张不落（顺序 = 主图谱容器盘顺序）

# 4 条建议告警（口径卡原文）：
# 1. >90% 持续 5m   2. 重启   3. OOM   4. 实例 < 2

# 面板口径：实线 = 使用，虚线 = 限额
sum by (service) (container_memory_working_set_bytes)
sum by (service) (container_spec_memory_limit_bytes)

# 面板口径：除法算百分比，clamp_min 防除零
sum by (service) (container_memory_working_set_bytes)
  / clamp_min(sum by (service) (container_spec_memory_limit_bytes), 1)

# 面板口径：user + system 速率求和
sum by (service) (rate(container_cpu_user_seconds_total[5m])
  + rate(container_cpu_system_seconds_total[5m]))

# 面板口径：收 + 发字节速率，按 service 拆
rate(container_network_receive_bytes_total[5m])
  + rate(container_network_transmit_bytes_total[5m]) by (service)

# 面板口径：重启次数 + OOM 事件
changes(container_start_time_seconds[1h]) by (service)
increase(container_oom_events_total[1h]) by (service)

# 面板口径：按 service 点名
count by (service) (container_start_time_seconds{service=~"siliang-.*"})

🏭 生产实战 real world

# 第 1 步：谁被杀/重启了？（k5）
increase(container_oom_events_total[1h]) by (service)
changes(container_start_time_seconds[1h]) by (service)
  # oom > 0 = 实锤；发布窗口外的 changes > 0 = 计划外重启

# 第 2 步：是不是内存顶格？（k1/k2）
sum by (service) (container_memory_working_set_bytes)
  / clamp_min(sum by (service) (container_spec_memory_limit_bytes), 1)
  # > 0.9 = OOM 前最后窗口；顶格后回落 = 刚被杀过一轮

# 第 3 步：还剩几台在撑？（k6）
count by (service) (container_start_time_seconds{service=~"siliang-.*"})
  # 1 = 单机在撑（冗余没了）：先查另一台，别动好的这台

groups:
- name: siliang-containers # 口径卡 k0 的 4 条建议告警
  rules:
  - alert: ContainerMemNearLimit
    expr: sum by (service) (container_memory_working_set_bytes) / clamp_min(sum by (service) (container_spec_memory_limit_bytes), 1) > 0.9
    for: 5m        # >90% 持续 5m：OOM 前的最后窗口（k2）
  - alert: ContainerOomKilled
    expr: increase(container_oom_events_total[1h]) > 0
    for: 0m        # OOM 出现即排查（k5；指标不支持时此规则静默）
  - alert: ContainerAliveBelowTwo
    expr: count by (service) (container_start_time_seconds{service=~"siliang-.*"}) < 2
    for: 5m        # 点名器缺员：1=单机在撑，0=整体不可用（k6）
  # 第 4 条：计划外重启 = 发布窗口外 changes(container_start_time_seconds[1h]) > 0
  # 需要结合发布日历排除预期重启，按 k0 口径卡为准

# 1) 各容器用了几个核（k3）
sum by (service) (rate(container_cpu_user_seconds_total[5m])
  + rate(container_cpu_system_seconds_total[5m]))

# 2) 同机合计：同一台机器上所有 service 加总（按 machine 打标后）
sum by (machine) (rate(container_cpu_user_seconds_total[5m])
  + rate(container_cpu_system_seconds_total[5m]))
  # 合计逼近 4 = 灶眼占满，互相挤占 → 节流 → 延迟升高

# 1) 下行（发送）速率按 service 看：backend 的 SSE 在里面
rate(container_network_transmit_bytes_total[5m]) by (service)

# 2) 对照上行：是不是只有下行掉（推流断）还是全断（网络故障）
rate(container_network_receive_bytes_total[5m]) by (service)
  # 收发全掉 = 网络/机器问题；只有下行掉 = SSE 推流断了

# 1) 指标到货？
container_memory_working_set_bytes
  # 有系列 = 采集链路通了

# 2) 限额对表：五个盒子 × 两台 = 应数出 10G/3G/2G/2G/1G 各两份
sum by (service) (container_spec_memory_limit_bytes)

# 3) 点名齐员：每个 service 应该数出 2
count by (service) (container_start_time_seconds{service=~"siliang-.*"})
  # 全部 = 2 且 k1 虚线与限额表一致 → 验收通过

⚠️ 常见坑 pitfalls

# 错: # No data → 报障仪表盘（盘没坏，是没数据源）
# 对: # 对照 k0 口径卡 → cAdvisor 未部署属预期

# 错: container_memory_usage_bytes / limit       # → 虚高误报
# 对: container_memory_working_set_bytes / limit  # → OOM 判定口径

# 错: changes(container_start_time_seconds[1h]) > 0   # → 发布日必炸
# 对: # 排除发布窗口；窗口外重启才算计划外（k5 口径）

# 错: # 日志空白 → 「再翻翻」（找不到的，它没来得及写）
# 对: # increase(container_oom_events_total[1h]) > 0 = 实锤

# 错: working_set / limit                     # → 偶发 NaN
# 对: working_set / clamp_min(limit, 1)        # → 防除零（k2）

# 错: # 点名 1 → 重启幸存实例 → 0，服务整体不可用
# 对: # 点名 1 → 查另一台机器的容器为何没起来

# 错: # 只看单 service 的核数（谁都不到 4）
# 对: # sum by (machine)(...) 合计贴 4 = 挤占（k3）

# 错: # 网络字节数 ÷ 平均包大小 = 业务 QPS（口径错位）
# 对: # 搬货看 k4，业务量看 sum(rate(siliang_biz_http_requests_total[5m]))

🎓 费曼自测 合上书，能讲出来才算懂

🔗 相关课程