ジョブのログ
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
となります。
ジョブログのローカルロケーションの変更
ジョブログの保存場所を変更するには、以下の手順に従ってください。
オムニバスのインストールで:
-
/etc/gitlab/gitlab.rb
を編集し、以下の行を追加または修正してください:gitlab_ci['builds_directory'] = '/mnt/to/gitlab-ci/builds'
-
ファイルを保存し、変更を有効にするために GitLab を再設定します。
ソースからのインストールで:
-
/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/
-
ファイルを保存し、GitLabを再起動して変更を有効にします。
オブジェクトストレージへのログのアップロード
アーカイブされたログはジョブのアーティファクトとみなされるため、オブジェクトストレージのインテグレーションを設定すると、ジョブのログは他のジョブのアーティファクトと一緒に自動的にオブジェクトストレージに移行されます。
プロセスについては、データフローの「フェーズ4:アップロード」をご覧ください。
ジョブログの削除方法
古いジョブログを自動的に期限切れにする方法はありませんが、容量を取りすぎている場合は削除するのが安全です。 手動でログを削除した場合、UIのジョブ出力は空になります。
例えば、60日以上前のジョブログをすべて削除するには、GitLabインスタンスのshellから以下を実行します:
find /var/opt/gitlab/gitlab-rails/shared/artifacts -name "job.log" -mtime +60 -delete
新しいインクリメンタルロギングアーキテクチャ
- GitLab 10.4 で導入されました。
- GitLab 11.0での一般利用が発表されました。
オブジェクトストレージの設定と処理を組み合わせることで、ローカルのファイルストレージを完全にバイパスすることができます。 これは、GitLabがKubernetes上などでクラウドネイティブとしてインストールされている場合に便利なオプションです。
データフローはデータフローのセクションで説明したものと同じですが、1つだけ変更点があります。 このインクリメンタルログアーキテクチャでは_、_ファイルストレージの代わりに、Redisと永続ストア(オブジェクトストレージまたはデータベース)にログのチャンクを保存します。 Redisはファーストクラスのストレージとして使用され、最大128KBのデータを保存します。 チャンク全体が送信されると、オブジェクトストレージ(一時ディレクトリ)またはデータベースの永続ストアにフラッシュされます。 しばらくすると、Redisと永続ストアのデータはオブジェクトストレージにアーカイブされます。
データは以下のRedis名前空間に格納されています:Gitlab::Redis::SharedState
.
詳細なデータの流れは以下の通りです:
- GitLab RunnerはGitLabからジョブを選びます。
- GitLab Runner はログの一部を GitLab に送信します。
- GitLabはRedisにデータを追加します。
- Redis内のデータが128KBに達すると、データは永続ストア(オブジェクトストレージまたはデータベース)にフラッシュされます。
- 以上の手順をジョブが終了するまで繰り返します。
- ジョブが終了すると、GitLabはログをアーカイブするためにSidekiqワーカーをスケジュールします。
- 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:Redisの全データが誤ってフラッシュされた場合
- 進行中のインクリメンタルログは、ログを再送信することで回復することができます(これはGitLab Runnerのすべてのバージョンでサポートされています)。
- インクリメンタルログをアーカイブしていない終了したジョブは、ログデータの最後の部分(~128KB)を失います。
-
ケース2:Sidekiqワーカーがアーカイブに失敗した場合(アーカイブ処理ができないバグがあった、Sidekiqの不整合など
- 現在、Redisのログデータは1週間後にすべて削除されます。 期限までにSidekiqワーカーが終了できない場合、ログデータの一部が失われます。
もう1つ発生する可能性のあるイシューは、Redisインスタンスのメモリをすべて消費してしまうことです。 ジョブ数が1000の場合、128MB(128KB * 1000)が消費されます。
また、データベースのレプリケーションラグを圧迫する可能性もあります。INSERT
sはログチャンクがあることを示すために生成されます。UPDATE
sは128KBのデータで、複数のチャンクを受信すると発行されます。