gitlab ci 不直接暴露流水线资源消耗数据，需通过 runner 进程监控、宿主机指标关联、prometheus 指标联动及 job 内埋点四层手段综合分析资源使用情况。
GitLab CI 本身不直接暴露流水线运行时的 CPU、内存等底层资源消耗数据，因为 Job 是在 Runner 所在宿主机或容器中执行的，GitLab Server 并不感知具体资源使用细节。但你可以通过分层组合监控手段，从 Runner 层、宿主机层、CI 指标层三个维度还原流水线的资源消耗情况。
Runner 进程级资源监控
Runner 是执行 Job 的实际载体，它自身进程（gitlab-runner）和所启动的 Job 进程（如 docker run、bash、java 等）会占用系统资源。
- 查看 Runner 主进程资源：
ps -o pid,ppid,cmd,%cpu,%mem -C gitlab-runner
- 查看当前正在运行的 Job 对应进程（按父进程 PID 追踪）：
pstree -p $(pgrep -f 'gitlab-runner') | grep -E "(docker|bash|sh|python|java)"
- 结合
htop或top -p动态观察：top -p $(pgrep -f 'gitlab-runner' | xargs | sed 's/ /,/g')
⚠️ 注意：若 Runner 使用 Docker executor，Job 实际运行在独立容器内，需额外进入容器或用
docker stats查看。
宿主机资源与 Job 执行上下文关联
Debian 系统上可将「某段时间内活跃的 Job」与「系统资源峰值」做时间对齐分析：
- 提取最近失败或耗时长的流水线时间范围（从 GitLab Web 页面或 API 获取
started_at/finished_at） - 在对应时间段内回溯系统指标：
-
vmstat 1或sar -u -r 1（需提前启用sysstat） -
iostat -x 1观察磁盘等待（尤其当 Job 含大量文件操作或缓存拉取） -
journalctl -u gitlab-runner --since "2026-07-06 21:30:00" --until "2026-07-06 21:35:00"查看 Runner 日志中的资源警告（如fork: Cannot allocate memory）
-
Prometheus + gitlab-ci-pipelines-exporter + Runner 内置指标
这是最实用的生产级方案，把「逻辑耗时」和「隐含资源压力」间接挂钩：
- 启用 Runner 的 Prometheus 指标端口（修改
config.toml）：[metrics] prometheus_listen_addr = "localhost:9252"
- 部署
gitlab-ci-pipelines-exporter，它会拉取 GitLab API 中的流水线/Job 元数据，并暴露gitlab_ci_job_duration_seconds、gitlab_ci_pipeline_status等指标 - 在 Grafana 中建立关联视图：
- 左侧面板：
gitlab_ci_job_duration_seconds{job="build"}P95 耗时趋势 - 右侧面板：
node_memory_MemAvailable_bytes或node_load1同时段曲线 - 若两者出现强相关性（如某 Job 耗时突增时，宿主机 load1 同步飙升），即可判断该 Job 存在资源争抢
- 左侧面板：
✅ 关键逻辑：虽然 GitLab 不上报“Job 占用 2.3GB 内存”，但当你发现
ci_job_duration_seconds > 300s且node_load1 > 16（8核机器），基本可定位为资源瓶颈；再结合docker stats或cgroup数据即可确认。
补充：对关键 Job 主动埋点（适用高要求场景）
若某个 Job 承载核心构建或测试，可在 .gitlab-ci.yml 中加入轻量采集：
build-job:
script:
- free -h && echo "---"
- ps aux --sort=-%mem | head -n 5 && echo "---"
- time your-build-command
或使用 cgroups 工具（需 Runner 宿主机支持）：
# 在 Job 内执行（仅限 systemd-executor 或 privileged docker） cat /sys/fs/cgroup/memory/memory.usage_in_bytes
不复杂但容易忽略
