Linux 패키지 설치에 대한 로그

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

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

서버 콘솔에서 로그 tail하기

GitLab 로그의 라이브 로그 업데이트를 보고 싶다면 ‘tail’을 사용하여 gitlab-ctl tail 명령을 사용할 수 있습니다. 

# 모든 로그 tail; 종료하려면 Ctrl-C 를 누르세요
sudo gitlab-ctl tail

# /var/log/gitlab의 하위 디렉터리로 들어가기
sudo gitlab-ctl tail gitlab-rails

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

콘솔에서 로그 tail하고 파일로 저장하기

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

# 'tee'를 사용하여 모든 로그를 STDOUT에 표시하고 동시에 파일에 작성하기
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를 실행하세요.

runit 로그

Linux 패키지 설치의 runit 관리 서비스는 svlogd를 사용하여 로그 데이터를 생성합니다.

  • 로그는 current라는 파일에 작성됩니다.
  • 정기적으로 이 로그는 TAI64N 형식을 사용하여 압축되고 이름이 변경됩니다. 예: @400000005f8eaf6f1a80ef5c.s.
  • 압축된 로그의 파일 시스템 날짜 타임스탬프는 GitLab이 해당 파일에 마지막으로 쓴 시간과 일치합니다.
  • zmore 및 zgrep를 사용하여 압축된 또는 압축되지 않은 로그를 볼 수 있고 검색할 수 있습니다.

svlogd에서 생성된 파일에 대한 자세한 정보는 svlogd 문서를 참조하세요.

다음과 같은 설정으로 /etc/gitlab/gitlab.rb를 통해 svlogd 설정을 수정할 수 있습니다. 

# 아래는 기본 값입니다
logging['svlogd_size'] = 200 * 1024 * 1024 # 로그 데이터가 200 MB가 되면 로테이트
logging['svlogd_num'] = 30 # 30개의 로테이트된 로그 파일 유지
logging['svlogd_timeout'] = 24 * 60 * 60 # 24시간 후에 로테이트
logging['svlogd_filter'] = "gzip" # gzip로 로그 압축
logging['svlogd_udp'] = nil # UDP를 통해 로그 메시지 전송
logging['svlogd_prefix'] = nil # 로그 메시지에 대한 사용자 정의 접두어

# 선택적으로 Nginx에 대한 접두어를 재정의할 수 있습니다.
nginx['svlogd_prefix'] = "nginx"

Logrotate

GitLab에 내장된 logrotate 서비스는 runit에 의해 캡처되지 않는 모든 로그를 관리합니다. 이 서비스는 gitlab-rails/production.log 및 nginx/gitlab_access.log와 같은 로그 데이터를 로테이트, 압축 및 마지막으로 삭제합니다. /etc/gitlab/gitlab.rb를 사용하여 공통 logrotate 설정, 서비스별 logrotate 설정을 구성하고 완전히 logrotate를 비활성화할 수 있습니다.

공통 logrotate 설정 구성

모든 logrotate 서비스에 대한 일반적인 설정은 /etc/gitlab/gitlab.rb 파일에 설정할 수 있습니다. 이러한 설정은 각 서비스의 logrotate 구성 파일에 대한 구성 옵션에 해당합니다. 자세한 내용은 각 서비스의 logrotate 구성 파일에 대한 로그로테이트 맨 페이지(man logrotate)를 참조하세요. 

logging['logrotate_frequency'] = "daily" # 로그를 매일로테이트
logging['logrotate_maxsize'] = nil # `maxsize`에 지정된 크기보다 크게 로그가 커지면 로그를 로테이트
logging['logrotate_size'] = nil # 기본적으로 크기에 따라 로테이트하지 않음
logging['logrotate_rotate'] = 30 # 30개의 로테이트된 로그 유지
logging['logrotate_compress'] = "compress" # 'man logrotate' 참조
logging['logrotate_method'] = "copytruncate" # 'man logrotate' 참조
logging['logrotate_postrotate'] = nil # 기본적으로 postrotate 명령 없음
logging['logrotate_dateformat'] = nil # 회전된 파일에 대해 숫자가 아닌 날짜 확장을 사용합니다. 예: "-%Y-%m-%d"의 값이 있다면 production.log-2016-03-09.gz와 같은 rotated 파일을 얻게 됩니다.

개별 서비스 logrotate 설정 구성

개별 서비스의 logrotate 설정을 /etc/gitlab/gitlab.rb를 사용하여 사용자 정의할 수 있습니다. 예를 들어 nginx 서비스의 logrotate 빈도와 크기를 사용자 정의하려면 다음과 같이 설정하세요: 

nginx['logrotate_frequency'] = nil
nginx['logrotate_size'] = "200M"

logrotate 비활성화

내장된 logrotate 서비스를 비활성화할 수도 있습니다. 다음 설정을 /etc/gitlab/gitlab.rb에 추가하세요: 

logrotate['enable'] = false

Logrotate notifempty 설정

GitLab 13.6부터 logrotate 서비스는 변경할 수 없는 기본값 notifempty로 실행되어 다음 문제를 해결합니다:

  • 불필요하게 로테이트된 빈 로그 및 종종 많은 빈 로그들이 저장되는 문제.
  • 장기적인 문제 해결을 위해 유용한 일회성 로그가 데이터베이스 마이그레이션 로그와 같이 30일 후에 삭제되는 문제.

Logrotate 일회성 및 빈 로그 처리

로그는 이제 logrotate에 필요할 때 로테이트되고 재생성되며 일회성 로그는 변경될 때에만 로테이트됩니다. 이 설정을 사용하면 일부 정리를 수행할 수 있습니다:

  • gitlab-rails/gitlab-rails-db-migrate*.log와 같은 빈 일회성 로그를 삭제할 수 있습니다.
  • 이전 버전의 GitLab에서 로테이트되고 압축된 빈 로그. 이러한 빈 로그들은 보통 크기가 20바이트입니다.

logrotate 수동 실행

Logrotate는 예약 작업이지만 필요한 경우 수동으로 트리거할 수도 있습니다.

logrotate를 사용하여 GitLab logrotate를 수동으로 트리거하려면 다음 명령을 사용하세요: 

/opt/gitlab/embedded/sbin/logrotate -fv -s /var/opt/gitlab/logrotate/logrotate.status /var/opt/gitlab/logrotate/logrotate.conf

UDP 로그 전달

Tier: Premium, Ultimate Offering: Self-managed

Linux 패키지 설치는 svlogd에서 UDP 로깅 기능 및 syslog 호환 원격 시스템으로 non-svlogd 로그를 전송할 수 있습니다. Linux 패키지 설치를 구성하여 UDP를 통해 syslog 프로토콜 메시지를 전송하려면 다음 설정을 사용하세요: 

logging['udp_log_shipping_host'] = '1.2.3.4' # 여러분의 syslog 서버
# logging['udp_log_shipping_hostname'] = nil # 선택 사항, 기본값은 시스템 호스트명
logging['udp_log_shipping_port'] = 1514 # 선택 사항, 기본값은 514 (syslog)

참고: udp_log_shipping_host를 설정하면 runit-managed 서비스의 각 호스트 및 서비스에 대해 svlogd_prefix를 추가합니다.

예제 로그 메시지: 

Jun 26 06:33:46 ubuntu1204-test production.log: Started GET "/root/my-project/import" for 127.0.0.1 at 2014-06-26 06:33:46 -0700
Jun 26 06:33:46 ubuntu1204-test production.log: Processing by ProjectsController#import as HTML
Jun 26 06:33:46 ubuntu1204-test production.log: Parameters: {"id"=>"root/my-project"}
Jun 26 06:33:46 ubuntu1204-test production.log: Completed 200 OK in 122ms (Views: 71.9ms | ActiveRecord: 12.2ms)
Jun 26 06:33:46 ubuntu1204-test gitlab_access.log: 172.16.228.1 - - [26/Jun/2014:06:33:46 -0700] "GET /root/my-project/import HTTP/1.1" 200 5775 "https://172.16.228.169/root/my-project/import" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36"
2014-06-26_13:33:46.49866 ubuntu1204-test sidekiq: 2014-06-26T13:33:46Z 18107 TID-7nbj0 Sidekiq::Extensions::DelayedMailer JID-bbfb118dd1db20f6c39f5b50 INFO: start
2014-06-26_13:33:46.52608 ubuntu1204-test sidekiq: 2014-06-26T13:33:46Z 18107 TID-7muoc RepositoryImportWorker JID-57ee926c3655fcfa062338ae INFO: start

커스텀 NGINX 로그 형식 사용하기

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

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

JSON 로깅

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

참고: 외부 플러그인 없이 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'

참고: 서비스에 따라 로그 형식에 대한 몇 가지 변형이 있습니다(예: 컨테이너 레지스트리는 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 Shell 및 Gitaly의 최소 로그 레벨(상세도)을 구성할 수 있습니다.

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

    registry['log_level'] = 'info'
gitlab_shell['log_level'] = 'INFO'
gitaly['configuration'] = {
  logging: {
    level: "warn"
  }
}

  2. GitLab을 다시 구성하십시오: 

    sudo gitlab-ctl reconfigure

참고: production_json.log, sidekiq.log 등 다른 GitLab 로그의 log_level을 편집할 수 없습니다.

사용자 정의 로그 그룹 설정

GitLab은 구성된 로그 디렉토리에 사용자 정의 그룹을 지정할 수 있습니다.

logging['log_group'] 설정을 /etc/gitlab/gitlab.rb 파일에 전역으로 설정할 수 있으며, gitaly['log_group']와 같은 서비스별 log_group 설정을 지정할 수도 있습니다. log_group 설정을 추가할 때 인스턴스를 구성하려면 sudo gitlab-ctl reconfigure를 실행해야 합니다.

전역 또는 서비스별 log_group을 설정하면 다음이 수행됩니다:

  • 구성된 그룹 구성원이 로그 디렉토리 내용을 읽을 수 있도록 로그 디렉토리의 권한을 0750으로 변경합니다.

  • 지정된 log_group(서비스별 또는 모든 runit 관리 서비스에 대해)을 사용하여 로그를 작성하고 회전하도록 runit을 구성합니다.

사용자 정의 로그 그룹 제한

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

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