잡 로그

요약

- Offering: GitLab Self-Managed Job logs는 러너가 job을 처리하는 동안 러너에 의해 전송됩니다. 일반적으로 job logs에는 log와 archived log의 두 가지 상태가 있습니다.

Job logs#

  - 
  Tier: Free, Premium, Ultimate

- Offering: GitLab Self-Managed

Job logs는 러너가 job을 처리하는 동안 러너에 의해 전송됩니다. job 페이지, 파이프라인, 이메일 알림 등 여러 위치에서 로그를 확인할 수 있습니다.

데이터 흐름#

일반적으로 job logs에는 log와 archived log의 두 가지 상태가 있습니다. 다음 표에서 로그가 거치는 단계를 확인할 수 있습니다:

단계	상태	조건	데이터 흐름	저장 경로
1: patching	log	job이 실행 중일 때	Runner => Puma => file storage	#{ROOT_PATH}/gitlab-ci/builds/#{YYYY_mm}/#{project_id}/#{job_id}.log
2: archiving	archived log	job이 완료된 후	Sidekiq이 로그를 아티팩트 폴더로 이동	#{ROOT_PATH}/gitlab-rails/shared/artifacts/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log
3: uploading	archived log	로그가 아카이브된 후	Sidekiq이 아카이브된 로그를 오브젝트 스토리지로 이동(구성된 경우)	#{bucket_name}/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log

ROOT_PATH는 환경에 따라 다릅니다:

Linux 패키지의 경우 /var/opt/gitlab입니다.
직접 컴파일한 설치의 경우 /home/git/gitlab입니다.

Job logs 로컬 위치 변경#

Docker 설치의 경우 데이터가 마운트된 경로를 변경할 수 있습니다.

Helm 차트의 경우 오브젝트 스토리지를 사용하세요.

job logs가 저장되는 위치를 변경하려면:

Linux package (Omnibus)

선택 사항. 기존 job logs가 있는 경우 Sidekiq을 일시적으로 중지하여 지속적인 CI/CD 데이터 처리를 일시 중지합니다:

sudo gitlab-ctl stop sidekiq

/etc/gitlab/gitlab.rb에서 새 스토리지 위치를 설정합니다:

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

파일을 저장하고 GitLab을 재구성합니다:

sudo gitlab-ctl reconfigure

rsync를 사용하여 job logs를 현재 위치에서 새 위치로 이동합니다:

sudo rsync -avzh --remove-source-files --ignore-existing --progress /var/opt/gitlab/gitlab-ci/builds/ /mnt/gitlab-ci/builds/

--ignore-existing을 사용하여 새 job logs가 동일한 로그의 이전 버전으로 덮어쓰이지 않도록 합니다.

CI/CD 데이터 처리를 일시 중지하기로 선택한 경우 Sidekiq을 다시 시작할 수 있습니다:

sudo gitlab-ctl start sidekiq

이전 job logs 스토리지 위치를 제거합니다:

sudo rm -rf /var/opt/gitlab/gitlab-ci/builds

Self-compiled (source)

선택 사항. 기존 job logs가 있는 경우 Sidekiq을 일시적으로 중지하여 지속적인 CI/CD 데이터 처리를 일시 중지합니다:

# 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를 사용하여 job logs를 현재 위치에서 새 위치로 이동합니다:

sudo rsync -avzh --remove-source-files --ignore-existing --progress /home/git/gitlab/builds/ /mnt/gitlab-ci/builds/

--ignore-existing을 사용하여 새 job logs가 동일한 로그의 이전 버전으로 덮어쓰이지 않도록 합니다.

CI/CD 데이터 처리를 일시 중지하기로 선택한 경우 Sidekiq을 다시 시작할 수 있습니다:

# For systems running systemd
sudo systemctl start gitlab-sidekiq

# For systems running SysV init
sudo service gitlab start

이전 job logs 스토리지 위치를 제거합니다:

sudo rm -rf /home/git/gitlab/builds

오브젝트 스토리지에 로그 업로드#

아카이브된 로그는 job 아티팩트로 간주됩니다. 따라서 오브젝트 스토리지 통합을 설정하면 job logs는 다른 job 아티팩트와 함께 자동으로 마이그레이션됩니다.

프로세스에 대해 알아보려면 데이터 흐름의 "Phase 3: uploading"을 참조하세요.

최대 로그 파일 크기#

GitLab의 job 로그 파일 크기 제한은 기본적으로 100메가바이트입니다. 제한을 초과하는 job은 실패로 표시되고 러너에 의해 삭제됩니다. 자세한 내용은 job logs의 최대 파일 크기를 참조하세요.

로컬 디스크 사용 방지#

job logs에 대한 로컬 디스크 사용을 방지하려면 다음 옵션 중 하나를 사용할 수 있습니다:

증분 로깅을 활성화합니다.
job logs 위치를 NFS 드라이브로 설정합니다.

Job logs 제거 방법#

