Job logs

Job logs

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

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

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

ROOT_PATH因环境而异. 对于 Omnibus GitLab，它将是/var/opt/gitlab ；对于从源代码进行的安装，它将是 .

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

在所有安装中；

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

  2. 保存文件并以使更改生效.

在源安装中：

    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，以使更改生效.

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

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

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

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

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

版本历史

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

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

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

这是详细的数据流：

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

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

  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.enable(:ci_enable_live_trace)

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

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

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

Potential implications

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

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

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