작업 로그

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

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

데이터 흐름

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

단계 상태 조건 데이터 흐름 저장된 경로
1: patching log 작업이 실행 중인 경우 러너 => Puma => 파일 저장소 #{ROOT_PATH}/gitlab-ci/builds/#{YYYY_mm}/#{project_id}/#{job_id}.log
2: archiving archived log 작업이 완료된 후 Sidekiq이 로그를 artifact 폴더로 이동 #{ROOT_PATH}/gitlab-rails/shared/artifacts/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log
3: uploading archived log 로그가 보관된 후 (구성된 경우) Sidekiq이 보관된 로그를 object storage로 이동 #{bucket_name}/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log

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

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

작업 로그의 로컬 위치 변경

주의: 도커 설치의 경우 데이터가 장착된 경로를 변경할 수 있습니다. 헬름 차트의 경우 object storage를 사용하세요.

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

리눅스 패키지 (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
자체 컴파일 (source)

  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

객체 저장소로 로그 업로드

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

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

로컬 디스크 사용 방지

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

작업 로그 삭제 방법

오래된 작업 로그를 자동으로 만료시키는 방법은 없지만, 공간을 많이 차지하고 있다면 삭제해도 안전합니다. 로그를 수동으로 제거하면 UI의 작업 출력이 비어 있게 됩니다.

예를 들어, 60일 이전의 모든 작업 로그를 삭제하려면 GitLab 인스턴스의 셸에서 다음 명령을 실행하세요.

주의: 헬름 차트의 경우, 자신의 객체 저장소와 제공된 저장소 관리 도구를 사용하세요.

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

리눅스 패키지 (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
자체 컴파일 (source)
find /home/git/gitlab/shared/artifacts -name "job.log" -mtime +60 -delete

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

증분 로깅 아키텍처

  • GitLab Self-Managed 인스턴스에서 사용하려면 GitLab 관리자에게 활성화를 요청하세요.

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

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

한계