잡 로그

요약

잡 로그는 러너가 잡을 처리하는 동안 전송됩니다. 일반적으로 잡 로그에는 log와 archived log의 두 가지 상태가 있습니다. ROOT_PATH는 환경마다 다릅니다: Docker 설치의 경우 데이터가 마운트되는 경로를 변경할 수 있습니다.

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

데이터 흐름#

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

단계	상태	조건	데이터 흐름	저장 경로
1: 패치	log	잡이 실행 중일 때	Runner => Puma => 파일 스토리지	`#{ROOT_PATH}/gitlab-ci/builds/#{YYYY_mm}/#{project_id}/#{job_id}.log`
2: 아카이브	archived log	잡이 완료된 후	Sidekiq가 로그를 아티팩트 폴더로 이동	`#{ROOT_PATH}/gitlab-rails/shared/artifacts/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log`
3: 업로드	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입니다.

잡 로그 로컬 위치 변경#

Note

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메가바이트입니다. 제한을 초과하는 잡은 실패로 표시되고 러너에 의해 삭제됩니다. 자세한 내용은 잡 로그의 최대 파일 크기를 참조하세요.

로컬 디스크 사용 방지#

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

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

잡 로그 제거 방법#

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

GitLab CLI를 사용하여 잡 로그를 삭제하는 방법은 잡 로그 삭제를 참조하세요.

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

또는 셸 명령으로 잡 로그를 삭제할 수 있습니다. 예를 들어, 60일이 지난 모든 잡 로그를 삭제하려면 GitLab 인스턴스의 셸에서 다음 명령을 실행합니다.

Warning

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

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를 임시 스토리지로 사용하며 다음 흐름을 따릅니다:

러너가 GitLab에서 잡을 가져옵니다.
러너가 로그 조각을 GitLab으로 전송합니다.
GitLab이 Gitlab::Redis::TraceChunks 네임스페이스에서 Redis에 데이터를 추가합니다.
Redis의 데이터가 128KB에 도달하면 데이터가 영속 스토어로 플러시됩니다.
잡이 완료될 때까지 이전 단계가 반복됩니다.
잡이 완료된 후 GitLab은 로그를 아카이브하기 위해 Sidekiq 워커를 예약합니다.
Sidekiq 워커가 로그를 오브젝트 스토리지로 아카이브하고 임시 데이터를 정리합니다.

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

증분 로깅 구성#

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

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

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

증분 로깅을 구성하려면:

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

잡 로그

Tier: Free, Premium, Ultimate
Offering: GitLab Self-Managed

원문 보기

번역일: 2026-05-22

요약

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

데이터 흐름#

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

단계	상태	조건	데이터 흐름	저장 경로
1: 패치	log	잡이 실행 중일 때	Runner => Puma => 파일 스토리지	`#{ROOT_PATH}/gitlab-ci/builds/#{YYYY_mm}/#{project_id}/#{job_id}.log`
2: 아카이브	archived log	잡이 완료된 후	Sidekiq가 로그를 아티팩트 폴더로 이동	`#{ROOT_PATH}/gitlab-rails/shared/artifacts/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log`
3: 업로드	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입니다.

잡 로그 로컬 위치 변경#

Note

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단계: 업로드"를 참조하세요.

최대 로그 파일 크기#

로컬 디스크 사용 방지#

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

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

잡 로그 제거 방법#

GitLab CLI를 사용하여 잡 로그를 삭제하는 방법은 잡 로그 삭제를 참조하세요.

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

Warning

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

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

증분 로깅#

증분 로깅은 잡 로그가 처리되고 저장되는 방식을 변경하여 스케일 아웃 배포에서 성능을 향상시킵니다.

증분 로깅을 사용하면 로그는 파일 스토리지 대신 Redis 및 영속 스토어에 저장됩니다. 이 접근 방식은:

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

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

러너가 GitLab에서 잡을 가져옵니다.
러너가 로그 조각을 GitLab으로 전송합니다.
GitLab이 Gitlab::Redis::TraceChunks 네임스페이스에서 Redis에 데이터를 추가합니다.
Redis의 데이터가 128KB에 도달하면 데이터가 영속 스토어로 플러시됩니다.
잡이 완료될 때까지 이전 단계가 반복됩니다.
잡이 완료된 후 GitLab은 로그를 아카이브하기 위해 Sidekiq 워커를 예약합니다.
Sidekiq 워커가 로그를 오브젝트 스토리지로 아카이브하고 임시 데이터를 정리합니다.

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

증분 로깅 구성#

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

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

증분 로깅을 구성하려면:

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