容器资源监控核心是稳定低开销采集cpu、内存、网络、磁盘io指标，结合业务上下文做趋势分析与分角色报表输出。
容器运行态资源占用趋势分析与监控报表生成，核心在于持续采集指标、识别异常模式、按需聚合展示。重点不是堆砌数据，而是让 CPU、内存、网络、磁盘 IO 的变化可读、可比、可追溯。
关键指标采集要稳定且低开销
容器层面推荐直接使用 cgroup v2 接口或 cadvisor（集成在 kubelet 中）获取原始数据，避免在容器内额外部署 agent。采集频率建议设为 15–30 秒，高频（如 1 秒）易引发指标抖动和存储压力；低频（如 5 分钟）则可能漏掉短时峰值。重点关注：
- CPU：
cpuacct.usage（纳秒级累计值），计算每秒平均使用率（需差值除以采样间隔） - 内存：
memory.usage_in_bytes和memory.limit_in_bytes，用于计算实际使用率；同时关注memory.stat中的pgmajfault（大页缺页）和oom_kill计数 - 网络：基于
/sys/fs/cgroup/net_cls/或容器运行时暴露的接口，取rx_bytes/tx_bytes差值，避免仅看速率忽略突发流量 - 磁盘 IO：优先用
io.stat（cgroup v2）而非传统 iostat，能精确归属到容器，包含读写 IOPS 和吞吐量
趋势分析需结合时间维度与业务上下文
单纯画线图意义有限。应将资源曲线与以下信息对齐：
- 部署事件：自动标记 Helm Release、Deployment rollout 时间点，观察资源是否阶梯式上升或突变
- 流量特征：叠加 Prometheus 中的 HTTP QPS、延迟 P95、任务队列长度等业务指标，判断高 CPU 是否对应请求洪峰
- 周期规律：对定时任务类容器（如 cronjob），启用按小时/天粒度的同比环比（如“本周三 14:00 vs 上周三同一时刻”），识别固有波动
- 基线建模：用滑动窗口（如最近 7 天）计算内存使用中位数 + 2 倍 MAD（绝对中位差），比固定阈值更能适应渐进式内存增长
监控报表要分角色、分粒度输出
一份报表难以满足所有需求。建议按使用方生成不同视图：
- 运维值班视图：Top 5 高 CPU/内存容器列表 + 过去 1 小时趋势折线图 + OOM 事件摘要，支持一键跳转至 Pod 日志
- 开发自检视图：单个 Deployment 下各 Pod 的资源热力图（横轴时间、纵轴 Pod 名、色块深浅表示内存使用率），附带启动后前 5 分钟的初始化资源毛刺标记
- 容量规划视图：按命名空间统计 30 天内存/ CPU 使用率 P90，并叠加 request/limit 设置，标出 “request
- 日报邮件：只含 3 项核心指标（最高内存使用率容器、最长 CPU 毛刺持续时间、当日 OOM 总次数），附带趋势简评（如“内存使用率均值下降 8%，与昨日版本回滚一致”）
自动化报表生成建议用轻量栈
不依赖重型 BI 工具也能高效产出。推荐组合：
- 数据源：Prometheus（采集+存储） + Loki（日志关联）
- 查询与计算：PromQL 聚合（如
rate(container_cpu_usage_seconds_total[1h])）、Grafana 变量实现多维下钻 - 报表渲染：用 Grafana 自带的 Scheduled Reports（v9.4+）导出 PDF；或用 Python +
plotly+requests调用 Prometheus API 定制 HTML 报表，通过邮件或企业 IM 推送 - 异常标注：在报表脚本中嵌入简单规则（如连续 5 个点 >90% 内存使用率），自动加红框并附简要原因建议（“建议检查是否存在内存泄漏或缓存未驱逐”）
