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