ジョブログ

ジョブログはジョブの処理中に Runner から送信されます。ジョブページ、パイプライン、Eメール通知などでログを見ることができます。

データフロー

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

フェーズ	State	条件	データフロー	ストアドパス
1: パッチング	ログ	ジョブ実行中	Runner => Puma => ファイルストレージ	`#{ROOT_PATH}/gitlab-ci/builds/#{YYYY_mm}/#{project_id}/#{job_id}.log`
2: アーカイブ	アーカイブログ	ジョブ終了後	Sidekiqはログをアーティファクトフォルダに移動します。	`#{ROOT_PATH}/gitlab-rails/shared/artifacts/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log`
3: アップロード	アーカイブログ	ログがアーカイブされた後	Sidekiqはアーカイブされたログをオブジェクトストレージに移動します (設定されている場合)	`#{bucket_name}/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log`

ROOT_PATH は環境ごとに異なります：

Linux パッケージの場合は/var/opt/gitlab です。
セルフコンパイルインストールの場合は/home/git/gitlab 。

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

Dockerインストールでは、データがマウントされるパスを変更できます。Helmチャートの場合は、オブジェクトストレージを使用します。

ジョブログの保存場所を変更するには：

Linux package (Omnibus)

オプション。既存のジョブログがある場合は、Sidekiqを一時的に停止して継続的インテグレーションのデータ処理を一時停止します：
```
sudo gitlab-ctl stop sidekiq
```
/etc/gitlab/gitlab.rb に新しい保存場所を設定します：
```
gitlab_ci['builds_directory'] = '/mnt/gitlab-ci/builds'
```
ファイルを保存して GitLab を再設定してください：
```
sudo gitlab-ctl reconfigure
```
rsync を使って、ジョブログを現在の場所から新しい場所に移動します：
```
sudo rsync -avzh --remove-source-files --ignore-existing --progress /var/opt/gitlab/gitlab-ci/builds/ /mnt/gitlab-ci/builds/
```
同じログの古いバージョンで新しいジョブログを上書きしないように、--ignore-existing 。
継続的インテグレーションデータ処理の一時停止を選択した場合、Sidekiqを再度起動できます：
```
sudo gitlab-ctl start sidekiq
```
古いジョブログの保存場所を削除します：
```
sudo rm -rf /var/opt/gitlab/gitlab-ci/builds
```

Self-compiled (source)

オプション。既存のジョブログがある場合は、Sidekiqを一時的に停止して継続的インテグレーションのデータ処理を一時停止します：
```
# For systems running systemd
sudo systemctl stop gitlab-sidekiq
   
# For systems running SysV init
sudo service gitlab stop
```
/home/git/gitlab/config/gitlab.yml を編集して、新しい保存場所を設定します：
```
production: &base
  gitlab_ci:
    builds_path: /mnt/gitlab-ci/builds
```

ファイルを保存して GitLab を再起動します：

# For systems running systemd
sudo systemctl restart gitlab.target
   
# For systems running SysV init
sudo service gitlab restart

rsync を使って、ジョブログを現在の場所から新しい場所に移動します：
```
sudo rsync -avzh --remove-source-files --ignore-existing --progress /home/git/gitlab/builds/ /mnt/gitlab-ci/builds/
```
同じログの古いバージョンで新しいジョブログを上書きしないように、--ignore-existing 。

継続的インテグレーションデータ処理の一時停止を選択した場合、Sidekiqを再度起動できます：

# For systems running systemd
sudo systemctl start gitlab-sidekiq
   
# For systems running SysV init
sudo service gitlab start

古いジョブログの保存場所を削除します：
```
sudo rm -rf /home/git/gitlab/builds
```

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

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

このプロセスについては、データフローの「フェーズ3：アップロード」を参照してください。

ローカルディスクの使用防止

ジョブログのローカルディスクの使用を避けたい場合は、以下のいずれかのオプションを使用します：

インクリメンタルロギング機能を有効にします。
ジョブログの場所をNFSドライブに設定します。

ジョブログの削除方法

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

例えば、60日以上前のジョブログをすべて削除するには、GitLabインスタンスのShellから次のコマンドを実行します。

Helmチャートについては、オブジェクトストレージで提供されているストレージ管理ツールを使ってください。

次のコマンドはログファイルを永久に削除し、元に戻せません。

Linux package (Omnibus)

find /var/opt/gitlab/gitlab-rails/shared/artifacts -name "job.log" -mtime +60 -delete

