# 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` .