Job logs

原文：https://docs.gitlab.com/ee/administration/job_logs.html

Job logs

在 GitLab 12.5 中从作业跟踪重命名为作业日志 .

作业日志由 GitLab Runner 在处理作业时发送. 您可以在作业页面，管道，电子邮件通知等中查看日志.

Data flow

通常，作业日志有两种状态： log和archived log . 在下表中，您可以看到日志经过的阶段：

Phase State Condition 数据流 储存路径
1：打补丁 log 作业运行时 GitLab Runner => Puma =>文件存储 #{ROOT_PATH}/gitlab-ci/builds/#{YYYY_mm}/#{project_id}/#{job_id}.log
2：覆盖 log 工作完成后 GitLab Runner => Puma =>文件存储 #{ROOT_PATH}/gitlab-ci/builds/#{YYYY_mm}/#{project_id}/#{job_id}.log
3：归档 存档日志 工作完成后 Sidekiq 将日志移至工件文件夹 #{ROOT_PATH}/gitlab-rails/shared/artifacts/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log
4：上传 存档日志 归档日志后 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 .

Changing the job logs local location

要更改作业日志的存储位置，请执行以下步骤.

在所有安装中；

  1. 编辑/etc/gitlab/gitlab.rb并添加或修改以下行：

    1. gitlab_ci['builds_directory'] = '/mnt/to/gitlab-ci/builds'

  2. 保存文件并重新配置 GitLab，以使更改生效.

在源安装中：

  1. Edit /home/git/gitlab/config/gitlab.yml and add or amend the following lines:

    1. gitlab_ci:
    2.   # The location where build logs are stored (default: builds/).
    3.   # Relative paths are relative to Rails.root.
    4.   builds_path: path/to/builds/

  2. 保存文件并重新启动 GitLab，以使更改生效.

Uploading logs to object storage

归档日志被视为作业工件 . 因此，当您设置对象存储集成时 ，作业日志将与其他作业工件一起自动迁移到该对象 .

请参阅数据流中的 “阶段 4：上传”以了解该过程.

How to remove job logs

没有办法自动使旧的作业日志过期，但是如果它们占用太多空间，可以安全地将其删除. 如果您手动删除日志，则 UI 中的作业输出将为空.

例如，要删除所有超过 60 天的作业日志，请在您的 GitLab 实例中的 Shell 中运行以下命令：

危险：此命令将永久删除日志文件，并且是不可逆的.

  1. find /var/opt/gitlab/gitlab-rails/shared/artifacts -name "job.log" -mtime +60 -delete

New incremental logging architecture

版本历史

注意：此功能默认为关闭. 有关如何启用或禁用它的信息，请参见下文.

通过将过程与对象存储设置相结合，我们可以完全绕过本地文件存储. 如果将 GitLab 安装为云原生，例如在 Kubernetes 上，这是一个有用的选项.

数据流与数据流部分中描述的相同，只是有所变化： 前两个阶段的存储路径不同 . 这种增量日志架构将日志块存储在 Redis 中，并将其存储在持久性存储（对象存储或数据库）中，而不是文件存储中. Redis 用作一流的存储，它最多可存储 128KB 数据. 一旦发送了完整的块，就将其刷新到持久性存储（对象存储（临时目录）或数据库）. 一段时间后，Redis 和持久性存储中的数据将被归档到对象存储 .

数据存储在以下 Redis 命名空间中： Gitlab::Redis::SharedState .

这是详细的数据流：

  1. GitLab Runner 从 GitLab 选择工作
  2. GitLab Runner 向 GitLab 发送一条日志
  3. GitLab 将数据追加到 Redis
  4. 一旦 Redis 中的数据达到 128KB，就将数据刷新到持久性存储（对象存储或数据库）.
  5. 重复上述步骤，直到作业完成.
  6. 作业完成后，GitLab 会安排 Sidekiq 工作人员存档日志.
  7. Sidekiq worker 将日志归档到对象存储，并在 Redis 和永久存储（对象存储或数据库）中清除日志.

Enabling incremental logging

在 Rails 控制台中将发出以下命令：

  1. # Omnibus GitLab
  2. gitlab-rails console
  4. # Installation from source
  5. cd /home/git/gitlab
  6. sudo -u git -H bin/rails console -e production

要检查是否启用了增量日志记录（跟踪）：

  1. Feature.enabled?(:ci_enable_live_trace)

要启用增量日志记录（跟踪）：

  1. Feature.enable(:ci_enable_live_trace)

注意：过渡期将得到适当处理. 即将到来的日志将使用增量体系结构生成，而正在进行的日志将保留在旧体系结构中，这意味着将不会使用增量体系结构强制重新生成正在进行的日志.

要禁用增量日志记录（跟踪）：

  1. Feature.disable('ci_enable_live_trace')

注意：过渡期将得到适当处理. 即将发生的日志将使用旧体系结构生成，而持续的增量日志将保留在增量体系结构中，这意味着持续的增量日志将不会用旧体系结构强制重新生成.

Potential implications

在某些情况下，将数据存储在 Redis 上可能会导致数据丢失：

  1. 情况 1：Redis 中的所有数据被意外刷新
    • 可以通过重新发送日志来恢复增量日志（所有版本的 GitLab Runner 均支持此功能）.
    • 未归档增量日志的已完成作业将丢失日志数据的最后一部分（〜128KB）.
  2. 情况 2：当 Sidekiq 工作人员无法归档时（例如，存在一个阻止归档过程，Sidekiq 不一致等的错误）
    • 当前，Redis 中的所有日志数据将在一周后删除. 如果 Sidekiq 工作人员无法在到期日之前完成操作，则部分日志数据将丢失.

可能出现的另一个问题是，它可能会消耗 Redis 实例上的所有内存. 如果作业数为 1000，则将消耗 128MB（128KB * 1000）.

而且，它可能会给数据库复制带来压力. 生成INSERT以表明我们有日志块. 一旦我们收到多个数据块，便发出具有 128KB 数据的UPDATE .