작업 로그

Tier: Free, Premium, Ultimate Offering: 스스로 관리

작업 로그는 실행 중인 러너에서 보내집니다. 작업 로그는 작업 페이지, 파이프라인, 이메일 알림 등에서 볼 수 있습니다.

데이터 흐름

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

단계 상태 조건 데이터 흐름 저장된 경로
1: 패칭 로그 작업이 실행 중일 때 러너 => 푸마 => 파일 리포지터리 #{ROOT_PATH}/gitlab-ci/builds/#{YYYY_mm}/#{project_id}/#{job_id}.log
2: 아카이빙 보관된 로그 작업이 완료된 후 Sidekiq가 로그를 artifacts 폴더로 이동 #{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에서 작업 결과가 비어있게 됩니다.

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

note
헬름 차트의 경우, 객체 리포지터리에서 제공되는 리포지터리 관리 도구를 사용하세요.
caution
아래 명령은 로그 파일을 영구적으로 삭제하므로 되돌릴 수 없습니다.
리눅스 패키지 (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 스스로 관리 인스턴스에서 사용하려면, GitLab 관리자에게 활성화 여부를 요청하세요.

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

Rails와 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는 일급 리포지터리로 사용되며 128KB까지의 데이터를 저장합니다. 전체 로그 조각이 전송되면 임시 리포지터리(객체 리포지터리) 또는 데이터베이스로 플러시됩니다. 잠시 후 Redis 및 영구 리포지터리의 데이터는 객체 리포지터리로 아카이브됩니다.

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

상세한 데이터 흐름은 다음과 같습니다:

  1. 실행기가 GitLab에서 작업을 선택합니다.
  2. 실행기가 GitLab에 로그 조각을 보냅니다.
  3. GitLab이 데이터를 Redis에 추가합니다.
  4. Redis의 데이터가 128KB에 도달하면 데이터는 영구 리포지터리(객체 리포지터리 또는 데이터베이스)로 플러시됩니다.
  5. 위 단계를 작업이 완료될 때까지 반복합니다.
  6. 작업이 완료된 후 GitLab은 로그를 아카이브하기 위해 Sidekiq 워커를 예약합니다.
  7. Sidekiq 워커가 로그를 객체 리포지터리에 아카이브하고 Redis 및 영구 리포지터리(객체 리포지터리 또는 데이터베이스)에서 로그를 정리합니다.

제한 사항