Linux 패키지 설치에 대한 로그

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

GitLab에는 고급 로그 시스템이 포함되어 있으며, GitLab 내의 모든 서비스와 컴포넌트는 시스템 로그를 출력합니다. 다음은 Linux 패키지 설치에서 이러한 로그를 관리하기 위한 구성 설정 및 도구입니다.

서버에서 콘솔에서 로그 보기

GitLab 로그의 실시간 업데이트를 보려면 ‘tail’을 사용할 수 있습니다. gitlab-ctl tail을 사용할 수 있습니다.

# 모든 로그 보기; 종료하려면 Ctrl-C 누름
sudo gitlab-ctl tail

# /var/log/gitlab의 하위 디렉터리로 이동
sudo gitlab-ctl tail gitlab-rails

# 개별 파일로 이동
sudo gitlab-ctl tail nginx/gitlab_error.log

콘솔에서 로그 보기 및 파일로 저장

콘솔에서 로그를 표시하고 나중에 디버깅/분석을 위해 파일로 저장하는 것이 유용합니다. 이를 위해 tee 유틸리티를 사용할 수 있습니다.

# 'tee'를 사용하여 모든 로그를 표준 출력에 표시하고 동시에 파일에 쓰기
sudo gitlab-ctl tail | tee --append /tmp/gitlab_tail.log

기본 로그 디렉터리 구성

/etc/gitlab/gitlab.rb 파일에서 여러 유형의 로그에 대한 log_directory 키가 있습니다. 원하는 위치에 로그를 저장할 수 있도록 모든 로그에 대한 값을 주석 처리 해제하고 업데이트하십시오.

# 예:
gitlab_rails['log_directory'] = "/var/log/gitlab/gitlab-rails"
puma['log_directory'] = "/var/log/gitlab/puma"
registry['log_directory'] = "/var/log/gitlab/registry"
...

Gitaly 및 Mattermost는 다른 로그 디렉터리 구성을 갖고 있습니다:

gitaly['configuration'] = {
   logging: {
    dir: "/var/log/gitlab/registry"
   }
}
mattermost['log_file_directory'] = "/var/log/gitlab/registry"

이러한 설정으로 인스턴스를 구성하려면 sudo gitlab-ctl reconfigure를 실행하십시오.

::EndTabs::

(이어서)

(해당 테이블은 현재 없습니다.)

(계속)

사용자 정의 NGINX 로그 형식

기본적으로 NGINX 액세스 로그는 ‘combined’ NGINX 형식의 버전을 사용하여 쿼리 문자열에 내재된 잠재적으로 민감한 정보를 숨기도록 설계되었습니다. 사용자 정의 로그 형식 문자열을 사용하려면 /etc/gitlab/gitlab.rb에서 지정할 수 있습니다. 형식 세부 정보는 NGINX 문서를 참조하십시오.

nginx['log_format'] = '내 형식 문자열 $foo $bar'
mattermost_nginx['log_format'] = '내 형식 문자열 $foo $bar'

JSON 로깅

구조화된 로그는 JSON으로 내보내어 Elasticsearch, Splunk 또는 다른 로그 관리 시스템에서 구문 분석될 수 있습니다. JSON 형식은 지원하는 모든 서비스에 대해 기본적으로 활성화됩니다.

note
PostgreSQL은 외부 플러그인 없이 JSON 로깅을 지원하지 않습니다. 그러나 CSV 형식으로 로깅은 지원합니다.
postgresql['log_destination'] = 'csvlog'
postgresql['logging_collector'] = 'on'

이를 적용하려면 데이터베이스를 다시 시작해야 합니다. 자세한 내용은 PostgreSQL 문서를 참조하십시오.

텍스트 로깅

기존 로그 적재 시스템을 사용하는 고객은 JSON 로그 형식을 사용하고 싶어하지 않을 수 있습니다. 텍스트 형식은 /etc/gitlab/gitlab.rb에 다음을 설정한 후 gitlab-ctl reconfigure를 실행하여 구성할 수 있습니다.

gitaly['configuration'] = {
   logging: {
    format: ""
   }
}
gitlab_shell['log_format'] = 'text'
gitlab_workhorse['log_format'] = 'text'
registry['log_formatter'] = 'text'
sidekiq['log_format'] = 'text'
gitlab_pages['log_format'] = 'text'
note
서비스에 따라 로그 형식의 속성 이름에는 몇 가지 변형이 있습니다 (예: Container Registry는 log_formatter를 사용하고, Gitaly 및 Praefect는 모두 logging_format을 사용합니다). 자세한 내용은 Issue #4280을 참조하십시오.

rbtrace

GitLab에는 rbtrace가 포함되어 있어 Ruby 코드를 추적하고 모든 실행 중인 스레드를 보거나 메모리 덤프를 가져오는 등의 작업을 수행할 수 있습니다. 그러나 기본적으로 이 기능은 활성화되어 있지 않습니다. 이를 활성화하려면 환경에 ENABLE_RBTRACE 변수를 정의하십시오.

gitlab_rails['env'] = {"ENABLE_RBTRACE" => "1"}

그런 다음 시스템을 다시 구성하고 Puma 및 Sidekiq를 다시 시작하십시오. Linux 패키지 설치에서 이를 실행하려면 루트로 다음과 같이 실행하십시오.

/opt/gitlab/embedded/bin/ruby /opt/gitlab/embedded/bin/rbtrace

로그 레벨/상세도 구성

GitLab Rails, Container Registry, GitLab Shell 및 Gitaly의 최소 로그 레벨(상세도)을 구성할 수 있습니다.

  1. /etc/gitlab/gitlab.rb를 편집하고 로그 레벨을 설정하십시오.

    gitlab_rails['env'] = {
      "GITLAB_LOG_LEVEL" => "WARN",
    }
    registry['log_level'] = 'info'
    gitlab_shell['log_level'] = 'INFO'
    gitaly['configuration'] = {
      logging: {
        level: "warn"
      }
    }
    
  2. GitLab을 다시 구성하십시오.

    sudo gitlab-ctl reconfigure
    
note
특정 GitLab 로그(예: production_json.log, graphql_json.log 등)에 대한 log_level을 편집할 수 없습니다. 자세한 내용은 기본 로그 레벨 재정의을 참조하십시오.

사용자 정의 로그 그룹 설정

GitLab은 구성된 로그 디렉터리에 사용자 정의 그룹을 할당하는 것을 지원합니다.

logging['log_group'] 설정을 /etc/gitlab/gitlab.rb 파일에 전역적으로 구성하거나 gitaly['log_group']와 같은 서비스별 log_group 설정을 추가하면 해당 인스턴스를 구성하기 위해 sudo gitlab-ctl reconfigure를 실행해야 합니다.

전역 또는 서비스별 log_group을 설정하면:

  • 구성된 그룹 멤버가 로그 디렉터리 내용을 읽을 수 있도록 로그 디렉터리(또는 전역 설정을 사용하는 경우 모든 로그 디렉터리)의 권한을 0750으로 변경합니다.

  • runit이 지정된 log_group을 사용하여 로그를 작성하고 회전하도록 구성합니다.

사용자 정의 로그 그룹 제한

runit으로 관리되지 않는 서비스의 로그(예: /var/log/gitlab/gitlab-railsgitlab-rails 로그)는 구성된 log_group 설정을 상속받지 않습니다.

그룹은 호스트에 이미 있어야 합니다. Linux 패키지 설치는 sudo gitlab-ctl reconfigure를 실행할 때 그룹을 생성하지 않습니다.