作业日志
- Tier: Free, Premium, Ultimate
- Offering: GitLab Self-Managed
作业日志由 Runner 在处理作业时发送。您可以在作业页面、流水线和邮件通知等地方查看日志。
数据流
通常,作业日志有两种状态:log(日志)和 archived log(已归档日志)。在下表中,您可以看到日志经历的各个阶段:
| 阶段 | 状态 | 条件 | 数据流 | 存储路径 |
|---|---|---|---|---|
| 1: 修补中 | log | 当作业正在运行时 | Runner => Puma => 文件存储 | #{ROOT_PATH}/gitlab-ci/builds/#{YYYY_mm}/#{project_id}/#{job_id}.log |
| 2: 归档中 | archived log | 作业完成后 | Sidekiq 将日志移动到产物文件夹 | #{ROOT_PATH}/gitlab-rails/shared/artifacts/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log |
| 3: 上传中 | archived log | 日志归档后 | Sidekiq 将已归档日志移动到 对象存储(如果已配置) | #{bucket_name}/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log |
ROOT_PATH 因环境而异:
- 对于 Linux 包,路径为
/var/opt/gitlab。 - 对于自行编译安装,路径为
/home/git/gitlab。
更改作业日志的本地位置
对于 Docker 安装,您可以更改数据挂载的路径。 对于 Helm chart,请使用对象存储。
要更改作业日志的存储位置:
-
可选。如果您有现有的作业日志,请通过临时停止 Sidekiq 来暂停持续集成数据处理:
sudo gitlab-ctl stop sidekiq -
在
/etc/gitlab/gitlab.rb中设置新的存储位置:gitlab_ci['builds_directory'] = '/mnt/gitlab-ci/builds' -
保存文件并重新配置 GitLab:
sudo gitlab-ctl reconfigure -
使用
rsync将作业日志从当前位置移动到新位置:sudo rsync -avzh --remove-source-files --ignore-existing --progress /var/opt/gitlab/gitlab-ci/builds/ /mnt/gitlab-ci/builds/使用
--ignore-existing以避免用同一日志的旧版本覆盖新的作业日志。 -
如果您选择暂停持续集成数据处理,现在可以再次启动 Sidekiq:
sudo gitlab-ctl start sidekiq -
删除旧的作业日志存储位置:
sudo rm -rf /var/opt/gitlab/gitlab-ci/builds
-
可选。如果您有现有的作业日志,请通过临时停止 Sidekiq 来暂停持续集成数据处理:
# For systems running systemd sudo systemctl stop gitlab-sidekiq # For systems running SysV init sudo service gitlab stop -
编辑
/home/git/gitlab/config/gitlab.yml以设置新的存储位置:production: &base gitlab_ci: builds_path: /mnt/gitlab-ci/builds -
保存文件并重启 GitLab:
# For systems running systemd sudo systemctl restart gitlab.target # For systems running SysV init sudo service gitlab restart -
使用
rsync将作业日志从当前位置移动到新位置:sudo rsync -avzh --remove-source-files --ignore-existing --progress /home/git/gitlab/builds/ /mnt/gitlab-ci/builds/使用
--ignore-existing以避免用同一日志的旧版本覆盖新的作业日志。 -
如果您选择暂停持续集成数据处理,现在可以再次启动 Sidekiq:
# For systems running systemd sudo systemctl start gitlab-sidekiq # For systems running SysV init sudo service gitlab start -
删除旧的作业日志存储位置:
sudo rm -rf /home/git/gitlab/builds
将日志上传到对象存储
已归档的日志被视为 作业产物。因此,当您 设置对象存储集成 时,作业日志会与其他作业产物一起自动迁移到对象存储。
要了解该过程,请参阅 数据流 中的“阶段 3:上传中”。
最大日志文件大小
GitLab 中作业日志文件大小的默认限制为 100 兆字节。任何超过此限制的作业都将被标记为失败,并被 Runner 丢弃。更多详情请参阅 作业日志的最大文件大小。
防止本地磁盘使用
如果您想避免作业日志占用任何本地磁盘空间,可以使用以下选项之一:
如何移除作业日志
目前没有自动过期旧作业日志的方法。但是,如果它们占用了过多空间,可以安全地将其移除。如果您手动移除日志,UI 中的作业输出将为空。
有关如何使用 GitLab CLI 删除作业日志的详细信息,请参阅 删除作业日志。
或者,您也可以使用 shell 命令删除作业日志。例如,要删除所有超过 60 天的作业日志,请在您的 GitLab 实例的 shell 中运行以下命令。
对于 Helm chart,请使用您的对象存储附带的管理工具。
以下命令将永久删除日志文件,且此操作不可逆。
find /var/opt/gitlab/gitlab-rails/shared/artifacts -name "job.log" -mtime +60 -delete假设您已将 /var/opt/gitlab 挂载到 /srv/gitlab:
find /srv/gitlab/gitlab-rails/shared/artifacts -name "job.log" -mtime +60 -deletefind /home/git/gitlab/shared/artifacts -name "job.log" -mtime +60 -delete删除日志后,您可以通过运行检查 上传文件完整性 的 Rake 任务来查找任何损坏的文件引用。更多信息请参阅如何 删除对缺失产物的引用。
增量日志
增量日志改变了作业日志的处理和存储方式,从而提高了扩展部署的性能。
默认情况下,GitLab Runner 将作业日志分块发送,并临时缓存在磁盘上。作业完成后,一个后台作业会将日志归档到产物目录,如果配置了对象存储,则会归档到对象存储。
使用增量日志时,日志将存储在 Redis 和一个持久化存储中,而不是文件存储中。这种方法:
- 防止作业日志占用本地磁盘空间。
- 消除了 Rails 和 Sidekiq 服务器之间对 NFS 共享的需求。
- 提高了多节点安装的性能。
增量日志过程使用 Redis 作为临时存储,并遵循以下流程:
- Runner 从 GitLab 获取一个作业。
- Runner 将一部分日志发送到 GitLab。
- GitLab 将数据追加到 Redis 的
Gitlab::Redis::TraceChunks命名空间中。 - 当 Redis 中的数据达到 128 KB 时,数据将被刷新到持久化存储。
- 重复上述步骤,直到作业完成。
- 作业完成后,GitLab 会调度一个 Sidekiq worker 来归档日志。
- Sidekiq worker 将日志归档到对象存储,并清理临时数据。
增量日志不支持 Redis Cluster。 更多信息请参阅 issue 224171。
配置增量日志
在开启增量日志之前,您必须为 CI/CD 产物、日志和构建 配置对象存储。开启增量日志后,文件将无法写入磁盘,并且没有针对错误配置的保护措施。
当您开启增量日志时,正在运行的作业的日志会继续写入磁盘,但新的作业将使用增量日志。
当您关闭增量日志时,正在运行的作业会继续使用增量日志,但新的作业将写入磁盘。
要配置增量日志: