작업 로그

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

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

데이터 흐름

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

단계	상태	조건	데이터 흐름	저장 경로
1: 패치	log	작업이 실행 중일 때	러너 => 푸마 => 파일 저장소	`#{ROOT_PATH}/gitlab-ci/builds/#{YYYY_mm}/#{project_id}/#{job_id}.log`
2: 아카이빙	archived log	작업이 완료된 후	사이드킥이 로그를 아카이브 폴더로 이동	`#{ROOT_PATH}/gitlab-rails/shared/artifacts/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log`
3: 업로드	archived log	로그가 아카이브된 후	사이드킥이 아카이브된 로그를 객체 저장소로 이동 (구성된 경우)	`#{bucket_name}/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log`

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

리눅스 패키지는 /var/opt/gitlab입니다.
자체 컴파일된 설치는 /home/git/gitlab입니다.

작업 로그 로컬 위치 변경

Docker 설치의 경우 데이터가 마운트되는 경로를 변경할 수 있습니다.
Helm 차트의 경우 객체 저장소를 사용하세요.

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

리눅스 패키지 (Omnibus)

선택 사항. 기존 작업 로그가 있는 경우,
사이드킥을 일시 중지하여 지속적인 통합 데이터 처리를 중단합니다:
```
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을 사용하세요.
지속적인 통합 데이터 처리를 중단하기로 선택한 경우,
사이드킥을 다시 시작할 수 있습니다:
```
sudo gitlab-ctl start sidekiq
```
이전 작업 로그 저장 위치를 제거합니다:
```
sudo rm -rf /var/opt/gitlab/gitlab-ci/builds
```

자체 컴파일 (소스)

선택 사항. 기존 작업 로그가 있는 경우,
사이드킥을 일시 중지하여 지속적인 통합 데이터 처리를 중단합니다:

# 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을 사용하세요.

지속적인 통합 데이터 처리를 중단하기로 선택한 경우,
사이드킥을 다시 시작할 수 있습니다:

# systemd를 사용하는 시스템의 경우
sudo systemctl start gitlab-sidekiq

# SysV init을 사용하는 시스템의 경우
sudo service gitlab start

이전 작업 로그 저장 위치를 제거합니다:
```
sudo rm -rf /home/git/gitlab/builds
```

로그를 객체 스토리지에 업로드하기

아카이브된 로그는 작업 아티팩트로 간주됩니다.

따라서 객체 스토리지 통합을 설정하면

작업 로그는 다른 작업 아티팩트와 함께 자동으로 이전됩니다.

프로세스에 대해 알아보려면 데이터 흐름의 “3단계: 업로드”를 참조하세요.

로컬 디스크 사용 방지

작업 로그에 대한 로컬 디스크 사용을 피하려면

다음 옵션 중 하나를 사용할 수 있습니다:

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

작업 로그 제거 방법

오래된 작업 로그를 자동으로 만료하는 방법은 없지만

공간을 너무 많이 차지하는 경우 안전하게 제거할 수 있습니다.

로그를 수동으로 제거하면 UI에서 작업 출력이 비어 있습니다.

예를 들어, 60일 이상된 모든 작업 로그를 삭제하려면

GitLab 인스턴스의 셸에서 다음 명령을 실행하세요.

참고: Helm 차트의 경우 객체 스토리지와 함께 제공되는 스토리지 관리 도구를 사용하세요.

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

리눅스 패키지 (Omnibus)

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 자체 관리 인스턴스에서 사용하려면 GitLab 관리자에게 활성화를 요청하세요.

기본적으로 작업 로그는 GitLab Runner에서 청크로 전송되며

디스크에 일시적으로 캐시됩니다.

작업이 완료되면 백그라운드 작업이 작업 로그를 아카이브합니다.

로그는 기본적으로 아티팩트 디렉토리로 이동되거나

구성된 경우 객체 스토리지로 이동합니다.

여러 서버에서 Rails 및 Sidekiq가 실행되는 확장 아키텍처에서는

파일 시스템의 두 위치가 NFS를 사용하여 공유되어야 하며, 이는 권장되지 않습니다.

대신:

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

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

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

증분 로깅의 한계를 검토하세요.
객체 스토리지를 활성화하세요.

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

Rails 콘솔을 엽니다.
기능 플래그를 활성화합니다:
```
Feature.enable(:ci_enable_live_trace)
```
실행 중인 작업의 로그는 계속 디스크에 기록되지만, 새로운 작업은

증분 로깅을 사용합니다.

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

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

기술 세부사항

데이터 흐름은 데이터 흐름 섹션에서 설명된 것과 동일하지만 한 가지 변경 사항이 있습니다: 첫 두 단계의 저장 경로가 다릅니다. 이 증분 로그 아키텍처는 파일 스토리지 대신 Redis와 영구 저장소(오브젝트 스토리지 또는 데이터베이스)에 로그 청크를 저장합니다. Redis는 일급 저장소로 사용되며 최대 128 KB의 데이터를 저장합니다. 전체 청크가 전송된 후, 그것은 영구 저장소(임시 디렉토리인 오브젝트 스토리지 또는 데이터베이스)로 플러시됩니다. 시간이 지나면 Redis와 영구 저장소의 데이터는 오브젝트 스토리지로 아카이브됩니다.

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

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

러너가 GitLab에서 작업을 선택합니다.
러너가 GitLab에 로그 조각을 보냅니다.
GitLab이 데이터를 Redis에 추가합니다.
Redis의 데이터가 128 KB에 도달하면, 데이터는 영구 저장소(오브젝트 스토리지 또는 데이터베이스)로 플러시됩니다.
위의 단계가 작업이 완료될 때까지 반복됩니다.
작업이 완료되면 GitLab이 로그 아카이브를 위해 Sidekiq 작업자를 예약합니다.
Sidekiq 작업자가 로그를 오브젝트 스토리지에 아카이브하고 Redis와 영구 저장소(오브젝트 스토리지 또는 데이터베이스)에서 로그를 정리합니다.

제한사항

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

작업 로그

데이터 흐름

작업 로그 로컬 위치 변경

로그를 객체 스토리지에 업로드하기

로컬 디스크 사용 방지

작업 로그 제거 방법

증분 로깅 아키텍처

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

기술 세부사항

제한사항

도움말

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

도움받기