ジョブログ

プラン: Free、Premium、Ultimate
提供形態: GitLab Self-Managed

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

データの流れ

一般に、ジョブログには2つの状態があります。logとarchived logです。次の表では、ログファイルがたどるフェーズを確認できます:

フェーズ	ステート	条件	データの流れ	保存パス
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チャートの場合は、オブジェクトストレージを使用します。

ジョブのログファイルの保存場所を変更するには、次の手順を実行します:

オプション。既存のジョブログがある場合は、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
```

オプション。既存のジョブログがある場合は、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：アップロード」を参照してください。

ログファイルの最大サイズ

GitLabのジョブログファイルサイズの制限は、デフォルトで100 MBです。制限を超過したジョブは失敗とマークされ、Runnerによって破棄されます。詳細については、ジョブのログファイルの最大ファイルサイズを参照してください。

ローカルディスクの使用量の抑制

ジョブログのローカルディスクの使用を回避する場合は、次のいずれかのオプションを使用します:

増分ロギングをオンにします。
ジョブログの場所をNFSドライブに設定します。

ジョブログの削除方法

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

GitLab CLIを使用してジョブログを削除する方法の詳細については、ジョブログの削除を参照してください。

または、Shellコマンドでジョブログを削除することもできます。たとえば、60日より古いすべてのジョブログを削除するには、GitLabインスタンスのShellから次のコマンドを実行します。

Helm Chartの場合は、オブジェクトストレージに付属しているストレージ管理ツールを使用します。

次のコマンドは、ログファイルを完全に削除し、元に戻すことはできません。

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

/var/opt/gitlabを/srv/gitlabにマウントしている場合は、次のようになります:

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

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

ログファイルを削除したら、アップロードされたファイルの整合性をチェックするRakeタスクを実行して、破損したファイル参照を検索できます。詳細については、欠落しているアーティファクトへの参照を削除する方法を参照してください。

増分ロギング

増分ロギングは、ジョブログが処理および保存される方法を変更し、スケールアウトされたデプロイでのパフォーマンスを向上させます。

デフォルトでは、ジョブログはチャンク単位でGitLab Runnerから送信され、ディスクに一時的にキャッシュされます。ジョブの完了後、バックグラウンドジョブはログファイルをアーティファクトディレクトリ、または構成されている場合はオブジェクトストレージにアーカイブします。

増分ロギングでは、ログファイルはファイルストレージではなく、Redisおよび永続ストレージに保存されます。このアプローチは次のことを可能にします:

ジョブログにローカルディスクを使用しないようにします。
RailsサーバーとSidekiqサーバー間のNFS共有の必要性を排除します。
マルチノードインストールでのパフォーマンスが向上します。

増分ロギングプロセスは、一時ストレージとしてRedisを使用し、次のフローに従います:

Runnerは、GitLabからジョブを選択します。
Runnerは、ログファイルの一部をGitLabに送信します。
GitLabは、Gitlab::Redis::TraceChunksネームスペースのRedisにデータを追加します。
Redisのデータが128 KBに達すると、データは永続ストレージにフラッシュされます。
ジョブが完了するまで、前の手順が繰り返されます。
ジョブが完了すると、GitLabはSidekiqワーカーをスケジュールしてログファイルをアーカイブします。
Sidekiqワーカーは、ログファイルをオブジェクトストレージにアーカイブし、一時データをクリーンアップします。

Redisクラスタリングは、増分ロギングではサポートされていません。詳細については、イシュー224171を参照してください。

増分ログの生成を設定する

増分ロギングをオンにする前に、CI/CDアーティファクト、ログファイル、およびビルドのオブジェクトストレージを構成する必要があります。増分ロギングがオンになると、ファイルはディスクに書き込むことができなくなり、設定ミスに対する保護はなくなります。

増分ロギングをオンにすると、実行中のジョブのログファイルは引き続きディスクに書き込まれますが、新しいジョブは増分ロギングを使用します。

増分ロギングをオフにすると、実行中のジョブは引き続き増分ロギングを使用しますが、新しいジョブはディスクに書き込みます。

増分ログを設定するには:

管理者エリアまたは設定で設定を使用します。