작업 로그

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

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

데이터 흐름

일반적으로 작업 로그에는 로그와 보관된 로그 두 가지 상태가 있습니다. 다음 표에서 로그가 거치는 단계를 볼 수 있습니다:

단계 상태 조건 데이터 흐름 저장된 경로
1: 패치 중 로그 작업 실행 중일 때 러너 => Puma => 파일 저장소 #{ROOT_PATH}/gitlab-ci/builds/#{YYYY_mm}/#{project_id}/#{job_id}.log
2: 보관 중 보관된 로그 작업이 완료된 후 Sidekiq이 로그를 아티팩트 폴더로 이동 #{ROOT_PATH}/gitlab-rails/shared/artifacts/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log
3: 업로드 중 보관된 로그 로그가 보관된 후 Sidekiq이 객체 저장소로 보관된 로그를 이동합니다(설정된 경우) #{bucket_name}/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log

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

  • 리눅스 패키지의 경우 /var/opt/gitlab입니다.
  • 직접 컴파일하여 설치한 경우 /home/git/gitlab입니다.

작업 로그의 로컬 위치 변경

note
도커 설치의 경우 데이터가 마운트된 위치를 변경할 수 있습니다. 헬름 차트를 사용하는 경우 객체 저장소를 사용합니다.

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

리눅스 패키지 (Omnibus)

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

    sudo gitlab-ctl stop sidekiq

  2. /etc/gitlab/gitlab.rb에서 새로운 저장 위치를 설정합니다: 

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

  3. 파일을 저장하고 GitLab을 다시 구성합니다: 

    sudo gitlab-ctl reconfigure

  4. rsync를 사용하여 현재 위치에서 새 위치로 작업 로그를 이동합니다: 

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

    --ignore-existing를 사용하여 같은 로그의 이전 버전으로 새 작업 로그를 덮지 않습니다.

  5. 지속적인 통합 데이터 처리를 일시적으로 중지하였다면 Sidekiq를 다시 시작할 수 있습니다: 

    sudo gitlab-ctl start sidekiq

  6. 이전의 작업 로그 저장 위치를 제거합니다: 

    sudo rm -rf /var/opt/gitlab/gitlab-ci/builds
직접 컴파일 (소스)

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

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

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

  2. `/home/git/gitlab/config/gitlab.yml’를 편집하여 새 저장 위치를 설정합니다: 

    production: &base
  gitlab_ci:
    builds_path: /mnt/gitlab-ci/builds

  3. 파일을 저장하고 GitLab을 재시작합니다: 

    # systemd를 실행 중인 시스템의 경우
sudo systemctl restart gitlab.target

# SysV init를 실행 중인 시스템의 경우
sudo service gitlab restart

  4. rsync를 사용하여 현재 위치에서 새 위치로 작업 로그를 이동합니다: 

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

    --ignore-existing를 사용하여 같은 로그의 이전 버전으로 새 작업 로그를 덮지 않습니다.

  5. 지속적인 통합 데이터 처리를 일시적으로 중지하였다면 Sidekiq를 다시 시작할 수 있습니다: 

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

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

  6. 이전의 작업 로그 저장 위치를 제거합니다: 

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

객체 저장소에 로그 업로드

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

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

로컬 디스크 사용 방지

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

작업 로그 제거 방법

이전 작업 로그가 자동으로 만료되는 방법은 없지만, 공간을 많이 차지하고 있다면 제거해도 안전합니다. 로그를 수동으로 제거하면 UI에서 작업 결과가 비어있을 것입니다.

예를 들어, 60일보다 오래된 모든 작업 로그를 삭제하려면 GitLab 인스턴스의 쉘에서 다음 명령을 실행합니다.

참고: 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

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

증분 로깅 아키텍처

  • GitLab 10.8에 도입되었습니다. 기본적으로 비활성화된 ci_enable_live_trace라는 플래그가 있습니다.
  • GitLab 13.6에서 GitLab.com에서 활성화되었습니다.
  • GitLab 13.6에서 프로덕션 환경에서의 사용이 권장됩니다.
  • GitLab 13.7에서 AWS S3와 함께 프로덕션 환경에서의 사용이 권장됩니다.
  • GitLab Self-Managed 인스턴스에서 사용하려면, GitLab 관리자에게 활성화할 것을 요청하십시오.

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

레일즈와 Sidekiq가 하나 이상의 서버에서 실행되는 스케일 아웃 아키텍처의 경우 파일 시스템의 두 위치를 NFS를 사용하여 공유해야 합니다. 대신, 다음을 수행하십시오:

  1. 아카이브된 작업 로그를 저장하기 위해 객체 저장소를 구성합니다.
  2. 증분 로깅 기능을 활성화합니다. 이는 새로운 작업이 디스크 공간 대신에 Redis를 사용하여 임시 캐싱하는 기능입니다.

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

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

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

  1. Rails 콘솔을 엽니다.

  2. 플래그를 활성화합니다. 

    Feature.enable(:ci_enable_live_trace)

    실행 중인 작업 로그는 여전히 디스크에 기록되지만, 새로운 작업은 증분 로깅을 사용합니다.

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

  1. Rails 콘솔을 엽니다.

  2. 플래그를 비활성화합니다. 

    Feature.disable(:ci_enable_live_trace)

    실행 중인 작업은 계속해서 증분 로깅을 사용하지만, 새로운 작업은 디스크에 기록됩니다.

기술적인 세부 정보

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

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

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

  1. Runner가 GitLab에서 작업을 선택합니다.
  2. Runner가 로그 조각을 GitLab에 전송합니다.
  3. GitLab이 데이터를 Redis에 추가합니다.
  4. Redis의 데이터가 128 KB에 도달하면, 데이터는 영구 저장소(객체 저장소 또는 데이터베이스)로 플러시됩니다.
  5. 위 단계를 작업이 완료될 때까지 반복합니다.
  6. 작업이 완료되면, GitLab은 Sidekiq 워커를 일정하여 로그를 아카이브합니다.
  7. Sidekiq 워커가 로그를 객체 저장소에 아카이브하고 Redis와 영구 저장소(객체 저장소 또는 데이터베이스)에서 로그를 정리합니다.

제한 사항