오래된 job logs를 자동으로 만료시키는 방법은 없습니다. 그러나 너무 많은 공간을 차지하는 경우 안전하게 제거할 수 있습니다. 로그를 수동으로 제거하면 UI의 job 출력이 비어 있게 됩니다.

GitLab CLI를 사용하여 job logs를 삭제하는 방법에 대한 자세한 내용은 Job logs 삭제를 참조하세요.

Helm 차트의 경우 오브젝트 스토리지와 함께 제공된 스토리지 관리 도구를 사용하세요.

또는 셸 명령어를 사용하여 job logs를 삭제할 수 있습니다. 예를 들어 60일보다 오래된 모든 job logs를 삭제하려면 GitLab 인스턴스의 셸에서 다음 명령어를 실행합니다.

다음 명령어는 로그 파일을 영구적으로 삭제하며 되돌릴 수 없습니다.

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 태스크를 실행하여 손상된 파일 참조를 찾을 수 있습니다. 자세한 내용은 누락된 아티팩트에 대한 참조 삭제 방법을 참조하세요.

증분 로깅#

증분 로깅은 job logs의 처리 및 저장 방식을 변경하여 스케일 아웃 배포에서 성능을 향상시킵니다.

기본적으로 job logs는 GitLab Runner에서 청크 단위로 전송되어 디스크에 일시적으로 캐시됩니다. job이 완료되면 백그라운드 job이 로그를 아티팩트 디렉터리 또는 구성된 경우 오브젝트 스토리지로 아카이브합니다.

증분 로깅을 사용하면 로그가 파일 스토리지 대신 Redis와 영구 저장소에 저장됩니다. 이 방식은 다음과 같은 이점을 제공합니다:

job logs에 대한 로컬 디스크 사용을 방지합니다.
Rails와 Sidekiq 서버 간의 NFS 공유 필요성을 제거합니다.
멀티 노드 설치에서 성능을 향상시킵니다.

증분 로깅 프로세스는 Redis를 임시 스토리지로 사용하며 다음 흐름을 따릅니다:

러너가 GitLab에서 job을 가져옵니다.
러너가 GitLab에 로그 일부를 전송합니다.
GitLab이 Gitlab::Redis::TraceChunks 네임스페이스의 Redis에 데이터를 추가합니다.
Redis의 데이터가 128KB에 도달하면 데이터가 영구 저장소로 플러시됩니다.
job이 완료될 때까지 이전 단계들이 반복됩니다.
job이 완료되면 GitLab이 로그를 아카이브하기 위한 Sidekiq 워커를 예약합니다.
Sidekiq 워커가 로그를 오브젝트 스토리지에 아카이브하고 임시 데이터를 정리합니다.

Redis Cluster는 증분 로깅에서 지원되지 않습니다. 자세한 내용은 이슈 224171을 참조하세요.

증분 로깅 구성#

증분 로깅을 활성화하기 전에 CI/CD 아티팩트, 로그 및 빌드를 위한 오브젝트 스토리지를 구성해야 합니다. 증분 로깅이 활성화되면 파일을 디스크에 쓸 수 없으며, 잘못된 구성에 대한 보호가 없습니다.

증분 로깅을 활성화하면 실행 중인 job의 로그는 계속 디스크에 기록되지만, 새 job은 증분 로깅을 사용합니다.

증분 로깅을 끄면 실행 중인 job은 계속 증분 로깅을 사용하지만, 새 job은 디스크에 기록합니다.

증분 로깅을 구성하려면:

Admin area 또는 Settings API의 설정을 사용합니다.

잡 로그

GitLab v19.2

원문 보기

번역일: 2026-06-19

요약

Job logs#

  - 
  Tier: Free, Premium, Ultimate

- Offering: GitLab Self-Managed

Job logs는 러너가 job을 처리하는 동안 러너에 의해 전송됩니다. job 페이지, 파이프라인, 이메일 알림 등 여러 위치에서 로그를 확인할 수 있습니다.

데이터 흐름#

일반적으로 job logs에는 log와 archived log의 두 가지 상태가 있습니다. 다음 표에서 로그가 거치는 단계를 확인할 수 있습니다:

단계	상태	조건	데이터 흐름	저장 경로
1: patching	log	job이 실행 중일 때	Runner => Puma => file storage	#{ROOT_PATH}/gitlab-ci/builds/#{YYYY_mm}/#{project_id}/#{job_id}.log
2: archiving	archived log	job이 완료된 후	Sidekiq이 로그를 아티팩트 폴더로 이동	#{ROOT_PATH}/gitlab-rails/shared/artifacts/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log
3: uploading	archived log	로그가 아카이브된 후	Sidekiq이 아카이브된 로그를 오브젝트 스토리지로 이동(구성된 경우)	#{bucket_name}/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log

ROOT_PATH는 환경에 따라 다릅니다:

Linux 패키지의 경우 /var/opt/gitlab입니다.
직접 컴파일한 설치의 경우 /home/git/gitlab입니다.