Docker

/var/opt/gitlab を/srv/gitlabにマウントしたと仮定します：

find /srv/gitlab/gitlab-rails/shared/artifacts -name "job.log" -mtime +60 -delete

Self-compiled (source)

find /home/git/gitlab/shared/artifacts -name "job.log" -mtime +60 -delete

ログが削除された後、アップロードされたファイルのインテグレーションをチェックするRakeタスクを実行することで、壊れたファイル参照を見つけることができます。詳細については、見つからないアーティファクトへの参照を削除する方法を参照してください。

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

GitLab 10.8 でci_enable_live_traceというフラグで導入されました。デフォルトでは無効になっています。
GitLab13.6でGitLab.comが有効になりました。
GitLab 13.6で本番環境での使用を推奨。
GitLab 13.7 でのAWS S3での本番環境での使用を推奨します。
GitLabセルフマネージドインスタンスで使用するには、GitLab管理者に有効化するよう依頼してください。

デフォルトでは、ジョブログはGitLab Runnerからチャンクで送信され、一時的にディスクにキャッシュされます。ジョブが完了すると、バックグラウンドジョブがジョブログをアーカイブします。ログはデフォルトではアーティファクトディレクトリに、設定があればオブジェクトストレージに移動されます。

RailsとSidekiqを複数のサーバーで実行するスケールアウトアーキテクチャでは、ファイルシステム上のこれら2つの場所をNFSを使って共有する必要がありますが、これは推奨されません。代わりに

アーカイブされたジョブログを保存するためにオブジェクトストレージを設定します。
ジョブログの一時的なキャッシュにディスク領域の代わりにRedisを使用するインクリメンタルロギング機能を有効にします。

インクリメンタルロギングの有効化または無効化

機能フラグを有効にする前に、以下の手順に従ってください：

インクリメンタルロギングの制限をレビューしてください。
オブジェクトストレージを有効にします。

インクリメンタルロギングを有効にします：

Railsコンソールを開きます。
機能フラグを有効にします：
```
Feature.enable(:ci_enable_live_trace)
```
実行中のジョブのログはディスクに書き込まれ続けますが、新しいジョブはインクリメンタルロギングを使用します。

インクリメンタルロギングを無効にするには

Railsコンソールを開きます。
機能フラグを無効にします：
```
Feature.disable(:ci_enable_live_trace)
```
実行中のジョブは引き続きインクリメンタルロギングを使用しますが、新しいジョブはディスクに書き込みます。

技術的な詳細

データフローはデータフローのセクションで説明したものと同じですが、1つだけ変更があります。このインクリメンタルログアーキテクチャでは、ファイルストレージの代わりにRedisと永続ストア（オブジェクトストレージまたはデータベース）にログのチャンクを保存します。Redisは第一級のストレージとして使用され、最大128KBのデータを保存します。完全なチャンクが送信されると、オブジェクトストレージ（一時ディレクトリ）またはデータベースのいずれかの永続ストアにフラッシュされます。しばらくすると、Redisと永続ストアのデータはオブジェクトストレージにアーカイブされます。

データは次のRedisネームスペースに格納されます:Gitlab::Redis::TraceChunks.

以下に詳細なデータの流れを示します：

Runner は GitLab からジョブを選択します。
Runner は GitLab にログの一部を送信します。
GitLab がデータを Redis に追加
Redisのデータが128KBに達すると、データは永続ストア（オブジェクトストレージやデータベース）にフラッシュされます。
上記の手順はジョブが終了するまで繰り返されます。
ジョブが終了すると、GitLabはログをアーカイブするためにSidekiqワーカーをスケジュールします。
Sidekiqワーカーはログをオブジェクトストレージにアーカイブし、Redisと永続ストア（オブジェクトストレージまたはデータベース）のログをクリーンアップします。

制限事項

Redisクラスタはサポートされていません。
機能フラグを有効にする前に、CI/CDアーティファクト、ログ、ビルド用のオブジェクトストレージを設定する必要があります。フラグを有効にすると、ファイルをディスクに書き込むことができなくなり、設定ミスに対する保護もなくなります。
その他の潜在的な制限や改善点を追跡するエピックがあります。

ジョブログ

データフロー

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

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

ローカルディスクの使用防止

ジョブログの削除方法

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

インクリメンタルロギングの有効化または無効化

技術的な詳細

制限事項

Help & feedback

Docs

Product

Feature availability and product trials

Get Help