작업 로그

Tier: Free, Premium, Ultimate Offering: Self-managed

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

데이터 흐름

일반적으로 작업 로그에는 log 및 archived log 두 가지 상태가 있습니다. 다음 테이블에서 로그가 거치는 단계를 볼 수 있습니다:

Phase	State	Condition	Data flow	Stored path
1: patching	log	When a job is running	Runner => Puma => file storage	`#{ROOT_PATH}/gitlab-ci/builds/#{YYYY_mm}/#{project_id}/#{job_id}.log`
2: archiving	archived log	After a job is finished	Sidekiq moves log to artifacts folder	`#{ROOT_PATH}/gitlab-rails/shared/artifacts/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log`
3: uploading	archived log	After a log is archived	Sidekiq moves archived log to object storage (if configured)	`#{bucket_name}/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log`

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

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

작업 로그의 로컬 위치 변경

도커 설치의 경우 데이터가 탑재된 위치를 변경할 수 있습니다. 헬름 차트의 경우, 객체 리포지터리를 사용하세요.

작업 로그가 저장된 위치를 변경하려면:

Linux 패키지 (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
```

직접 컴파일 (소스)

선택 사항. 기존 작업 로그가 있는 경우, 일시적으로 Sidekiq를 중지하여 지속적인 연속 통합 데이터 처리를 일시 중단하세요:

# systemd를 실행 중인 시스템의 경우
sudo systemctl stop gitlab-sidekiq
   
# SysV init를 실행 중인 시스템의 경우
   sudo service gitlab stop

/home/git/gitlab/config/gitlab.yml을 편집하여 새로운 저장 위치를 설정하세요:
```
production: &base
  gitlab_ci:
    builds_path: /mnt/gitlab-ci/builds
```

파일을 저장하고 GitLab을 다시 시작하세요:

# systemd를 실행 중인 시스템의 경우
sudo systemctl restart gitlab.target
   
# 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를 다시 시작할 수 있습니다:

# systemd를 실행 중인 시스템의 경우
sudo systemctl start gitlab-sidekiq
   
# SysV init를 실행 중인 시스템의 경우
sudo service gitlab start

이전의 작업 로그 저장 위치를 제거하세요:
```
sudo rm -rf /home/git/gitlab/builds
```

객체 리포지터리로 로그 업로드

보관된 로그는 작업 아티팩트로 간주됩니다. 따라서, 객체 리포지터리 통합을 설정하면 작업 로그는 다른 작업 아티팩트와 함께 자동으로 이동됩니다.

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

로컬 디스크 사용 방지

작업 로그를 위한 로컬 디스크 사용을 피하려면, 다음 중 하나를 사용할 수 있습니다:

증분 로깅 기능을 활성화합니다.
작업 로그 위치를 NFS 드라이브로 설정합니다.

작업 로그 삭제 방법

이전 작업 로그를 자동으로 만료시키는 방법은 없지만, 공간을 많이 차지한다면 안전하게 제거할 수 있습니다. 로그를 매뉴얼으로 삭제하면 UI의 작업 출력이 비어 있습니다.

예를 들어, GitLab 인스턴스의 셸에서 다음 명령을 실행하여 60일 이전의 모든 작업 로그를 삭제할 수 있습니다.

헬름 차트의 경우, 객체 리포지터리와 함께 제공되는 리포지터리 관리 도구를 사용하세요.

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

Linux 패키지 (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

직접 컴파일 (소스)

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

로그를 삭제한 후, Rake 작업을 실행하여 업로드된 파일의 무결성을 확인하는 작업을 통해 깨진 파일 참조를 찾을 수 있습니다. 더 자세한 정보는 누락된 아티팩트에 대한 참조 삭제를 참조하세요.

증분 로깅 아키텍처

- GitLab 10.8에서 도입되었습니다. ci_enable_live_trace라는 플래그로 기본값은 비활성화되어 있습니다. - GitLab 13.6에서 GitLab.com에 활성화되었습니다. - GitLab 13.6에서 GitLab 13.6에 대한 운영 환경에서의 사용을 권장합니다. - GitLab 13.7에서 AWS S3를 사용하여 운영 환경에서의 사용을 권장합니다. - GitLab의 Self-managed 인스턴스에서 사용하려면 GitLab 관리자에게 활성화하도록 요청하세요.

기본적으로 작업 로그는 GitLab Runner에서 청크 단위로 전송되어 임시로 디스크에 캐시됩니다. 작업이 완료된 후 백그라운드 작업이 작업 로그를 아카이브합니다. 기본적으로 로그는 아티팩트 디렉터리로 이동하거나 구성된 경우 객체 리포지터리로 이동합니다.

Rails와 Sidekiq가 여러 서버에서 실행되는 확장형 아키텍처에서는 파일 시스템의 이러한 두 위치를 NFS를 사용하여 공유해야 하므로 권장되지 않습니다. 대신:

아카이브된 작업 로그를 저장하기 위해 객체 리포지터리 구성합니다.
디스크 공간 대신 Redis를 사용하여 임시적으로 작업 로그를 캐싱하는 증분 로깅 기능을 활성화합니다.

증분 로깅 활성화 또는 비활성화

피처 플래그를 활성화하기 전에:

증분 로깅의 제한 사항을 리뷰하세요.
객체 리포지터리를 활성화합니다.

증분 로깅을 활성화하려면:

Rails 콘솔을 엽니다.
피처 플래그를 활성화합니다:
```
Feature.enable(:ci_enable_live_trace)
```
실행 중인 작업 로그는 여전히 디스크에 기록되지만 새로운 작업에는 증분 로깅이 사용됩니다.

증분 로깅을 비활성화하려면:

Rails 콘솔을 엽니다.
피처 플래그를 비활성화합니다:
```
Feature.disable(:ci_enable_live_trace)
```
실행 중인 작업은 계속해서 증분 로깅을 사용하지만 새로운 작업은 디스크에 기록됩니다.

기술적 세부 정보

데이터 흐름은 데이터 흐름 섹션에서 설명한 것과 동일하지만 한 가지 변경 사항이 있습니다: 첫 번째 두 단계의 저장된 경로가 다릅니다. 이 증분 로그 아키텍처는 로그 청크를 Redis와 영구 리포지터리(객체 리포지터리 또는 데이터베이스)에 저장하여 파일 리포지터리 대신 Redis를 일등 시민으로 사용합니다. Redis는 최대 128 KB의 데이터를 저장합니다. 전체 청크가 전송되면 임시 디렉터리의 객체 리포지터리 또는 데이터베이스로 플러시됩니다. 얼마 후에 Redis 및 영구 리포지터리의 데이터가 객체 리포지터리로 아카이브됩니다.

데이터는 다음과 같은 Redis 네임스페이스에 저장됩니다: Gitlab::Redis::TraceChunks.

다음은 자세한 데이터 흐름입니다:

Runner가 GitLab에서 작업을 선택합니다.
Runner가 GitLab에 로그 조각을 전송합니다.
GitLab이 데이터를 Redis에 추가합니다.
Redis의 데이터가 128 KB에 도달하면 데이터가 영구 리포지터리(객체 리포지터리 또는 데이터베이스)로 플러시됩니다.
위 단계가 작업이 완료될 때까지 반복됩니다.
작업이 완료된 후 GitLab은 Sidekiq 워커를 스케줄하여 로그를 아카이브합니다.
Sidekiq 워커가 로그를 객체 리포지터리에 아카이브하고 Redis 및 영구 리포지터리(객체 리포지터리 또는 데이터베이스)에서 로그를 정리합니다.

제한 사항

Redis 클러스터는 지원되지 않습니다.
피처 플래그를 활성화하기 전에 CI/CD 아티팩트, 로그 및 빌드를 위해 객체 리포지터리를 구성해야 합니다. 플래그가 활성화된 후 파일을 디스크에 작성하지 못하며 구성 오류에 대한 보호 기능도 없습니다.
다른 잠재적 제한 사항 및 개선 사항을 추적하는 에픽이 있습니다.

작업 로그

데이터 흐름

작업 로그의 로컬 위치 변경

객체 리포지터리로 로그 업로드

로컬 디스크 사용 방지

작업 로그 삭제 방법

증분 로깅 아키텍처

증분 로깅 활성화 또는 비활성화

기술적 세부 정보

제한 사항

도움말

기능 사용 가능성과 제품 평가판

도움받기