Job logs 로컬 위치 변경#

Docker 설치의 경우 데이터가 마운트된 경로를 변경할 수 있습니다.

Helm 차트의 경우 오브젝트 스토리지를 사용하세요.

job logs가 저장되는 위치를 변경하려면:

Linux package (Omnibus)

선택 사항. 기존 job logs가 있는 경우 Sidekiq을 일시적으로 중지하여 지속적인 CI/CD 데이터 처리를 일시 중지합니다:

sudo gitlab-ctl stop sidekiq

/etc/gitlab/gitlab.rb에서 새 스토리지 위치를 설정합니다:

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

파일을 저장하고 GitLab을 재구성합니다:

sudo gitlab-ctl reconfigure

rsync를 사용하여 job logs를 현재 위치에서 새 위치로 이동합니다:

sudo rsync -avzh --remove-source-files --ignore-existing --progress /var/opt/gitlab/gitlab-ci/builds/ /mnt/gitlab-ci/builds/

--ignore-existing을 사용하여 새 job logs가 동일한 로그의 이전 버전으로 덮어쓰이지 않도록 합니다.

CI/CD 데이터 처리를 일시 중지하기로 선택한 경우 Sidekiq을 다시 시작할 수 있습니다:

sudo gitlab-ctl start sidekiq

이전 job logs 스토리지 위치를 제거합니다:

sudo rm -rf /var/opt/gitlab/gitlab-ci/builds

Self-compiled (source)

선택 사항. 기존 job logs가 있는 경우 Sidekiq을 일시적으로 중지하여 지속적인 CI/CD 데이터 처리를 일시 중지합니다:

# 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를 사용하여 job logs를 현재 위치에서 새 위치로 이동합니다:

sudo rsync -avzh --remove-source-files --ignore-existing --progress /home/git/gitlab/builds/ /mnt/gitlab-ci/builds/

--ignore-existing을 사용하여 새 job logs가 동일한 로그의 이전 버전으로 덮어쓰이지 않도록 합니다.

CI/CD 데이터 처리를 일시 중지하기로 선택한 경우 Sidekiq을 다시 시작할 수 있습니다:

# For systems running systemd
sudo systemctl start gitlab-sidekiq

# For systems running SysV init
sudo service gitlab start

이전 job logs 스토리지 위치를 제거합니다:

sudo rm -rf /home/git/gitlab/builds

오브젝트 스토리지에 로그 업로드#

프로세스에 대해 알아보려면 데이터 흐름의 "Phase 3: uploading"을 참조하세요.

최대 로그 파일 크기#

로컬 디스크 사용 방지#

job logs에 대한 로컬 디스크 사용을 방지하려면 다음 옵션 중 하나를 사용할 수 있습니다:

증분 로깅을 활성화합니다.
job logs 위치를 NFS 드라이브로 설정합니다.

Job logs 제거 방법#

GitLab CLI를 사용하여 job logs를 삭제하는 방법에 대한 자세한 내용은 Job logs 삭제를 참조하세요.

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

증분 로깅#

증분 로깅은 job logs의 처리 및 저장 방식을 변경하여 스케일 아웃 배포에서 성능을 향상시킵니다.

증분 로깅을 사용하면 로그가 파일 스토리지 대신 Redis와 영구 저장소에 저장됩니다. 이 방식은 다음과 같은 이점을 제공합니다:

job logs에 대한 로컬 디스크 사용을 방지합니다.
Rails와 Sidekiq 서버 간의 NFS 공유 필요성을 제거합니다.
멀티 노드 설치에서 성능을 향상시킵니다.

증분 로깅 프로세스는 Redis를 임시 스토리지로 사용하며 다음 흐름을 따릅니다:

러너가 GitLab에서 job을 가져옵니다.
러너가 GitLab에 로그 일부를 전송합니다.
GitLab이 Gitlab::Redis::TraceChunks 네임스페이스의 Redis에 데이터를 추가합니다.
Redis의 데이터가 128KB에 도달하면 데이터가 영구 저장소로 플러시됩니다.
job이 완료될 때까지 이전 단계들이 반복됩니다.
job이 완료되면 GitLab이 로그를 아카이브하기 위한 Sidekiq 워커를 예약합니다.
Sidekiq 워커가 로그를 오브젝트 스토리지에 아카이브하고 임시 데이터를 정리합니다.

Redis Cluster는 증분 로깅에서 지원되지 않습니다. 자세한 내용은 이슈 224171을 참조하세요.

증분 로깅 구성#

증분 로깅을 활성화하면 실행 중인 job의 로그는 계속 디스크에 기록되지만, 새 job은 증분 로깅을 사용합니다.

증분 로깅을 끄면 실행 중인 job은 계속 증분 로깅을 사용하지만, 새 job은 디스크에 기록합니다.

증분 로깅을 구성하려면:

Admin area 또는 Settings API의 설정을 사용합니다.