ジョブのログ

GitLab 12.5でジョブトレースからジョブログに名称変更。

ジョブログは GitLab Runner がジョブを処理している間に送信されます。 ジョブページ、パイプライン、メール通知などでログを見ることができます。

データフロー

一般的に、ジョブログには2つの状態があります。log とarchived logです。以下の表で、ログが通過する段階を見ることができます：

フェーズ State 状態 データフロー 保存パス
1: パッチング ログ ジョブ実行中 GitLab Runner => Puma => ファイルストレージ #{ROOT_PATH}/gitlab-ci/builds/#{YYYY_mm}/#{project_id}/#{job_id}.log
2: 上書き ログ ジョブ終了時 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となります。

ジョブログのローカルロケーションの変更

ジョブログの保存場所を変更するには、以下の手順に従ってください。

オムニバスのインストールで：

  1. /etc/gitlab/gitlab.rb を編集し、以下の行を追加または修正してください： 

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

  2. ファイルを保存し、変更を有効にするために GitLab を再設定します。

ソースからのインストールで：

  1. /home/git/gitlab/config/gitlab.yml を編集し、以下の行を追加または修正してください： 

    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を再起動して変更を有効にします。

オブジェクトストレージへのログのアップロード

アーカイブされたログはジョブのアーティファクトとみなされるため、オブジェクトストレージのインテグレーションを設定すると、ジョブのログは他のジョブのアーティファクトと一緒に自動的にオブジェクトストレージに移行されます。

プロセスについては、データフローの「フェーズ4：アップロード」をご覧ください。

ジョブログの削除方法

古いジョブログを自動的に期限切れにする方法はありませんが、容量を取りすぎている場合は削除するのが安全です。 手動でログを削除した場合、UIのジョブ出力は空になります。

例えば、60日以上前のジョブログをすべて削除するには、GitLabインスタンスのshellから以下を実行します：

警告：このコマンドはログファイルを永久に削除し、元に戻すことはできません。
find /var/opt/gitlab/gitlab-rails/shared/artifacts -name "job.log" -mtime +60 -delete

新しいインクリメンタルロギングアーキテクチャ

注：この機能はデフォルトではオフになっています。有効または無効にする方法については、以下を参照してください。

オブジェクトストレージの設定と処理を組み合わせることで、ローカルのファイルストレージを完全にバイパスすることができます。 これは、GitLabがKubernetes上などでクラウドネイティブとしてインストールされている場合に便利なオプションです。

データフローはデータフローのセクションで説明したものと同じですが、1つだけ変更点があります。 このインクリメンタルログアーキテクチャでは_、_ファイルストレージの代わりに、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ワーカーはログをオブジェクトストレージにアーカイブし、Redisと永続ストア（オブジェクトストレージまたはデータベース）でログをクリーンアップします。

インクリメンタルロギングの有効化

以下のコマンドは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')
注：移行期間は優雅に処理されます。 今後のログはレガシーアーキテクチャで生成され、進行中のインクリメンタルログはインクリメンタルアーキテクチャのままです。

潜在的な影響

場合によっては、Redisにデータを保存することでデータ損失が発生する可能性があります：

  1. ケース1：Redisの全データが誤ってフラッシュされた場合
    • 進行中のインクリメンタルログは、ログを再送信することで回復することができます（これはGitLab Runnerのすべてのバージョンでサポートされています）。
    • インクリメンタルログをアーカイブしていない終了したジョブは、ログデータの最後の部分（~128KB）を失います。
  2. ケース2：Sidekiqワーカーがアーカイブに失敗した場合（アーカイブ処理ができないバグがあった、Sidekiqの不整合など
    • 現在、Redisのログデータは1週間後にすべて削除されます。 期限までにSidekiqワーカーが終了できない場合、ログデータの一部が失われます。

もう1つ発生する可能性のあるイシューは、Redisインスタンスのメモリをすべて消費してしまうことです。 ジョブ数が1000の場合、128MB（128KB * 1000）が消費されます。

また、データベースのレプリケーションラグを圧迫する可能性もあります。INSERTsはログチャンクがあることを示すために生成されます。UPDATEsは128KBのデータで、複数のチャンクを受信すると発行されます。