Job logs · Gitlab 中文文档

# Job logs > 原文：[https://docs.gitlab.com/ee/administration/job_logs.html](https://docs.gitlab.com/ee/administration/job_logs.html) * [Data flow](#data-flow) * [Changing the job logs local location](#changing-the-job-logs-local-location) * [Uploading logs to object storage](#uploading-logs-to-object-storage) * [How to remove job logs](#how-to-remove-job-logs) * [New incremental logging architecture](#new-incremental-logging-architecture) * [Enabling incremental logging](#enabling-incremental-logging) * [Potential implications](#potential-implications) # Job logs[](#job-logs "Permalink") > 在 GitLab 12.5 中[从作业跟踪重命名为作业日志](https://gitlab.com/gitlab-org/gitlab/-/issues/29121) . 作业日志由 GitLab Runner 在处理作业时发送. 您可以在作业页面，管道，电子邮件通知等中查看日志. ## Data flow[](#data-flow "Permalink") 通常，作业日志有两种状态： `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 将存档日志移至[对象存储](#uploading-logs-to-object-storage) （如果已配置） | `#{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[](#changing-the-job-logs-local-location "Permalink") 要更改作业日志的存储位置，请执行以下步骤. **在所有安装中；** 1. 编辑`/etc/gitlab/gitlab.rb`并添加或修改以下行： ``` gitlab_ci['builds_directory'] = '/mnt/to/gitlab-ci/builds' ``` 2. 保存文件并[重新配置 GitLab，](restart_gitlab.html#omnibus-gitlab-reconfigure)以使更改生效. **在源安装中：** 1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following lines: ``` gitlab_ci: # The location where build logs are stored (default: builds/). # Relative paths are relative to Rails.root. builds_path: path/to/builds/ ``` 2. 保存文件并[重新启动 GitLab，](restart_gitlab.html#installations-from-source)以使更改生效. ## Uploading logs to object storage[](#uploading-logs-to-object-storage "Permalink") 归档日志被视为[作业工件](job_artifacts.html) . 因此，当您[设置对象存储集成时](job_artifacts.html#object-storage-settings) ，作业日志将与其他作业工件一起自动迁移到[该对象](job_artifacts.html#object-storage-settings) . 请参阅[数据流中的](#data-flow) "阶段 4：上传"以了解该过程. ## How to remove job logs[](#how-to-remove-job-logs "Permalink") 没有办法自动使旧的作业日志过期，但是如果它们占用太多空间，可以安全地将其删除. 如果您手动删除日志，则 UI 中的作业输出将为空. 例如，要删除所有超过 60 天的作业日志，请在您的 GitLab 实例中的 Shell 中运行以下命令： **危险：**此命令将永久删除日志文件，并且是不可逆的. ``` find /var/opt/gitlab/gitlab-rails/shared/artifacts -name "job.log" -mtime +60 -delete ``` ## New incremental logging architecture[](#new-incremental-logging-architecture "Permalink") 版本历史 * 在 GitLab 10.4 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/18169) . * [公布为一般可](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/46097)在 GitLab 11.0\. **注意：**此功能默认为关闭. 有关如何[启用或禁用](#enabling-incremental-logging)它的信息，请参见下文. 通过将过程与对象存储设置相结合，我们可以完全绕过本地文件存储. 如果将 GitLab 安装为云原生，例如在 Kubernetes 上，这是一个有用的选项. 数据流与[数据流部分中](#data-flow)描述的相同，只是有所变化： *前两个阶段的存储路径不同* . 这种增量日志架构将日志块存储在 Redis 中，并将其存储在持久性存储（对象存储或数据库）中，而不是文件存储中. Redis 用作一流的存储，它最多可存储 128KB 数据. 一旦发送了完整的块，就将其刷新到持久性存储（对象存储（临时目录）或数据库）. 一段时间后，Redis 和持久性存储中的数据将被归档到[对象存储](#uploading-logs-to-object-storage) . 数据存储在以下 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[](#enabling-incremental-logging "Permalink") 在 Rails 控制台中将发出以下命令： ``` # Omnibus GitLab gitlab-rails console # Installation from source cd /home/git/gitlab sudo -u git -H bin/rails console -e production ``` **要检查是否启用了增量日志记录（跟踪）：** ``` Feature.enabled?(:ci_enable_live_trace) ``` **要启用增量日志记录（跟踪）：** ``` Feature.enable(:ci_enable_live_trace) ``` **注意：**过渡期将得到适当处理. 即将到来的日志将使用增量体系结构生成，而正在进行的日志将保留在旧体系结构中，这意味着将不会使用增量体系结构强制重新生成正在进行的日志. **要禁用增量日志记录（跟踪）：** ``` Feature.disable('ci_enable_live_trace') ``` **注意：**过渡期将得到适当处理. 即将发生的日志将使用旧体系结构生成，而持续的增量日志将保留在增量体系结构中，这意味着持续的增量日志将不会用旧体系结构强制重新生成. ### Potential implications[](#potential-implications "Permalink") 在某些情况下，将数据存储在 Redis 上可能会导致数据丢失： 1. **情况 1：Redis 中的所有数据被意外刷新** * 可以通过重新发送日志来恢复增量日志（所有版本的 GitLab Runner 均支持此功能）. * 未归档增量日志的已完成作业将丢失日志数据的最后一部分（〜128KB）. 2. **情况 2：当 Sidekiq 工作人员无法归档时（例如，存在一个阻止归档过程，Sidekiq 不一致等的错误）** * 当前，Redis 中的所有日志数据将在一周后删除. 如果 Sidekiq 工作人员无法在到期日之前完成操作，则部分日志数据将丢失. 可能出现的另一个问题是，它可能会消耗 Redis 实例上的所有内存. 如果作业数为 1000，则将消耗 128MB（128KB * 1000）. 而且，它可能会给数据库复制带来压力. 生成`INSERT`以表明我们有日志块. 一旦我们收到多个数据块，便发出具有 128KB 数据的`UPDATE` .