作业日志
作业日志由 runner 在处理作业时发送。您可以在作业页面、流水线、电子邮件通知等中查看日志。
数据流
一般来说,作业日志有两种状态:log
和 archived log
。
在下表中,您可以看到日志经历的阶段:
阶段 | 状态 | 环境 | 数据流 | 存储路径 |
---|---|---|---|---|
1: patching | log | 作业运行时 | Runner => Puma => 文件存储 | #{ROOT_PATH}/gitlab-ci/builds/#{YYYY_mm}/#{project_id}/#{job_id}.log
|
2: archiving | archived log | 作业已完成 | Sidekiq 将日志移动到产物文件夹 | #{ROOT_PATH}/gitlab-rails/shared/artifacts/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log
|
3: uploading | archived log | 日志已归档 | Sidekiq 将归档日志移动到对象存储(如果已配置) | #{bucket_name}/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log
|
ROOT_PATH
因环境而异。 对于 Omnibus GitLab,为 /var/opt/gitlab
,对于从源代码安装,为 /home/git/gitlab
。
更改作业日志本地位置
要更改作业日志的存储位置,请按照以下步骤操作。
Omnibus 安装实例:
-
编辑
/etc/gitlab/gitlab.rb
并添加或修改以下行:gitlab_ci['builds_directory'] = '/mnt/to/gitlab-ci/builds'
-
保存文件并重新配置极狐GitLab,使更改生效。
或者,如果您有现有的作业日志,您可以按照以下步骤将日志移动到新位置,而不会丢失任何数据。
-
通过更新
/etc/gitlab/gitlab.rb
中的此设置来暂停持续集成数据处理。根据数据流的工作方式,正在进行的作业不受影响。sidekiq['queue_selector'] = true sidekiq['queue_groups'] = [ "feature_category!=continuous_integration" ]
- 保存文件并重新配置极狐GitLab,使更改生效。
-
在
/etc/gitlab/gitlab.rb
中设置新的存储位置:gitlab_ci['builds_directory'] = '/mnt/to/gitlab-ci/builds'
- 保存文件并重新配置极狐GitLab,使更改生效。
-
使用
rsync
将作业日志从当前位置移动到新位置:sudo rsync -avzh --remove-source-files --ignore-existing --progress /var/opt/gitlab/gitlab-ci/builds/ /mnt/to/gitlab-ci/builds`
使用
--ignore-existing
这样就不会用旧版本的相同日志覆盖新的作业日志。 - 通过编辑
/etc/gitlab/gitlab.rb
并删除您之前更新的sidekiq
设置来恢复持续集成数据处理。 - 保存文件并重新配置极狐GitLab,使更改生效。
-
删除旧的作业日志存储位置:
sudo rm -rf /var/opt/gitlab/gitlab-ci/builds`
源安装实例:
-
编辑
/home/git/gitlab/config/gitlab.yml
并添加或修改以下几行:gitlab_ci: # The location where build logs are stored (default: builds/). # Relative paths are relative to Rails.root. builds_path: path/to/builds/
-
保存文件并重启极狐GitLab,使更改生效。
将日志上传到对象存储
归档日志被视为作业产物。 因此,当您设置对象存储集成时,作业日志会与其他作业产物一起自动迁移到其上。
查看数据流中的 “Phase 3: uploading” 了解流程。
防止使用本地磁盘
如果要避免作业日志使用任何本地磁盘,可以使用以下选项之一:
如何删除作业日志
没有办法让旧的作业日志自动过期,但如果它们占用太多空间,可以安全地删除它们。如果手动删除日志,则 UI 中的作业输出为空。
例如,要删除超过 60 天的所有作业日志,请从 GitLab 实例中的 shell 运行以下命令:
find /var/opt/gitlab/gitlab-rails/shared/artifacts -name "job.log" -mtime +60 -delete
sudo gitlab-rake gitlab:artifacts:check
时可以报告损坏的文件引用。
获取更多信息,查看删除对缺失产物的引用。增量日志架构
- 部署在功能标志后默认禁用。
- 推荐生产使用于 13.6 版本。
- 推荐与 AWS S3 生产使用于 13.7 版本。
默认情况下,作业日志以块的形式从 GitLab Runner 发送,并由 Omnibus GitLab 临时缓存在 /var/opt/gitlab/gitlab-ci/builds
中的磁盘上。作业完成后,后台作业会归档作业日志。日志默认移动到 /var/opt/gitlab/gitlab-rails/shared/artifacts/
,或者已配置的对象存储上。
在一个横向扩展架构中,Rails 和 Sidekiq 运行在多个服务器上,文件系统上的这两个位置必须使用 NFS 共享。
要消除这两个文件系统要求:
技术细节
数据流与数据流部分中描述的相同,有一个变化:前两个阶段的存储路径不同。这种增量日志架构将日志块存储在 Redis 和持久存储(对象存储或数据库)中,而不是文件存储中。Redis 用作一流的存储,它可以存储高达 128KB 的数据。发送完整块后,将其刷新到持久存储,对象存储(临时目录)或数据库。 过了一会儿,Redis 中的数据和一个持久化存储被归档到对象存储。
数据存储在以下 Redis 命名空间中:Gitlab::Redis::TraceChunks
。
下面是详细的数据流:
- Runner 从极狐GitLab 中挑选一个作业
- Runner 向极狐GitLab 发送一条日志
- 极狐GitLab 将数据追加到 Redis
- Redis 中的数据达到128KB 后,将数据刷新到持久化存储(对象存储或数据库)中。
- 重复以上步骤,直到作业完成。
- 作业完成后,极狐GitLab 会安排一个 Sidekiq worker 来归档日志。
- Sidekiq worker 将日志归档到对象存储并清理 Redis 和持久存储(对象存储或数据库)中的日志。
限制
- 不支持 Redis 集群
- 在启用功能标志之前,您必须配置 CI/CD 产物、日志和构建的对象存储。启用该标志后,将无法将文件写入磁盘,并且无法防止配置错误。
- 有一个史诗跟踪其他潜在的限制和改进
启用或禁用增量日志
可以访问 GitLab Rails 控制台的 GitLab 管理员可以启用它。
在启用功能标志之前:
- 查看增量日志记录的局限性。
- 启用对象存储。
要启用增量日志记录:
Feature.enable(:ci_enable_live_trace)
运行作业的日志会继续写入磁盘,但新作业使用增量日志记录。
要禁用增量日志记录:
Feature.disable(:ci_enable_live_trace)
正在运行的作业继续使用增量日志记录,但新作业会写入磁盘。